What Makes a Good Developer and What Company Communication Has to Do With It

It all started with a colleague’s post: As software developers, we often think our job is to develop software, but, really, that is just the means to an end, and the end is to empower business to reach their goals. Your code may be elegant, but if it doesn’t meet the objectives (be they time or business) it doesn’t f***ing work. From a business point of view, what makes a good developer (in fact, any employee, from the most hands-on roles to leadership) is how they influence the entire system — in our case, the business itself. A useful way to judge a solution’s quality is to ask whether it is a global or local optimisation. Local optimisation improves something on a narrow scale, while global optimisation benefits the whole. Example: when my family and I go on a short weekend trip, I make sure we have everything we need, check that no one forgets anything, and see that everyone is ready on time so we don’t miss any stops. That looks like a sensible adult approach. Yet behind those tense “perfect” preparations, the global goal — having an enjoyable family trip and creating warm memories — can be lost. Missing a restaurant before it closes is not so bad if you can buy hot dogs and sit together on a bench at sunset, discussing the journey. Sometimes local optimisation harms global optimisation. To achieve global optimisation, we need a global view. For instance, we once had to show a working prototype while a competitor was entering the market with the same product. We knew speed, not build quality, was the goal. When Marketing could start attracting clients to the prototype, we gained time to rewrite parts of the system and refine the long-term architecture, and the business won an advantage. The opposite situation: our core product — the revenue locomotive — hit technical limits. Re-building it was not a hypothesis; it was a product that was certainly needed, demanding a solid approach that drew on all current experience and looked ahead. Companies usually have solid bottom-up communication — daily stand-ups, quarterly OKRs, reports, and so on. Top-down communication is often poorer: annual or quarterly demos, and a little more. In such demos, people forget who the end user is, and numbers look like mere figures — clear to executives, unclear to staff. Linking company strategy with tactical decisions is hard without expertise. It’s just as hard for a CEO to understand a junior developer’s report. The data flow must therefore be multistage and bidirectional, moving through the management chain both upward and downward. An individual contributor can hardly influence this; establishing feedback loops is management’s responsibility, and the business must be the first to care. Still, contributors should show interest and demand this communication. What I do personally, within the power of an ordinary developer Ask for more context in team meetings — why we do something and what we aim to achieve — so the whole team hears the answer. Remember what’s shared at company demos and, crucially, link what we do, what other departments do, and our goals. Take an interest in what neighbouring departments are working on, talk with colleagues, learn about their problems, and help with cross-department tasks. Justify my decisions by referring to global goals; this keeps them at the front of my mind for me and for the team. To see the full picture, an individual contributor must navigate how the business is structured, which markets it serves, who its audience is, and so on. That knowledge is far beyond ordinary job duties, and no one expects it to be as deep as management’s. Yet it lets us propose solutions that benefit the entire company and become the in-demand specialists we aspire to be.

May 1, 2025 - 20:58

What Makes a Good Developer and What Company Communication Has to Do With It

It all started with a colleague’s post:

As software developers, we often think our job is to develop software, but, really, that is just the means to an end, and the end is to empower business to reach their goals. Your code may be elegant, but if it doesn’t meet the objectives (be they time or business) it doesn’t f***ing work.

From a business point of view, what makes a good developer (in fact, any employee, from the most hands-on roles to leadership) is how they influence the entire system — in our case, the business itself.

A useful way to judge a solution’s quality is to ask whether it is a global or local optimisation. Local optimisation improves something on a narrow scale, while global optimisation benefits the whole.

Example: when my family and I go on a short weekend trip, I make sure we have everything we need, check that no one forgets anything, and see that everyone is ready on time so we don’t miss any stops. That looks like a sensible adult approach. Yet behind those tense “perfect” preparations, the global goal — having an enjoyable family trip and creating warm memories — can be lost. Missing a restaurant before it closes is not so bad if you can buy hot dogs and sit together on a bench at sunset, discussing the journey. Sometimes local optimisation harms global optimisation.

To achieve global optimisation, we need a global view.

For instance, we once had to show a working prototype while a competitor was entering the market with the same product. We knew speed, not build quality, was the goal. When Marketing could start attracting clients to the prototype, we gained time to rewrite parts of the system and refine the long-term architecture, and the business won an advantage. The opposite situation: our core product — the revenue locomotive — hit technical limits. Re-building it was not a hypothesis; it was a product that was certainly needed, demanding a solid approach that drew on all current experience and looked ahead.

Companies usually have solid bottom-up communication — daily stand-ups, quarterly OKRs, reports, and so on. Top-down communication is often poorer: annual or quarterly demos, and a little more. In such demos, people forget who the end user is, and numbers look like mere figures — clear to executives, unclear to staff.

Linking company strategy with tactical decisions is hard without expertise. It’s just as hard for a CEO to understand a junior developer’s report. The data flow must therefore be multistage and bidirectional, moving through the management chain both upward and downward. An individual contributor can hardly influence this; establishing feedback loops is management’s responsibility, and the business must be the first to care. Still, contributors should show interest and demand this communication.

What I do personally, within the power of an ordinary developer

Ask for more context in team meetings — why we do something and what we aim to achieve — so the whole team hears the answer.
Remember what’s shared at company demos and, crucially, link what we do, what other departments do, and our goals.
Take an interest in what neighbouring departments are working on, talk with colleagues, learn about their problems, and help with cross-department tasks.
Justify my decisions by referring to global goals; this keeps them at the front of my mind for me and for the team.

To see the full picture, an individual contributor must navigate how the business is structured, which markets it serves, who its audience is, and so on. That knowledge is far beyond ordinary job duties, and no one expects it to be as deep as management’s. Yet it lets us propose solutions that benefit the entire company and become the in-demand specialists we aspire to be.