Dark Mode

Understanding Programmers

By Santi on July 02, 2019


Programmers are often stereotyped in series and movies: nerdy, antisocial, oblivious to fashion and sometimes even personal hygiene. A particular kind, the hacker, tends to be associated with darkness: writing code on a black terminal inside a dimly lit room, with a hoodie on. Though some coders tend to to fit into the stereotype fairly well (I even loved the checkered shirt patterns before I started programming professionally); real life, as usual, is a bit more nuanced than that.

For society in general, and business people in particular, the software developer’s motivations and aspirations are hard to understand. On other fields, employees are thrilled when offered a promotion to a position with a higher salary, a nicer office, and a better parking spot. Coders will sometimes pass on it, and be happy just to keep staring at the monitor all day while writing some arcane computer code few people can understand. Or accept it, and try to find ways to keep coding and reviewing code, even if it doesn’t fit their job description anymore.

This article explains the work and mindset of software developers, equipped with some hard data (as accurate as it can get with social sciences) and some conclusions based on direct observation.

Nature and Value of Programmer’s Work

A programmer is someone who provides hardware with instructions for the automatic execution of a task. This does not always involve writing code: if an Operations Analyst who works at a financial institution automates tasks by recording an Excel Macro, even if he does not directly write code, he programs. There are also companies like Zapier which make it easy to automate processes without explicitly writing code. This trend of non-explicit coding will grow as machine learning is replacing tasks where programmers were needed (machines learn the best parameters and humans decide the best way to train them). Even when the software developer is required, higher level (more similar to plain English) programming languages like Python are gaining popularity.

This article is about the competent vocational explicit programmer, someone who is good at producing, understanding, and improving code, and also enjoys it very much. This persona also understands how to run code into existing or new machines (infrastructure), with little instruction or supervision. Most importantly, he or she (usually he, according to statistics) must be able to learn on the spot, which requires solid knowledge of the fundamentals. Tools change fast, but principles and theories behind them don’t.

How they occupy their working time is easy to describe: they read, write, test and re-write code. Most of the time is actually spent fixing errors (known as debugging) and going through documentation (learning). The program needs to run without errors and serve its purpose, but also, it is important that the code is simple enough for humans to understand (for another programmer or the future self of the programmer who wrote it), as it is read more times than it is written.

The value of this work, it is said, is to automate processes, which increases efficiency, but this is a misrepresentation. A video game programmer does not automate amusement, and a social network programmer is not making relations more efficient. They are creating, improving, or maintaining software, a technological product with very special characteristics. The business value of the software developer’s jobs is what can be done with the software they develop.

What makes software unique? First, no other kind of engineering makes experiments so cheap and fast. Open a terminal, type the magic words, check if it works, and feel a bit of either dopamine, if it does, or cortisol, if it doesn’t. On the business side of software, fixed costs (as the required hardware and infrastructure) get exponentially lower following Moore’s Law, and the only variable cost is developer’s time, so once a product is finished (a meaningless concept in software), the marginal cost is around 0. With volume, some technical problems can arise, such as scaling infrastructure, but this is also becoming easier and cheaper than ever to manage thanks to the cloud. As with any product, however, there will be some growing costs involved, such as sales, marketing, and support. Software also gives user quick, precise, and predictable feedback for their actions, making communication less noisy -as in signal versus noise- than it would be with human interaction.

Due to all these features, software is usually more efficient than its physical world equivalent (think letter vs email), but this is a possibility, not a given. It is true that developers have an unhealthy obsession with efficiency, but writing code is not a valuable activity per se. If the task that is automated is worthless, no efficiency can be gained, and some low tech systems are just good enough, so there is little a computer can do to help (think Dabbawalas)

Programmers are also architects, even if the job title does not state so. They need to think about how the whole and the parts will interact, and design solutions that don’t collapse the structures. They need to model how things are (database modeling, data structures), how things respond to input (user interaction), and how things change (algorithms). The power to create abstractions from real life systems should matter to the company, as it can bring many good ideas beyond the computer.


With the number of software developers in the millions, all generalizations are hasty. If we accept a lax definition of programmer (i. e.: anyone who programs), then there are almost no conclusions we can draw, since the barrier to entry has never been lower. So assume we are talking about someone writes code well and habitually, and likes it.

The mindset is that of the technologist: his/her objective is building powerful products, things that can alter reality significantly, even if the effect is not valuable for society. When one feels awe for the SpaceX Falcon launches, without thinking how population in general benefits from them, one is thinking as a technologist, and there is nothing wrong with that. Businessmen, on the other hand, do not have the luxury of ignoring the market value of their products. The mindset of the businessman is: build and sell something valuable for society. This does not mean that entrepreneurs are the good guys, as the perceived and actual value of products vary widely, and time does not always make those quantities converge.

Clive Thompson, author of Coders: The Making of a New Tribe and the Remaking of the World,explains on the subject:

The coders would often get weirdly obsessed with optimizing seemingly silly things, and that's exactly how real-life coders think

An example of this would be the tabs versus spaces scene on HBO’s series Silicon Valley, where two programmers who were dating split up over an argument about code formatting which has no effect on its functionality.

Thompson also states that:

“Halt and Catch Fire” was another good [depiction of coders], showing how a super-talented coder could simultaneously be amazing at writing code but terrible at imaging a useful product that regular people would want to use. That’s very realistic.

I attended a Facebook talk about self-repairing code. They explained that if they found a memory leak in one of the servers, turning it off and on again was the business-savvy thing to do. The neurotic inside the software developer needs to know what is wrong and fix it, but the businessman assesses the effort and return of said decision (return on investment or ROI). The programmer focuses on the details, because they matter a lot to the computer, but they can add little value to the company.

It was not uncommon for a programmer to turn specs (specifications about what software should do) into computer code without thinking about the consequences, but this has started to change on the last few years, with employees on Amazon, Google, and Microsoft protesting business decisions they deemed not beneficial for society. Also, many employees in non-technological careers would find it hard to explain how their work impacts the bottom line of the company, much less evaluate if they are improving society as its effect.

One might expect that being so able at organizing complex code, they would excel at organizing people, that is, being a manager, but this isn’t always the case. Developers don’t like ambiguity, and nothing provides less reliable behavior and feedback than people. Personality is not so fixed that people can’t adopt a different mindset, but it can be hard. One of my former bosses, when being offered a promotion, was told by his superiors: “Are you ready to stop programming?”.

Clive Thompson also compares the founding fathers to programmers:

Hamilton, Madison and Jefferson entered ‘The Room Where it Happens’ and Hamilton [came] out having written 20 lines of code that basically said, ‘Washington is going to be this center of power, and there’s going to be the national bank,’. They pushed their software update, and completely changed the country.

The big difference is that with software it is easy to run experiments. In politics, it is almost impossible, so programmers don’t like it.

Coders should excel at resilience (tolerating frustration), since code can become complex fast and errors are bound to appear. They also need to be constantly learning new methods and tools, since software changes fast, sometimes because better processes are discovered, and sometimes just following fashion.

The cognitively demanding task of programming can be addictive because it induces a state of flow, in which time doesn’t seem to pass. This is why programmers usually enjoy it so much. But patience and discipline are muscles, and mentally stimulating work is fun, but tiring, and it is more difficult to socialize when tired, as Robert M. Sapolsky describes in the book Behave:

[...]if you increase people’s cognitive load, they become less prosocial toward strangers. Similarly, when people are hungry, they are less charitable—hey, quit bellyaching about your problems; my belly is aching. Make people feel socially excluded and they become less generous and empathic.

In companies, software development happens in teams, but coding requires being alone, intensely concentrated for anything more than a very simple feature. Pair-programming is a methodology that is gaining traction, but if the thinking of coding is increased by the thinking of communication, one can infer that is not very efficient. The jury is still out.

There is also some feeling of power which comes from being able to command the bit army. With its firepower, a single coder can have an enormous effect on the world. In the series Mr. Robot, Elliott is able to fight against the Dark Army because of his prowess in the computer terminal.

Sometimes programmers wear their particular uniform: hoodie, checkered shirt. Or they might dress very casually, or with dark clothes. This can have many interpretations:

  • I am an engineer, I don’t like business so don’t bother me with it.
  • I don’t care about fashion. Just let me do my job.
  • I am important enough to the organization and my skills are in-demand enough that I can dress however I want.

They just want to be left alone to concentrate, they came to program, not to socialize, and efficient as they are, socializing and choosing what to wear is a waste of time. Let them wear their hoodie and listen to the noise-canceling headphones.


The company should do everything to keep all its people as motivated and happy as possible. This is especially easy when it is free. For knowledge professionals, money and perks are nice, but motivation depends on autonomy, mastery, and purpose.

When it comes to people’s wants, one should not generalize. They have their unique preferences and personalities, so understand these differences and optimize accordingly. In general, an organization should trust its knowledge professionals, not only because it is the right thing to do, but because knowledge work is highly non-linear and almost impossible track properly. This a two-way street; employees should make sure they keep work quality and quantity, work ethic, and communication.


There is a discussion on the coding community about whether if it even makes sense to estimate hours, with good reason. Delivering a new feature can be enormously complex and there can be many unknown unknowns (things that you don’t know that you don’t know). Some might feel that this is a very inefficient form of micromanagement, and hour estimates are sometimes treated as deadlines.

Some creative freedom is necessary (programming languages, infrastructure, methodology, and code conventions), but too much of it can be a disaster for the team and the code base. A good trade-off is allowing the development team to choose the coding style and technologies as much as possible, but then making sure that the standards have been properly documented and applied.

Remote work and geographically distributed teams are becoming increasingly popular in software companies. This way, companies are not limited to their immediate cities to find scarce developers, and even for those who are able to commute, knowing they have the option to work from home establishes trust.


An engineer enjoys picking up good tools and keeping them sharp. Depending on the tool, this might not be on the interests of the organization. Great technical management plays a big role here: they should listen to Devs and assess the technical consequences of new tools and methods, such as infrastructure, team organization, and programming languages and frameworks. Then management can decide which projects are best to implement these new tools with minimal risk and which developers should work on them, making sure all programmers are properly challenged and engaged.

Provide high-ranking positions which don’t involve managing people, such as Software Architect and Subject Matter Expert (SME). Some coders hate meetings and office politics, and provide enormous value on the technical side, so why move them to work that won’t make anyone happy? Not every developer wants to be a manager, or would make a good one.


Communicating and aligning purpose doesn’t mean changing the company’s slogan to “Make Code Great Again”. Even if some programmers might not care, it is nice to see that your work contributes something to the world, it provides a sense of accomplishment. If software made a client happy, or the quality of a product was quantitatively increased, tell the team.

Social value didn’t matter so much to them just until recently, but it is starting to, as competent programmers are in such demand and have the luxury of being able to choose companies which align with their values. When hiring, make sure to explain what the company does for society and what its values are.


Understanding the Mind of the Coder | SmithsonianMag
Coder’s Urge to Kill Inefficiency | Wired
The End of Code | Wired

Further Reading

Coders: The Making of a New Tribe and the Remaking of the World
Working with Coders: A Guide to Software Development for the Perplexed Non-Techie

‹ Previous: Statistics, Not Anecdotes Next: Software in the House ›