What Nobody Teaches You About Working in Software

When you learn to write software, you learn a set of skills that are necessary for the job and insufficient for the career. You learn how to think logically. How to break a problem into smaller problems. How to read documentation and find answers and build things that work.

Nobody teaches you how decisions actually get made in engineering organisations. Nobody teaches you why the best technical solution sometimes does not get built. Nobody teaches you what visibility means and why it matters more than most people are comfortable admitting. Nobody teaches you why two engineers with identical technical ability can have careers that diverge so dramatically over ten years that they end up in different worlds entirely.

These things get learned, eventually, through experience. Through watching, through getting things wrong, through conversations with people who have been around long enough to be honest about what they have observed.

This article is an attempt to compress some of that learning. Not all of it can be transmitted this way. Some of it requires living through it. But some of it can be said directly, and the people who hear it early have an advantage over the people who have to discover it the hard way.

The technical problem is rarely the hard part

The first thing that surprises most people when they start working in software professionally is how much of the job is not about code.

A rough breakdown of what the job actually involves, after the first year or two: some portion of time writing and reviewing code, some portion in meetings and planning discussions, some portion communicating through written documents and messages, some portion understanding what the actual problem is before trying to solve it, and a significant portion navigating the human dynamics of getting things built in an organisation where many people have different opinions about what should be built and how.

The technical part of this list is real and important. It is not the bottleneck for most people whose careers are not going the way they want.

The bottleneck is usually the last item: navigating the human dynamics. Not office politics in the cynical sense, although that exists too. The more fundamental challenge of working in a context where multiple people with different incentives, different information, and different mental models of the system have to collectively make decisions and produce results.

The engineer who can write excellent code and cannot navigate this context will have a frustrating career. They will see their good ideas not get implemented. They will see worse solutions get chosen because someone else advocated for them more effectively. They will feel that their work is undervalued without being able to explain exactly why.

The engineer who cannot write excellent code but can navigate this context will have a different kind of frustrating career. They can get things done but they cannot produce the quality of output the work requires.

The engineers whose careers go well are usually the ones who understand that both matter and invest in both deliberately.

Decisions get made before the meeting

One of the more disorienting realisations for people new to engineering organisations is that the formal decision-making moments, the architecture review, the planning meeting, the design discussion, are often not where the actual decision gets made.

The actual decision often gets made in the conversations that precede the meeting. Someone who wants a particular outcome talks to the people who will be in the room before the room convenes. They understand where the resistance will come from. They address it one-on-one before it becomes a public objection. By the time the meeting starts, the outcome is frequently already determined. The meeting is the ratification, not the deliberation.

This is not corruption. It is not even necessarily bad. It is how groups of people with different positions and different information tend to make decisions. The formal meeting is often too high-stakes and too time-pressured for real exploration of disagreement. The conversations before and after the meeting are where the real thinking happens.

The practical implication is significant. An engineer who has a good idea and brings it to a meeting cold, without having talked to the relevant people beforehand, is at a disadvantage relative to an engineer who has done the same work of understanding the landscape and addressing the concerns before the room convenes. The technical quality of the idea is the same. The probability of it being adopted is not.

This is not a cynical observation. It is a practical one. The work of getting a good idea adopted is real work. It requires understanding the concerns of the people who will evaluate it. It requires being willing to modify the idea in response to those concerns, which is often how the idea gets better anyway. The engineer who treats this work as beneath them, as politics to be avoided in favour of letting the technical merits speak for themselves, is opting out of a large portion of how decisions actually get made.

Being right is not enough

This one takes most people a long time to accept because it seems deeply unfair.

In engineering, as in most professional contexts, being right about something is a necessary condition for being effective but not a sufficient one. The right answer that nobody believes is less useful than the slightly less right answer that the team commits to and executes well.

The engineer who is frequently right in technical discussions and communicates it poorly will have less influence than the engineer who is sometimes right and communicates it well. This feels unjust. It is the normal operating condition of human organisations, and understanding it is the prerequisite for doing something about it.

Communicating well in this context does not mean being charismatic or politically savvy or saying things people want to hear. It means understanding your audience well enough to explain things in terms that are meaningful to them. It means understanding the concerns of the person you are trying to convince before you start talking, so that what you say addresses those concerns rather than bypassing them. It means being honest about uncertainty, because an argument that acknowledges its own weaknesses is more convincing than one that pretends not to have any.

The engineers who are most effective at getting good technical decisions made are not always the ones with the best technical judgment. They are the ones who combine good technical judgment with the ability to communicate it in ways that other people can act on. Both parts of that sentence are important.

Visibility is real and it is not shameful

There is a strain of engineering culture that treats self-promotion as distasteful. The work should speak for itself. The good engineer does the work and lets others notice. Drawing attention to your contributions is unseemly.

This is a cultural value that protects the people it benefits and disadvantages the people who follow it sincerely.

Visibility matters. The engineers who get good assignments, who are considered for interesting projects, who are promoted at the pace their ability warrants, are not always the ones who do the best work. They are the ones whose work is known to the people making those decisions. Sometimes these are the same engineers. Often they are not.

The way visibility gets built is not through self-promotion in the sense of talking loudly about your own accomplishments. It is through being the person who communicates clearly about what they are working on, who surfaces problems early rather than late, who participates in discussions in ways that give their colleagues and their managers an accurate picture of how they think.

An engineer who does excellent work in silence and then is frustrated to find that someone whose work is less excellent has been given an opportunity they wanted is experiencing the predictable outcome of having opted out of the communication that creates visibility. The solution is not to do less work. It is to communicate about the work they are doing more consistently.

Writing well helps. The engineers who can explain what they built, why they built it that way, and what they learned from building it, in clear written language, have a visibility advantage over the ones who cannot. Writing creates a record. It distributes understanding. It shows how someone thinks in a way that the code alone does not.

The work you are not doing is more important than the work you are

Most engineers spend their careers doing the work that is assigned to them. The requirements arrive. The work gets done. The requirements arrive again. This is not wrong. It is the job. But it is a particular way of doing the job that leaves significant value on the table.

The engineers whose careers compound most effectively have developed the habit of noticing work that is not being done and either doing it themselves or making the case for it to be done. The undocumented system that everyone is afraid to touch. The repeated manual process that nobody has automated because it belongs to everyone and therefore to no one. The architectural problem that everyone sees and nobody is addressing because it requires a conversation that feels difficult.

This work is often not rewarded directly. It does not come with a ticket number or a sprint allocation. It requires initiative and a certain amount of willingness to do something that was not asked for, which carries the risk of being told it was not needed.

The engineers who take this risk consistently develop something that no amount of ticket-completing can develop: a reputation for seeing what needs to be done rather than waiting to be told. This reputation compounds. The people who have it get asked for their opinion on what should be done. They get included in conversations about direction. They develop influence over the shape of the work, which is the kind of influence that makes the work more interesting and the career more satisfying.

The assignment does not determine the ceiling. The choice of whether to look beyond the assignment does.

The colleague you help for no reason

There is a category of investment that has among the highest long-term returns in an engineering career and that almost no career advice talks about: being genuinely helpful to the people you work with, with no expectation of return.

Not networking in the transactional sense. Actually helping. The junior engineer who is stuck on something you have encountered before. The colleague on another team who is trying to understand a system you know well. The new hire who needs someone to explain how things actually work rather than how they are documented to work.

This is not altruism in the sense of sacrificing your interests for others. It is an investment in a network of relationships where people know from experience that you are someone who helps, which means they are more likely to help you, more likely to think of you when opportunities come up, and more likely to advocate for you in the conversations you are not in.

The reciprocity is real but it is not transactional and it is not immediate. Someone you helped three years ago, who has since moved to a different company or a different team, will remember that you helped them in a way that they will not remember much of the other professional interaction they have had. People remember being helped when they were stuck. They remember it accurately and they remember it for a long time.

The career built on genuine helpfulness looks different from the outside than the career built on individual achievement. It is more distributed. The contributions are harder to point to directly. The network is broader and the relationships in it are warmer. When something goes wrong, the person with this career has more people who will help without being asked than the person who has spent the same time accumulating individual accomplishments.

The thing that compounds and the thing that does not

Engineering is a field where the gap between a good career and a great one is often not explained by the gap in technical ability. Technical ability matters enormously early in a career, when the job is primarily about producing output. It matters less over time as the job becomes increasingly about judgment, influence, and direction.

The thing that compounds is judgment. Not the accumulation of knowledge about specific technologies, which depreciates as the technologies change. The accumulation of pattern recognition about how systems fail, how organisations make decisions, how problems that look new are often variations of problems that are old. This kind of judgment is built through breadth of experience and honest reflection on that experience. It does not accumulate automatically. It requires the habit of asking, after something goes wrong or right, what it was that made it go that way.

The thing that does not compound is busyness. The engineer who is always executing, always productive, always delivering, but who has not invested time in understanding the patterns behind the work, will reach a point in their career where the execution speed that carried them through the early years is no longer sufficient. The job has become about more than execution and they have not prepared for it.

This is one of the most common career stalls in software engineering. Not a failure of ability. A failure of preparation for what the job becomes as the career advances.

The preparation is not complicated. It is reading broadly, including things outside software. It is having conversations with people who are further along than you and asking them what they wish they had understood earlier. It is reflecting on your work with enough honesty to learn from it rather than just completing it. It is treating the understanding of how things work, not just the ability to make them work, as something worth investing in deliberately.

What this industry is actually like

Software engineering is one of the more meritocratic professions in the sense that technical ability is a real input to outcomes and cannot be entirely faked. It is less meritocratic than it presents itself in the sense that technical ability is one input among several and not always the most important one.

The people who do best over long careers in this industry are usually the ones who understand this early enough to act on it. They invest in their technical ability because it is foundational and because the work requires it and because it is one of the things that genuinely brings them satisfaction. And they invest with equal seriousness in the other things: communication, judgment, the ability to navigate human systems, the habits that build reputation and relationship over time.

None of this is taught in a curriculum because it is uncomfortable to teach. It implies that the profession is not a pure meritocracy, which is a claim that many engineers resist. It implies that things other than technical excellence matter, which feels like it devalues technical excellence.

It does not devalue it. It contextualises it. Technical excellence in the absence of the other things is an engine without a steering mechanism. Powerful. Capable of producing significant output. Not reliably pointed at something worth producing.

The engineers who figure this out have better careers than the ones who do not. Not always in the sense of title or money, though often there too. In the sense of doing work that matters to them, in environments they have helped shape, with people they have genuinely helped along the way.

That version of a career is available to more people than pursue it. It requires knowing it exists, which is what the curriculum forgot to mention.