In the pioneering days of the 1960s and 70s, a "good" developer was a master of precision. When you were punching holes into cards, a single typo wasn’t just an error, it was a wasted day of processing. Success meant having an intimate, low-level relationship with the hardware. You were responsible for managing every byte of memory and every CPU cycle.

As personal computing took hold, the goalposts shifted from hardware limitation to structural integrity. Being "good" meant writing robust, maintainable code. We turned our focus toward structured programming and object-oriented design, prioritising the longevity of a system and its ability to scale without collapsing under its own complexity.

Then the cloud age forced a third evolution: service-first thinking. Suddenly, a functional algorithm was insufficient. A "good" developer had to master the abstractions of distributed systems, scalability, and DevOps. You were no longer merely writing a program; you were architecting a resilient, 24/7 ecosystem.

Today, we stand at the threshold of a fourth redefinition.

And this one is more radical than the others.

The AI era is doing more than automating tasks, it is reshaping the traditional hierarchy of the industry. For decades, software development relied on a broad base of junior contributors handling high-volume implementation work, while a smaller number of architects made the decisive technical choices at the summit.

That pyramid is compressing into a flatter landscape. As portions of implementation are becoming commoditised, the baseline expectation for many developers is being pulled upward. More developers are being expected to think like solution architects earlier in their careers.

In this new reality, value is no longer derived from commit frequency or ticket velocity, but it is instead found in your ability to orchestrate, audit, and direct.

The New Normal

A developer’s skill is no longer measured solely by their technical grounding, but by their ability to translate complex logic into unambiguous intent. Communication has become a primary technical discipline.

Before AI a developer could find job security within the labyrinth of the code; if you were able to navigate a convoluted codebase, you were considered valuable by default. But as AI assumes the heavy lifting of boilerplate and implementation, the bottleneck has shifted from the keyboard to the mind. We are entering the age of intent-based development, where the primary task is no longer the manual construction of implementation logic, but the delivery of a flawless mental model to a machine capable of building it.

As the corporate mandate to "do more with less" accelerates, the traditional developer role is evolving under the pressure of AI-assisted velocity. In this high-stakes environment, AI literacy is no longer seen as a competitive edge, but rather a baseline requirement for professional survival.

True literacy, however, is not merely knowing how to "chat" with a model; it is a deep understanding of its underlying logic, its limitations, and its specific capabilities. Ultimately, this is the line of demarcation in the modern industry: the difference between a developer who is replaced by a machine and one who uses that machine to amplify their own architectural vision.

Prompting as Functional Specification

In a professional SDLC, we have never lacked context. Between design systems, Agile ceremonies, and explicit acceptance criteria, the "what" has always been well defined. Historically, however, the gap between a human-readable user story and a machine-executable program was bridged by a developer’s manual labour. The most effective developers were those who could internalise a nuanced requirement and mentally map out the precise technical constraints, data structures, and edge cases. They were translators, converting business intent into logical architecture that they would then disseminate to others to be manually built out.

In this new paradigm, the AI has effectively become the recipient of that delegation.

As execution becomes cheaper, specification becomes the primary engineering activity. The manual execution phase is no longer the differentiator it once was. Instead, the developer becomes the bridge between a Product Owner’s vision and a machine’s literalism. Within this framework, prompting must be reframed from a conversational shortcut into an exercise in functional specification discipline. While a human can infer meaning from a bullet point in a Jira ticket, a machine cannot.

As a result, "good" is now defined by the ability to transform high-level business goals into high-fidelity technical instructions. This demands a mastery of techniques that go beyond simple queries. We are all now required to think like architects, precisely because the machine has assumed the role of the scribe.

From Author to Authority

We are transitioning from a world where we are judged by the code we produce to one where we are judged by the code we permit to exist. Unlike traditional peer review (where one can assume shared human intuition and a mutual understanding of "why"), auditing AI requires a fundamental shift toward radical skepticism. You are no longer reviewing a colleague; you are interrogating an entity that possesses technical fluency but inconsistent judgement.

Consequently, the "good" developer now acts as a high-stakes editor for a tool capable of brilliant synthesis one moment and confident hallucination the next. It can optimise a function, but it cannot understand the domain-specific "why" behind a feature's existence. This requires acknowledging that while an AI is a great assistant, it remains blind to the nuances of business logic and the long-term trade-offs of maintainability, security, and systemic side effects.

In this new hierarchy, seniority is found in the authority to sign off on a solution rather than the manual labour of authoring it. This demands a specialised intuition for spotting the subtle logical flaws that a predictive model naturally glosses over in its rush to provide a correct-looking answer. Your role is to ensure that the sheer velocity of AI-assisted production remains aligned with the structural integrity and the commercial objective of the project.

Ultimately, the most vital skill in the modern toolkit is the wisdom to know exactly when to tell the machine "no."

The Future-Fit Developer

The industry’s transformation doesn't just change how software is written; it collapses the traditional model that once defined developer growth. We are entering an era where exposure to architectural responsibility arrives far earlier in a career than it used to.

In previous generations, a “junior” developer focused primarily on learning the mechanics of implementation. Today, as AI can produce senior-level output at junior-level cost, the role is shifting: the constraint is no longer throughput but judgement. Developers are increasingly expected to evaluate solutions and make architectural trade-offs, not merely execute them.

This shift introduces what might be called a wisdom gap: the space between a machine’s ability to generate solutions and a developer’s ability to verify whether those solutions are appropriate in context.

To bridge that gap, the "good" developer evolves from a polyglot implementer into a contextual navigator of systems. Progression is no longer defined by how well you can code; it is defined by how well you understand boundaries, trade-offs, and consequences across a system.

Professional longevity, therefore, is no longer found in attempting to outpace the machine, but in the collaborative intelligence required to guide it. AI accelerates the path to the “Aha!” moment, but it does not remove the responsibility of deciding what should happen next. In this environment, developers are no longer just builders of components, they are stewards of direction.

Compressed Growth Trajectory

If the role of the developer is changing, the timeline for becoming one is changing with it.

Traditionally, seniority emerged from years of accumulated exposure to implementation details and the slow internalisation of how languages behaved and how systems failed. Today, when AI can generate thousands of lines of syntactically correct code in seconds, learning is no longer tightly coupled to typing. The growth curve has shifted from repetition-driven mastery to concept-driven acceleration.

This changes what career progression actually measures. Increasingly, advancement depends less on how quickly a developer can implement features and more on how effectively they can evaluate solutions. AI accelerates execution, but it also amplifies the consequences of weak structural decisions.

As a result, Computer Science fundamentals are moving from academic background knowledge to operational decision-making tools. AI can produce working implementations quickly, but it still optimizes locally rather than globally, it does not inherently understand whether a solution aligns with long-term system constraints, scaling realities, or business context. That responsibility remains human.

Intelligent Collaboration

Where previous generations relied on documentation, code review cycles, and accumulated institutional knowledge to understand unfamiliar systems, today’s developer can interrogate a codebase conversationally. A “good” developer uses AI as an exploratory partner, asking why a system behaves the way it does, how a component evolved into its current shape, and what assumptions are quietly embedded in its architecture. The result is not just faster output, but faster orientation.

This changes how learning happens inside a project. Instead of treating implementation as the primary path to understanding, developers can now model alternative approaches before committing to them. They can ask how a different data structure might affect performance characteristics, how a boundary change might alter coupling, or how an architectural decision might influence future extensibility. The machine becomes a surface against which ideas can be tested early, cheaply, and repeatedly.

Crucially, this only works when AI is used as a reasoning partner rather than a reasoning substitute. Used passively, it becomes a crutch that accelerates output while quietly weakening understanding. Used deliberately, it becomes a mirror that exposes assumptions, surfaces trade-offs, and sharpens judgement. As a result, "good" developers don’t ask the system to think for them, they use it to think with them.

This is the shift from automation to collaboration. The developer is no longer working alone at the keyboard, nor are they delegating total responsibility to a model. Instead, they are conducting a continuous dialogue with the system. It's not about how often you use AI, but how deliberately you collaborate with it.

In this environment, the defining skill is no longer just writing solutions. It is knowing how to ask the kinds of questions that make solutions better before they are written. The “good” developer treats AI not as a replacement for judgement, but as a multiplier of it.

Conclusion

The definition of a “good” developer has never been static. It has always followed the location of the highest-leverage decisions in the software lifecycle. In previous eras, those decisions lived close to the implementation. In the AI era, they are moving upstream, into intent, structure, and judgement.

The developers who thrive will not be the ones who write the most code, but the ones who can translate ideas into systems with clarity and precision.

That was my dilemma recently. I wanted to watch something with Jason Statham, but I wasn’t sure which film I was in the mood for. I just wanted to see what was available across my subscriptions and choose from there. In my house we have Amazon Prime, Netflix, and Disney+, and the thought of searching each one manually sounded painful.

So… I automated it.

Using a Postman collection and a Watchmode API key, I built a small platform-agnostic search tool that pulls together every Statham title and tells me where I can stream it. Watchmode’s data isn’t perfect, but it’s reliable enough for casual browsing, and the API is so simple that you can be up and running in minutes.

The Watchmode API Requests

1. Make a request to the ‘search’ endpoint with the name of the actor you’re interested in to get their Watchmode id:
   https://api.watchmode.com/v1/search/?apiKey={{api_key}}&search_field=name&search_value={{actor}}

2. Make a request to the ‘list-titles’ endpoint with that actor’s id to get their films as known by Watchmode:
   https://api.watchmode.com/v1/list-titles/?apiKey={{api_key}}&person_id={{actor_id}}

3. Make a request to the title’s ‘sources’ endpoint for each film listed to get the streaming services Watchmode think has it available:
   https://api.watchmode.com/v1/title/{{title_id}}/sources/?apiKey={{api_key}}=GB

You could run these manually - copying IDs from one response into the next - but where’s the fun in that? Let’s automate it.

Making It Dynamic with Postman Variables

If you’re new to Postman, the double braces ({{api_key}}, {{actor}}, etc.) represent variables. They let you store reusable values (like your API key or actor name) that Postman automatically substitutes into requests.

In this example:

• {{actor}} might be Jason Statham

• {{api_key}} is your Watchmode developer key

Automating the Workflow

One of Postman’s best features is that you can run custom JavaScript before and after each request using the Pre-request Script and Tests tabs. This lets you capture response data, save it as variables, and use it in later requests - all automatically.

Here’s what our flow now looks like:

1. Search endpoint

   • Make a request for the actor’s name

   • Extract the actor’s Watchmode ID

   • Save it as a collection variable: {{actor_id}}

2. List-titles endpoint

   • Use {{actor_id}} to fetch all films

   • Store each film’s ID and title as an array of objects in {{titles}}

3. Sources endpoint

   • Loop over each title in {{titles}}

   • Request the available streaming sources for each film

   • Save the results in a final variable: {{available_on}}

The Final Result

With just a handful of lines of JavaScript and Postman’s Collection Runner, you can pull every title for an actor and see exactly which of your streaming subscriptions carry it - all without leaving Postman. Here’s what Jason Statham films Watchmode API said was available for my chosen streaming services:

{
    "13":["Prime Video"],
    "Operation Fortune: Ruse de Guerre":["Prime Video"],
    "A Working Man":["Prime Video"],
    "Fast & Furious Presents: Hobbs & Shaw":["Netflix"],
    "The Expendables 2":["Netflix"],
    "Meg 2: The Trench":["Prime Video"],
    "Spy":["Disney+"],
    "The Mechanic":["Netflix"],
    "The Expendables 3":["Netflix"],
    "The Expendables":["Netflix"],
    "Collateral":["Netflix"],
    "Homefront":["Netflix","Prime Video"],
    "The Transporter":["Disney+"],
    "Transporter 2":["Disney+"],
    "Transporter 3":["Prime Video"],
    "Crank: High Voltage":["Prime Video"],
    "Hummingbird":["Disney+"],
    "Revolver":["Netflix","Prime Video"],
    "Cellular":["Netflix"],
    "Expend4bles":["Netflix"],
    "Safe":["Prime Video"],
    "Gnomeo & Juliet":["Prime Video"],
    "In the Name of the King: A Dungeon Siege Tale":["Prime Video"]
}

In the end I settled on 13, a gritty and suspensful film about a desperate young man unknowingly entering an underworld game of Russian roulette.

How It Works

Test script for our ‘search’ request to get the actor id:

// Parse JSON response
let jsonData = pm.response.json();

// Ensure people_results exists
if (jsonData.people_results && jsonData.people_results.length > 0) {
    let person = jsonData.people_results[0];
    let actorId = person.id;

    // Save actor ID
    pm.collectionVariables.set("actor_id", actorId);
    console.log(`✅ Saved actor_id ${actorId}`);
}

Test script for our ‘list-titles’ request to get the films:

let jsonData = pm.response.json();

if (jsonData.titles && jsonData.titles.length > 0) {
    // Save titles array
    let titlesArray = jsonData.titles.map(t => ({ id: t.id, title: t.title }));
    pm.collectionVariables.set("actor_titles", JSON.stringify(titlesArray));

    // Initialize index for looping - used in our final request to loop over each title
    pm.collectionVariables.set("current_index", 0);

    console.log("✅ Saved actor_titles and initialized current_index");
}

Pre-request script for our ‘sources’ request to handle the looping over titles:

let titles = JSON.parse(pm.collectionVariables.get("actor_titles") || "[]");
let index = parseInt(pm.collectionVariables.get("current_index") || "0");

let currentTitle = titles[index];

if (currentTitle) {
    pm.variables.set("title_id", currentTitle.id);
    pm.variables.set("title_name", currentTitle.title);
    console.log(`\n🎬 [Title ${index + 1}/${titles.length}] Processing: "${currentTitle.title}" (ID: ${currentTitle.id})`);
} else {
    console.warn("⚠️ No title found for this index");

    // Close the iterations
    postman.setNextRequest(null);
}

Test script for our ‘sources’ request to get the streaming sources offering each film:

// Parse JSON response for sources
let sources = pm.response.json();

// Retrieve existing results
let allResults = pm.collectionVariables.get("available_on");
allResults = allResults ? JSON.parse(allResults) : {};

// Get current title info
let titleId = pm.variables.get("title_id");
let titleName = pm.variables.get("title_name");

// Target streaming services - the services I have access to
// Can add 'Amazon' if you're open to renting
let targetSources = ["Netflix", "Prime Video", "Disney+"];

// Array to hold found services
let servicesFound = [];

let normalizedSources = sources.map(src => ({
    name: src.name ? src.name.trim().toLowerCase() : "",
    web_url: src.web_url
}));

targetSources.forEach(target => {
    let matched = normalizedSources.find(src => src.name.includes(target.toLowerCase()));
    if (matched) {
        servicesFound.push(target);
        console.log(`✅ Found ${target} for "${titleName}"`);
    } else {
        console.log(`❌ ${target} not found for "${titleName}"`);
    }
});

// Only set title if it's offered by our chosen services
if (servicesFound.length > 0) {
    allResults[titleName] = servicesFound;
}

// Save results
pm.collectionVariables.set("available_on", JSON.stringify(allResults));

// Increment index
let titles = JSON.parse(pm.collectionVariables.get("actor_titles") || "[]");
let index = parseInt(pm.collectionVariables.get("current_index") || "0") + 1;

// Loop or finish
if (index < titles.length) {
    pm.collectionVariables.set("current_index", index);
    console.log(`➡️ Moving to next title (${index + 1} of ${titles.length})`);
    postman.setNextRequest("Request 3"); // loop to same request
} else {
    console.log("✅ All titles processed!");
    postman.setNextRequest(null); // stop run
}

With everything configured, open Postman’s Collection Runner, select your collection, and set the request order to Search → Titles → Sources. Hit Run, and Postman will take care of the rest. When the run finishes, check your collection variables — you should see a new {{available_on}} variable containing your JSON blob of movie data.

In just a few clicks, you’ve built a custom, cross-platform movie search that finds films in seconds across all your streaming services.

1. They Communicate Clearly

A good manager never leaves you in the dark. They check in, provide constructive feedback, and let you know where you stand. Just like in a healthy relationship, they won’t ghost you for weeks and then hit you with an unexpected “We need to talk”. They articulate expectations clearly, ensuring you feel secure and valued rather than confused or anxious.

2. They Have a Sense of Humour

A little workplace banter, a well-timed joke, or a funny meme in the team chat - good managers know how to keep things light. A sense of humour can make tough situations more bearable, whether it's a stressful deadline or a meet the parents style disaster. And let’s be real, a shared sense of humour is what makes both great workplaces and great relationships thrive.

3. They Respect Boundaries

Good managers know that you have a life outside of work (or at least, they should). They respect your personal time, ensuring that work doesn’t consume your entire existence. Similarly, a great partner wouldn’t expect you to be available 24/7 or guilt-trip you for needing space. If your manager texts you at all hours of the day with urgent tasks, well… that’s a different kind of relationship, and not the healthy kind.

4. They Make You Feel Valued

The best managers understand that feeling appreciated is key to motivation and satisfaction. They acknowledge hard work, show gratitude, and make their team members feel like an important part of something bigger. Likewise, a great partner consistently expresses appreciation, making sure you know just how much you mean to them. Whether it’s a thoughtful “thank you” or a grand gesture, knowing your efforts are seen and valued strengthens any relationship.

5. They’re Reliable and Trustworthy

In both business and love, trust is everything. A solid manager follows through on promises, ensures fairness, and always has your back. Just like a good partner remembers your anniversary, a dependable manager won’t suddenly switch priorities or ignore you when you need guidance.

6. They Handle Conflict with Maturity

No passive-aggressive messages. No silent treatment. Just honest conversations to resolve issues efficiently. A great manager addresses conflicts head-on, listens to all sides, and works toward a solution instead of holding grudges. If only every relationship operated this smoothly - no more “I’m fine” and silent treatment when they’re definitely not fine!

7. They Celebrate Wins in Meaningful Ways

Much like a great partner cheers you on and is always by your side, a good manager makes sure your successes, big or small, don’t go unnoticed. But beyond simple recognition, they find ways to celebrate in meaningful ways - whether it’s a heartfelt shoutout in a meeting, a pizza lunch, or a simple but sincere slack message of appreciation. A partner who does the same - remembering milestones and making a big deal out of them - makes life that much sweeter.

8. They Offer Constructive Feedback

A good manager doesn’t just point out what’s wrong - they help you improve by providing actionable and timely feedback and encouragement. Similarly, a good partner won’t just tell you that your cooking is bad - they’ll politely commend you for your efforts and gently suggest takeout when you offer to cook again.

9. They Encourage Teamwork

Micromanagers make terrible bosses, just like controlling partners make terrible significant others. A great manager makes their team feel heard and included, giving them the autonomy to work independently while offering support when needed. Likewise, a great partner trusts you to make your own choices, respects your independence, and cares about your opinions rather than trying to dictate everything.

10. They Adapt to Changing Situations

The best managers can navigate shifting priorities, unexpected challenges, and last-minute curveballs with grace. They don’t panic or shut down when things go off-script; they pivot, problem-solve, and keep things moving forward. Just like an ideal partner doesn’t crumble when date night plans fall apart or when life throws surprises their way. Instead, they roll with the punches, finding ways to make the best of any situation.

So this Valentine’s Day, if you’re single, don’t despair - just appreciate your great manager. They might not bring you chocolates, but at least they’re contractually obligated to care about you.

Happy Valentine’s Day to all the leaders, lovers, and those just trying to survive another day in the office!

- Made with love and ChatGPT ❤️

This post will explore practical strategies to help you get to know your codebase better, regardless of whether you're starting a new job or looking to get ahead professionally in your current position.

Trace code execution

Following a piece of functionality through the codebase gives you a clear idea of the system's flow and operation. Are there lots of moving parts? Is everything handled in one place? Is the code new or old? By simply taking an action and unravelling its inner workings, you can quickly grasp the architecture and design of the code.

Start with the UI elements, if relevant, and then work through the code. This will allow you to compare the user flow with the code flow. Does it make sense? Are the two aligned? Compare the use of wording against variable and function names, are they conveying the same meaning?

Tip: Take note of the filenames and endpoints as you trace the execution, this creates a sort of stack trace for you to follow. Additionally, check to see if there is any documentation covering the aspect of the system you're investigating. If there isn't any, your stack trace could become the basis of a new piece of technical documentation.

Pair program

If you're starting a piece of work in a new area or hear about someone working on something you haven't explored yet but find interesting, ask if you can work on it together. Pair programming with someone more familiar with the area allows you to ask questions and get up to speed more quickly, bypassing much of the trial and error and upfront investigation necessary when working alone.

Tip: Before starting a pair programming session, ensure that goals of what you want to achieve from the session are clear. Agree on a specific problem to solve or a piece of the codebase to explore. Make sure to consider who performs the roles of "driver" and "navigator", as that might steer the learnings you can expect to gather.

Take advantage of Pull Requests

Pull requests (PRs) are a great way to stay updated on the changes being implemented in the system. They also offer an opportunity to ask questions and understand different areas of the codebase you may not have worked on yet. This not only shows that you’re engaged but also helps you learn why certain decisions were made. Engaging with pull requests helps you learn from others’ work and keep a pulse on the evolving state of the code. Remember that you don't need to leave a review (approve, decline, request changes etc.) to be able to ask questions. So you can peruse at your leisure without having to worry about overstepping your mark by reviewing unsolicited.

Tip: When reviewing pull requests, try to source them from as many different contributors as possible. This allows you to be exposed to a greater variety of ways of working and areas of the system.

Review and update documentation

Although often seen as more of a chore than a resource, reviewing, producing, and updating documentation can be a valuable method for improving your knowledge of the codebase. By documenting what you know, you reinforce your understanding and create an easily accessible explanation of the system's inner workings. This also creates a valuable resource for others which in turn elevates their perception of you.

Tip: As you review documentation check the change log/history if there is one. If you come across a section that hasn't been updated for a while, it could suggest its out of date.

Review the commit history

Understanding the evolution of the codebase and the rationale behind changes can provide context and insights into its current state. This can help you assess whether the foundation of the codebase is solid or problematic. With this knowledge, you can better estimate the feasibility of extending or maintaining the functionality.

In addition, when reviewing the commit history look for patterns in the types of changes being made. If you are consistently seeing bug fixes being applied to a particular area or module, it could suggest its no longer in active development and just in maintenance.

Tip: Use IDE plugins/addons such as Git Lens and Git Blame to see the commit history from within your preferred IDE. Additionally, try to reach out to the developers who made significant changes to gain insights into their thought processes and any challenges they encountered.

Start by writing tests

Writing unit tests, integration tests, or end-to-end tests forces you to understand the functionality and edge cases of the code. Reviewing existing tests can also provide valuable insights into code behaviour. If there are no automated tests, try using debugging tools to step through the code execution and learn how it operates.

Tip: When writing tests, start with edge cases and boundary conditions that are most likely to expose bugs. If you're stepping through the code instead, use breakpoints strategically to pause at key points in the code. This allows you to observe the flow and state of the application at critical points. If you encounter unexpected behaviour, take note of the variables and their values and consider raising a ticket to address the issue.

Play around

Try refactoring the code and observing what breaks! Does the whole system crash after a simple change, or is it a relatively painless experience? Knowing how easy or difficult it is to modify the code helps you predict how straightforward it will be to extend the functionality in the future.

Tip: If you encounter any issues or quirks you weren't expecting, raise them as tickets or query them with other members of the team. Taking the initiative allows you to present yourself as proactive.

Conclusion

Mastering your codebase is a crucial step in your journey as a developer. By consistently exploring, questioning, and experimenting within the code, you’ll not only become more confident and capable but also enhance your overall effectiveness. Whether you’re starting a new job or aiming to deepen your expertise in your current role, investing time in understanding the codebase will set you apart as a knowledgeable and proactive professional. By embracing these strategies you’ll find yourself better equipped to tackle challenges, make informed decisions, and more quickly contribute meaningfully.

The Importance of Accurate Estimations

As software developers, the estimates we provide carry significant weight and often have broader implications than we might anticipate. Although these estimates are not meant to be commitments or promises, they are frequently interpreted as such by our colleagues, both technical and non-technical. These estimates can influence project plans, roadmaps, budgets, and resource allocation. Consequently, an inaccurate estimate can reflect poorly not only on ourselves but also on our team, department, and even the entire organisation.

This significance is amplified when providing estimates to individuals outside our team and organisation. When dealing with vendors, industry partners, and clients, our estimates are even more likely to be interpreted as commitments. There is no faster way to disappoint a third party than by overpromising and underdelivering.

So why are our estimates often taken out of context and misconstrued as promises? The reason lies in the differing languages spoken by developers and everyone else. We understand that a task's complexity can vary and that our estimates are informed guesses - nothing more. However, others deal in absolutes. When they hear "probably tomorrow," they interpret it as "tomorrow." This misunderstanding can lead to miscommunication, such as a client expecting a quick resolution to a support case or the board anticipating forecasted revenue from a newly developed product or feature.

The Difference Between Junior and Senior Developers

It is clear then that accurate estimates are vital for any successful project. However, mastering this skill is a key factor that distinguishes junior developers from their more senior colleagues. In my opinion, it can also play an essential part in the success and rate of progress of a developer's career.

While you may think that being a good estimator comes down more to experience and expertise than to anything else, there are a lot more nuances involved in estimations. An estimate is a culmination of experience, ability, certainty, knowledge of the codebase, and an awareness of the wider environment.

Throughout my career, I have observed several common challenges that junior developers face with estimations:

1. Taking tasks at face value: Junior developers often estimate only what is explicitly mentioned in a ticket, overlooking hidden complexities or dependencies that may affect the overall effort required.

2. Limited knowledge of the codebase: New developers may struggle to foresee how changes in one part of the codebase can ripple through other components or external dependencies, impacting their estimation accuracy.

3. Overestimating their abilities: Early in their careers, developers may underestimate the time and effort needed to complete tasks, not yet fully aware of the intricacies involved or the potential for unforeseen obstacles.

4. Neglecting non-coding aspects: Estimation involves more than just writing code. Junior developers may overlook tasks such as writing tests, undergoing code reviews, or obtaining approvals from other teams, leading to underestimated completion times.

5. Difficulty in breaking tasks down: Junior developers may attempt to tackle large tasks as a whole rather than breaking them down into smaller, manageable sub-tasks. This can lead to confusion and inaccurate estimations as they wade through the complexity they have unknowingly ventured into.

Although juniors often struggle with estimating effort, it's important to note that senior developers are not infallible; they too face challenges. However, they are usually more adept at anticipating obstacles, breaking tasks into manageable chunks, and considering the broader implications of their work.

Good vs Bad Estimation

After discussing the importance of estimation and the common pitfalls, let's now explore some typical types of estimators - both good and bad.

• The People Pleaser - Nobody wants to be the bearer of bad news, especially when it comes to important tasks and deadlines, but no one avoids bad news as much as the people pleaser. In an effort to stay in everyone's good books they provide estimates based on what they think people want to hear rather than the reality. You will often find people pleasers giving unrealistic estimates just to keep others happy. An example could be agreeing to a shorter turnaround and then working overtime to make it happen, often leading to burnout or setting unrealistic expectations for future projects.

• The Overpromiser - A cousin to the people pleaser is the overpromiser. The overpromiser people pleases in a different way by providing estimates beyond expectation in order to appear more competent than perhaps they are. The overpromiser will often provide estimates without real investigation in order to seem in control and knowledgeable. However, often they underestimate the size of the task and are left looking incompetent, which can undermine trust and strain team collaboration. An example could be providing an estimate on a bug fix without investigating the issue first, stating something along the lines of "oh I know that what that is, it should be easy - 10 minutes tops". Low and behold 10 minutes go by and the issue is still nowhere near complete.

• The Underpromiser - The opposite of the overpromiser is the underpromiser. The underpromiser purposefully exaggerates their estimates so that they can always better them, with the hope that this makes them seem like a better developer. In reality, however, their lack of accuracy makes them appear unreliable and can be just as damaging as overpromising, often leading to unnecessary delays and missed opportunities for optimisation.

• The Evader - For fear of becoming a people pleaser or overpromiser, our next type of estimator refuses to estimate at all unless they are completely confident in their estimation. Choosing to evade the accountability of providing a bad estimate, the evader only acts in confidence. They hide behind terms such as "I don't know," "how long is a piece of string," and "I couldn't possibly say" in order to shirk responsibility. However, what they don’t realize is that providing no estimate at all can be more detrimental than offering a poor one, as it leaves teams and stakeholders without direction and unable to plan effectively.

• The Adjuster - The adjuster understands that estimates aren't always accurate and can change as new information surfaces. By transparently adjusting their estimates, they help stakeholders prepare for potential changes and build trust through ongoing communication. This approach allows teams to stay agile and responsive to evolving project demands.

• The Professional - The final type of estimator is the professional. Professionals understand that one estimate isn't accurate enough to depict the variability of software tasks. Instead, as described in Robert C. Martin's The Clean Coder, they provide three estimates; an optimistic estimate (perfect conditions), a nominal estimate (most likely conditions) and a pessimistic estimate (worse conditions). These estimates produce a distribution that highlights the possible timeframe for a task and allows project managers to better anticipate variance, leading to more realistic roadmaps and successful project outcomes.

While there are many types of estimators, few consistently hit the mark. It’s not about always providing three estimates but about understanding the nuances of estimation and striving for continuous improvement. If you can relate to any of the more negative types of estimator, ask yourself what actions you can take to improve your consistency and reliability.

What Your Estimates Say About You

By now, this should be clear: your estimates are more than just numbers - they are a reflection of your competency, consistency, and reliability. When you provide accurate and well-considered estimates, it demonstrates a deep understanding of your work and builds trust with your team and stakeholders. Consistency in your estimates signals that you can reliably gauge the scope of tasks, fostering confidence in your ability to deliver. On the other hand, frequent inaccuracies can lead others to question your expertise and dependability, potentially damaging your reputation. In essence, your estimates are a key factor in how others perceive your professional capabilities.

Improving Your Estimates

Having explored the variance, necessity, and importance of estimation, it's now time to focus on how to improve this critical skill. Estimation isn't just about guessing; it’s a craft that can be honed with the right techniques and mindset. Fortunately, there are many practical methods that aspiring developers can use to enhance their estimation accuracy. Let’s dive into some strategies to help you become a more reliable and confident estimator.

Knowing What You Know

Everyone loves a good four-box diagram, and one particularly relevant to estimation is the concept of unknown unknowns. By cultivating self-awareness and understanding the differences between what you know and what you don’t, you can factor in knowledge gaps and the potential for surprises in your nominal and pessimistic estimations. This approach helps you to be better prepared, justify your estimations, and support them with sound reasoning.

• Known Knowns - These are things you know that you know.

• Known Unknowns - These are things you know that you don’t know.

• Unknown Knowns - These are things you don’t realize you know.

• Unknown Unknowns - These are things you don’t know that you don’t know.

Let's look at this concept through the eyes of a worked example. Imagine you are tasked with improving the performance of a webpage by reducing the amount of upfront load and necessary database calls.

• Known Knowns - You may already be aware of the tools and techniques available, such as lazy loading, caching strategies, and optimizing database queries and have experience of using them in other projects.

• Known Unknowns - You might know that there could be performance bottlenecks within your current database structure, but at this stage you're not sure where they are or how significant they might be in regards to improving the performance.

• Unknown Knowns - You might have access to team members or resources with relevant expertise that you haven’t fully explored.

• Unknown Unknowns - While working through the problem you might discover unknown dependencies or interactions within the codebase that you weren’t aware of. It could be that code is more tightly coupled that you realised meaning that the change you were planning to make might have unintended knock-on effects throughout the wider system.

When you start to view problems through this lens it is easier to avoid overly optimistic estimations as you are bringing the possibility of unknown obstacles to your attention.

Get To Know The Codebase

Just as a surgeon wouldn't operate without a thorough understanding of human anatomy, software developers shouldn't work without a deep knowledge of the codebase they're working on. Fortunately, gaining deep knowledge of your codebase doesn’t come with a hefty price tag or years of training, but it can be just as rewarding for your professional career.

When you have a thorough understanding of the environment in which you're working, you minimise the risk of nasty surprises. This not only makes your estimates more accurate and reliable but also provides the satisfaction of becoming a true domain expert. Best of all, achieving this level of understanding is possible regardless of your experience.

For a deeper dive into practical methods for mastering your codebase, check out this detailed guide.

Provide a Range

We've already touched on this in Good vs Bad Estimation, but get used to providing a range of estimates instead of a single estimate. If your team only deals with one estimate currently, propose the idea of providing more than one. For example, workflow management tools like Jira often allow you to customise your tickets with as many pieces of information as you'd like, allowing you to represent all your estimates on the ticket. If the team shoots down your idea, then you can continue to implement the approach alone by communicating your optimistic, nominal and pessimistic estimates when you start a new piece of work.

Take Time to Reflect

While team retrospectives are a key part of agile software development, individual reflection on a task-by-task level is a technique that’s often overlooked. Yet, it’s something you can easily implement to consistently improve your estimation skills. By taking time to reflect at the end of each task, you can identify aspects you’re proud of and areas where you may have fallen short.

Consider a task you either grossly underestimated or overestimated. Reviewing why your estimate was off in hindsight allows you to apply that knowledge to future tasks. If you simply move on to the next task without reflection, you miss an opportunity to refine your ability to estimate accurately. Not only that, but reflection can also highlight areas for improvement in other aspects of your software development career, such as code quality, test coverage, and documentation.

Conclusion

Estimation is more than just a technical skill - it's a hallmark of experience and professionalism in software development. As we’ve explored, the ability to accurately estimate the effort and complexity of tasks is essential not only for the success of individual projects but also for the long-term trajectory of your career. Accurate estimations build trust, enhance collaboration, and drive better decision-making within your team and organisation.

Whether you’re just starting out or looking to refine your skills, remember that great estimators are made, not born. By understanding the common challenges, learning from your experiences, and continuously improving your knowledge of the codebase and your environment, you can become a more reliable and respected developer. Estimation is a craft that evolves with time, practice, and reflection. Embrace the journey, and you'll find that the rewards extend far beyond just hitting deadlines - they define your impact as a developer.

As you continue to hone this vital skill, keep in mind that your estimates are more than just numbers. They are a reflection of your competency, consistency, and reliability, influencing how others perceive your professional capabilities. So, invest the time to master the art of estimation, and watch it transform your work, your team’s success, and your career.

To succeed in a managerial role then, it is essential to master the art of navigating and mitigating snap judgements, personal flaws and cognitive biases. But how can you maintain self-awareness and stay true to yourself, while simultaneously fostering a positive culture conducive to success? Throughout the following paragraphs hopefully the answer to that question will become clear, but before we delve into a solution we must first better understand the problem.

What is influence?

Influence refers to the capacity to have an effect on the thoughts, behaviours, or actions of others. It involves the ability to shape or sway opinions, decisions, and outcomes, often through leadership, or example. Influence can manifest in various forms, such as social influence, where individuals impact each other's attitudes and behaviours within a group, or professional influence, where leaders guide and motivate their team members.

Now that we've defined what is meant by the term influence in the context of this article, let's now analyse how our choice of language and position of influence can sometimes lead to unintended consequences.

The impact of language

It is clear to see that a leader's actions and use of language extends beyond the immediate interaction from which it originates. Looking back at our definition of influence, I have highlighted what I believe to be the key points:

• To have an effect on the thoughts, behaviours, or actions of others i.e. what we say and do has the potential to immediately impact those around us and often in ways that isn't immediately obvious.

• To shape or sway opinions, decisions, and outcomes i.e. others might think highly of our opinions and passing comments could lead to unintended decision making and outcomes if taken out of context or not fully understood.

• Individuals impact each other's attitudes and behaviours within a group i.e. we are also influenced by those around us and should be conscious of the messaging that we permit others in the group to share.

Breaking down the definition in this way demonstrates how nuanced and subtle influence can be, as well as how important it is to be clear with our use of language. Any ambiguity is an opportunity to invite misinterpretation and confusion guaranteeing that the original intention is misunderstood. This is more noticeable with messaging tools like Slack and Microsoft Teams, where instant messages can be void of essential characteristics for meaning such as intonation, tone and emotion.

The dark side of influence is something that we don't usually consider in the moment but come to regret in future. Here is a recent example from LinkedIn where Duolingo's use of the word "quitter" was being interpreted as derogatory, rather than motivational/humorous which I assume their intention to have been. Reading the comments it is interesting to see how people's opinions differ based on their background and locality.

How influence shapes culture

While it's largely common sense that influence shapes culture, it is worth knowing why and how. Edgar Schein, a well known and respected management professor at MIT, argues that "culture and leadership are two sides of the same coin." Having spent his career as an organisational expert, his experience studying corporations has led him to believe that culture is not a collection of mission statements, slogans and values but instead a product of a leader's interactions with their teams.

Ron Friedman references and summarises Schein's research in The Best Place To Work, highlighting that there are four main ways in which a leader can influence culture:

• What leaders pay attention to (and what they ignore) i.e. where leaders decide to place their focus infers what they consider important and a priority. Always focussing on one item or always ignoring another, subconsciously suggests to the team what is and isn't important.

• Emotional outbursts i.e. what causes a leader to experience negative emotions such as anger, frustration and stress, signals what a leader truly cares about.

• Reactions to incidents and crises i.e. how a leader handles pressure and crisis creates a model for how team members will handle them in future.

• How leaders allocate rewards and status i.e. what actions and behaviours a leader chooses to positively reinforce are what others are likely to repeat and demonstrate.

Clearly then, even the most casual or innocent remark could have long-term implications and consequences that shape the future of a workplace culture. In the following section I will share some real life examples that I've noticed from my own experiences.

Examples from the workplace

When you take the time to reflect and analyse why the things are the way they are, you begin to notice correlations between the way leaders act and the environment that surrounds them. Here are some examples of what I have noticed over the years and how they might have affected culture both positively and negatively:

• Focussing on the edge cases - As we now know, what leaders pay attention to quickly permeates throughout the team. I've previously worked with engineering managers who have perhaps given too much attention to the edge cases of a particular piece of work. While sound in theory, after all no body wants to ship a broken feature, placing too much emphasis on finding edge cases created an environment in which things were overengineered and overcomplicated. Unfortunately, this impacted the feasibility of extending features and the refinement of new work was framed in the mindset of "what could go wrong" ultimately limiting innovation.

• Pandering to problem clients - When a client complains and is given preferential treatment in response to resolve their issue, it creates an environment in which he who shouts the loudest wins. It puts the client on a pedestal and elevates their position even above those in the team. Sadly, when this happens not only does the team find themselves in a position where they have to create one-off/temporary solutions, to often minor problems, but it also comes at the price of working on something else. From my own experiences, when this happens it impacts the engagement, motivation and morale of those involved as well as the potential future of the business.

• Promoting ownership and accountability - If you're looking to create trust and a high performance team, then promoting ownership is one way to do so. When a manager cares deeply about accountability and rewards those who hold themselves accountable for their actions, it signals to others that ownership is important. Working in an environment where ownership is not only encouraged but expected, wonderful things happen. Team member confidence increases, collaboration happens naturally and issues are resolved quickly.

With these examples in mind, lets turn our attention to consciously building positive culture through the use of Schein's observations and our understanding of language and influence.

Building positive culture

In the course of this article we have mostly concentrated on the negative consequences of influence. However, while it is possible to create a negative culture almost absentmindedly, it is just as easy to create a positive culture consciously.

Edgar Schein's key observations on corporate culture provide us with a framework in which we can operate. By taking advantage of the knowledge and the psychology behind his observations, we can use them to intentionally influence our workplace environment. This is the ripple effect in action.

By understanding and leveraging these points you can influence change in almost any area:

• Consciously focus on the things you care about as a leader and use praise and recognition to promote positive reinforcement.

• Limit your emotional outbursts or use them, sparingly, to your advantage by ensuring its over something that you deem important.

• Keep a cool head in times of crisis and use them as an opportunity to lead by example.

As such if communication is something that is important to you, here is just one in which you can use the actions above to influence a more communicative culture:

• Give recognition and praise to good communication, be it client facing, internal documentation or otherwise.

• Don't ignore bad communication as that would suggest that it is permissible. Instead highlight how it can be improved through actionable feedback.

• Demonstrate that communication is important by creating metrics/OKRs and making it a focus point. For example, set a coverage goal for internal documentation or during refinement sessions make a point to consider what communication might be needed both internally and externally.

• Use emotion tactfully. If there is a particularly bad example of communication (or lack of communication) you could consider using emotion to signal how important it is that it doesn't happen again. However, outbursts of emotion could have other side effects such as loss of team trust and fear of conflict.

• Finally, if you find yourself in the unfortunate position of being in a crisis, use it as an opportunity to demonstrate good communication and lead by example. This could be done as easily as emphasising the need to communicate the incident internally e.g. by communicating the issue to support so they can be proactive rather than reactive to incoming help cases. Or it could be used as a learning opportunity by writing an incident report/conducting a post-mortem.

While the given example of improving communication is a simple one, hopefully it illustrates the potential of the underlying framework.

Reflection

To conclude then, these days it is simply not enough to only focus on your team, you also have to focus on yourself. Without self-awareness and introspection to keep yourself in check, the signals you subconsciously transmit could set your team and workplace down a negative path. The consequences of which you could be dealing with for years to come. As such, take the time to reflect and ensure you are fostering a positive workplace culture rather than a negative one. Regularly ask yourself the following questions:

• Are you focussing on the right tasks?

• Do you show emotion at work?

• How do you act under pressure?

• Which behaviours do you publicly reward?

• What language do you use when you talk about team members?

By taking action, you are committing to building a workplace where influence is wielded responsibly, and language is a force for positive change. Remember, the impact of your actions today will shape the future of your team and organisation. Take the initiative and start consciously building a workplace culture that enables you and your team to thrive.

Recommended Reading

• The Best Place To Work by Ron Friedman

• Organisational Culture and Leadership by Edgar Schein

In this article, I shed light on my initial, somewhat naive, expectations of engineering management and contrast them with the actual experiences I have so far encountered in my role as Lead Developer at Unity5. It's essential to acknowledge that every company has its distinctive characteristics and ways of working, so you may encounter variations of what I detail below. Nevertheless, I aim to provide you with valuable insights that can serve as a guiding framework if you're contemplating going beyond the code and into management.

Here's a closer look at what I initially expected versus what I've learned through experience:

Expectation: To feel confident in all aspects of my role I would require sufficient management training.
Reality: Although I did participate in a one-day management workshop, which offered some valuable insights, it primarily reinforced that becoming a comfortable and effective manager would depend more on gaining experience rather than formal training. The realisation that it's acceptable not to have all the answers, has given me the confidence to fully embrace the role knowing that whatever happens, I'll be more prepared for future challenges.

Expectation: My workload would change from mostly technical duties towards mostly managerial ones.
Reality: Aside from conducting quarterly performance reviews and holding regular one-to-ones, my daily tasks have remained largely consistent. I continue to dedicate most of my time to feature development, code reviews and deployments. I'd estimate that on average my workload is split between roughly 80% development and 20% management each week.

Expectation: There might be a change in the dynamic within the team as I move from being a peer to a manager.
Reality: Becoming a manager brought about a shift in the team's dynamics but fortunately, it was a positive one. As we transitioned away from a flat team structure, team members began to feel that their voices were being heard more effectively and that they were receiving more personal attention. This has led to an increase in the engagement and job satisfaction of those in my team.

Expectation: I would have the time to think of big-picture ideas and processes.
Reality: Due to my continued involvement in product development, to get the time I need to think about things on a larger scale, I need to carve it out and reserve it for myself. As such, I typically allocate the last hour of each working day for "focus time" so that I can work on the things that are important to me.

Expectation: I would be involved in a lot more meetings.
Reality: A common cliché of engineers turned managers is that they are taken out of the code and dropped into a neverending cycle of meetings. However, I've found that the frequency of meetings I attend doesn't significantly differ from my time as a senior developer, though this will vary depending on the company.

Expectation: Working longer hours would become more the norm rather than the exception.
Reality: While I occasionally work outside of regular hours, it's not something I do regularly. That said, I can understand why I initially thought it might be necessary and why other managers may feel compelled to do so. If you find yourself unable to safeguard your time during working hours to focus on essential tasks, working outside of regular hours might seem like the only option. However, this just emphasises the significance of allocating dedicated time for yourself and for tasks that only you can do.

Expectation: I would more easily be able to bring about change.
Reality: Even within a fast-paced environment, introducing change can pose challenges. Not only does change necessitate questioning the status quo, but substantial changes also depend on gaining the support of others. In the end, it's not merely about enforcing change but rather about influencing it. This is something I didn't completely grasp until I stepped into a management role, and I acknowledge that I may have been somewhat ignorant of it beforehand.

Through reflecting on my journey into management and writing the above, it's clear that my initial expectations didn't align with the realities I've encountered, but in a surprisingly good way. Numerous concerns I had have been addressed, and my initial negative assumptions have been proven wrong. I am now a year into my new role and the position still provides me with a satisfying and meaningful challenge, offering opportunities to enact change within both the team and the larger organisation. While, in hindsight, I might have approached some aspects differently, I don't regret my decision to go beyond the code. I hope this introspection helps you if you are considering doing the same.