Warning: Long read. May contain 7 Tyrion Lannister Pro Tips

Management—this boogeyman word every developer hates or avoids. But hey, it doesn't have to relate to executive management specifically, or to be confined to the bureaucracy of institutions and companies.

There are possibly countless types of management—not in the sense that they are endless, but rather in their categorization and contextualization. From where I stand, I can speak about a few types: Self-Management, Task Management, Task Execution Management, and People Management.

My concern is about Self-Management and Task Execution Management. They are the most crucial types for devs and non-managerial positions, because they directly impact your—as a developer—daily progress and achievement. While other management types are important, e.g Task Management, which might be familiar to many teams and widely adopted in different forms like Agile methodology, I'm passing on them due to their organizational focus - they're externally structured frameworks that teams adopt rather than personal skills you develop.

Self-Management

Throughout my journey, I've met people with different self-management styles and personalities. Such observations extend to non-work related self-pillars like emotions, thoughts, and behavior. There are people who look like machines in terms of being fully self-managed; they manage their time, tasks, execution, emotions, thoughts, and so on. On the other side, there are people who need others to fully manage them, and of course there is a very wide range in between.

I'm not saying one of those styles is better than the other. Just as each person has their own genes, they have a different personality and type of self-management. If you accept this reality, this is what you get! But the important thing here is for someone with a need for "nano-management" to be aware of that. Being ignorant of such characteristics will put them out of their circle of competence and lead to focusing on distracting matters that would prevent their progress and reduce their productivity.

I encountered two kinds of people who need nano-management, not micromanagement. Some succeeded in carrying their duties because they were aware of the idea "this is what I can do," while the other type was not conscious about this "circle of competence"—as a concept, of course—which led them to chaos: missing deadlines, digging in the wrong place even with guidance and coaching, because they were refusing to admit the reality.

This is applicable to other areas - emotions for instance, which are generic, not limited to the workspace, and can reveal much about someone. Have you ever gotten into the office and seen your colleague's face about to explode? I bet this colleague of yours always lets outside variables affect their work performance and would need another person, maybe another colleague, to talk with—not in the sense of regular human interaction and discussion flow, but as a need for emotional direction.

An Islamic wisdom says "إنّ السماح رباح" which translates to "Allowance/Permitting is profitable"; that means giving people space to operate according to their nature, and permitting flexibility rather than imposing rigid control. It's about the profit that comes from allowing rather than restricting. And starting from oneself; you should allow your very nature, free from community and modernity stress. I knew a designer who was doing very impressive work; he could capture an idea and transform it into living graphics and animation, but he stressed himself trying to become an "entrepreneur". The word "سماح" also translates to "Forgiveness", and you might explore its relation to our context.

Speaking of myself: I struggle with vocally expressing ideas, as well as learning things at a good speed. I've come to the conclusion that I'm a slow learner and writer. That is fine; I've allowed myself to slowly learn and write, which in turn gave me a way to explore and understand complex and interconnected ideas on paper as iterations, rather than expressing them in linear sequencing—which speaking requires. So I embraced the mentioned saying above, kind of late.

I've succeeded in creating two new routines in my life; one is body activation to find the buried wisdom in flesh and bone. I'm not consistent in this routine—I don't show up at the gym every day—but I manage to find alternatives. The routine isn't about consistency; it's about recognition. Recognizing when my body needs movement to unlock or lock my mind. Sometimes that's the gym, sometimes it's pacing while debugging, sometimes it's just getting up from the damn chair. The second one is the mighty Sun Rituals. No further questions!

Self-management is sometimes sold as if you need to treat yourself as a project or a well-defined algorithm. In contrast, we are complex entities.

Self-management books and LinkedIn carousels love to pretend you're a simple system that just needs the right inputs and processes. "Follow these 7 steps!" "Use this productivity framework!" "Optimize your morning routine!" As if humans were machines that respond predictably to the same commands every day.

But we're not algorithms. We have moods, energy cycles, creative blocks, emotional baggage from yesterday's failed deploy, or excitement about a new technology we want to try. Some days you're laser-focused, other days your brain feels like spaghetti code.

The productivity gurus want you to believe consistency is king—same routine, same methods, same outputs. But real self-management means working with your inconsistencies, not against them. It's more like debugging a complex system where the variables keep changing.

Maybe today you need nano-management (strict structure), tomorrow you need complete freedom to explore. Maybe this week you're energized by hard problems, next week you need easy wins to rebuild confidence. The complexity is the point. Managing a complex entity requires flexibility, not rigid frameworks.

Am I anti-consistency? I don't think so. I'm against how it has been framed to us.

The "Strongly Typed vs Loosely Typed" analogy

Speaking coding language: keep your bigger picture/goals/milestones strongly typed—so core principles stay consistent. But adapt to loosely typed implementation based on context. You aren't going to create chaos, but flexibility instead. You'll have patterns, but not necessarily repeat yourself every day. This liquid world, as Bauman has described, will require you to allow this liquidity to pass, but not be affected by it. In this liquid modernity combined with your sophisticated personal circumstances: allowance and flexibility are survival necessities.

Personal creative processes aren't meant to be "managed" in the sense of standardization, systemization, or formalization. Imagine someone telling Leonardo da Vinci: "Hey, follow this framework, and you'll produce the most famous drawing ever." The absurdity is obvious—creativity resists systematization. But they can and should be self-micro-managed. So, Task Execution Management is an informal, non-universal, unofficial type you could call Micro-Decision Management, Self-OS, or keep it under Self-Management. You don't need to label it in the first place.

Task Execution Management

Now to the Ghoul!

I love Agile and its easing process. Once the sprint has started and you pick your first ticket, all echoes from the past start hunting you!

It doesn't matter what your code-level seniority is; what matters is your ability to manage this every time and every day, because each task is unique however similar it is to other tasks you've done before. You might already be confident about what you are going to do, but I bet you cannot explain the "How" each time in the same steps. If you fail to admit this, you've created another issue for yourself. Also, I haven't worked in big corporations, so I'm not aware of their processes, knowledge bases, or orientation programs that might help with task execution—this is coming from smaller team/startup experience.

No fancy promises such as you'll find here a "7 Ways To Flourish While Executing Your Daily Tasks"—which could be one of the top sellers in the future—guide. This would be exploring and insights sharing—you might find it useful and you may not. Also, none of my claims come from profound research; they are all raw observations and notes.

Whatever you are up to, don't start coding immediately—just don't!

Philosophers taught us about important life questions, which also happen to exist in most learning paths: What? When? Where? Who? Why?

The good news: you don't have to answer the immediate "Why" like "why am I doing this task?" either from a business perspective or from your existential perspective. Also, you can safely eliminate the "Who" as no one else will do your job. I intentionally dropped the "How" as, if you remember, it is the main one you are trying to answer yourself silently.

"What"

Probably this is the easiest question, and most likely well defined in your board ticket, and you may even have a good picture of its implementation. Despite that, it is a tricky one, and highly interconnected with "When" and both need to be managed simultaneously.

"Where"

I take time to scan a project, even though I'm living with it every day and see those lines that blur my eyes more than my kids. I have to do this every time, regardless of whether I'm working solo or within a team. It's like a recap of what has been done; what to use; what to avoid duplicating; where the new service or new model shall live. It helps you strategically build the picture in your mind, and once it's there, you can blueprint on paper, draw a diagram, whatever suits you!

If I have to pick for you, I'd say start with 'Where' - it will be your friend. Unlike "What" which can spiral into endless requirements analysis, or “When” which opens the door to decision paralysis, "Where" grounds you in the actual codebase reality. It forces you to do that essential scanning ritual, rebuilding your mental map even when you think you know the code intimately. Starting with 'Where' prevents the common mistakes of duplicating functionality, breaking existing patterns, or creating isolated code islands, and it naturally connects to that "don't start coding immediately" wisdom - making you pause, think strategically, and build that blueprint in your mind before your fingers hit the keyboard.

Starting from the wrong place will create a time vortex like the ones Dr. Strange does, except you don't have the time stone or any Ancient One to guide you out. You need precision that will relieve you of the burden of answering other questions.

Starting from "Where" might slow you down - short-term - but definitely will keep you on track - long-term benefit for better decisions, fewer rewrites, and cleaner execution.

"When"

This is a branched question that might hit technical and non-technical territories. I've been asked these kinds of questions while giving a training session, and honestly I did not have a clear answer that a fresh graduate would be satisfied with.

Have you ever asked yourself:

When to start with UI and when with the data layer?
When to ask for help versus struggle alone?
When to refactor versus when to just make it work?
When to reset and when to proceed? (It is not obvious, by the way.)
When to over-engineer or under-engineer?
When to optimize for performance versus readability?
When to write tests first versus after?
When to tackle the hard part first versus start with easy wins?
When to make judgment calls versus have strict definitions?

Pay attention during this stage of your execution, and if you followed the 'Where' advice, it might save you a lot of hassle. In this era, you're either under-productive or super productive; either way, pause. Such questions interfere with the organic "How", and if you want to be productive, never count lines. This is the big dilemma I'm wrestling with right now.

Sometimes you have to make judgement calls - stress on your instinct, conduct quick research, depend on your experience in similar cases, future proof thinking. But here's the thing: there's no universal formula for these decisions. What works in one context fails in another.

SE guidelines are great, when you are looking for "textbook answers", but they assume rational conditions, stable teams, and predictable environments. They don’t count your energy level, team dynamics, political pressure, real-word chaos, legacy codebase constraints, skill gaps, or business priorities.

For example, books say "Start with data layer" or "Start with UI" or "It depends", but rarely address what to do when you're solo switching contexts constantly, when business pressure forces a specific approach, when legacy constraints limit your choices, or when you're not sure what the final product should be.

The books assume you have time for proper analysis - they don't cover "I need to deliver something in 3 days and I'm not sure what the stakeholder actually wants."

Sometimes you'd start with UI to digest the complex requirements, other times you’d start with a simple function, more frequently you'll have to lay out the data foundation at the very beginning.

Your "when" instincts improve with experience, but they're always contextual. The same developer who knows exactly when to optimize for performance in a fintech app might be completely lost about when to write tests in a creative prototype.

The goal isn't perfect timing - it's conscious decision-making. Even when you get it "wrong," knowing why - tactical why - you made the choice helps you calibrate for next time. The developers who struggle most are the ones who make these decisions unconsciously, then wonder why their instincts never improve.

So yeah, even in ones and zeros world, developed instinct still valid.

"How"

As the above elaboration on questions may help you slightly in answering the main "How," keep in mind: the notes from the previous questions do not, in any way, mean to ignore guidelines. You still need to confirm the following practices while answering them: Clean Code, Best Practices, Authentic sources, team documentation and knowledge bases, SOLID and DRY, and all other hot stuff.

Our "How" isn't a tutorial; it's a survival kit that will activate as a primal instinct once you're trapped. To sum up, you'll keep bouncing between "What" and "Where" for a while until you have your mind-map fully developed, stepping into the next stage where all the magic happens. As simple as this, right?

The Existential Thread

On Context and Complexity: I'll just remind you that there are no constants—rather the ones you define in your code—in all of that. So yes, context matters. Starting from your workspace, your development environment, to the exact case and scenario you are dealing with at the moment.

While Software Engineering focuses on disciplining development practices and processes, I'm tackling the individual psychology and real-time decision-making that happens within those processes—exploring how management concepts can help navigate the messy human side of coding.

On the "Why" Trap: Starting with "Why" will lead you to an Existential Crisis; avoid it unless you are ready to fight these battles every day. You start with "when should I use this design pattern" and suddenly you're questioning the nature of universal truth, which is also typically not management's primary domain. But it also happens that practical whys (i.e., choosing one architectural pattern over another for maintainability over performance considerations) lead to the land of existential mines: Why this algorithm? For better performance. Why better performance? For user satisfaction. Why user satisfaction? For business success. Why business success? For... career advancement? Personal fulfillment? Societal contribution? Why do any of those matter? What's the point of any of this work? Why am I spending my finite existence writing code? If you happen to fall into this trap, run, lift weights, tire your body out. Nothing defeats the mind like exhausting the body.

On Effectiveness vs. Balance: I'm not a fan of "work-life balance"; I'm a fan of "being effective in what you are doing," which might require you to balance things. This means developing mental structures, coping mechanisms, and agility and flexibility to get things done.

On Perspective and Reality: Absolutely, my notes are irrelevant to other contexts, especially stable and systematic environments. But from where I'm talking, managing any task, let alone completing it, in Palestine is a victory over reality (Militarized, Brutal, yet Liquid Modernity), not just an achievement.

On Dramatic Transformation: Embrace the concept "The deceived is the one whose days are equal" to ensure forward movement without falling into the "why" trap. Switching between implementations while maintaining core principles will definitely add to your day.

On Unconscious Competence: The best self-management often happens when you're not consciously managing - just following your natural rhythms and instincts.

Tyrion Lannister Pro Tips

I'm not trying to sell my word as other men's wisdom :) but you could use of them:

Stick to your circle of competence, even if only momentarily.
Allowance is profitable, restricting is costly.
Answer the questions, even implicitly.
Start with "Where" not with coding, or "Why".
"Why" is a divisive question. Important in some contexts.
When you are under-productive, stop.
When you are super-productive, also stop.

Yes, I accidentally created two sets of 7 points while making fun of '7 Ways' frameworks. The irony is not lost on me. 😄

Raw Notes On Management and Beyond: A Dev's Perspective