The Mindset of the Software Developer

Coders are as unique as the code they write and the services they are trying to create.

Which is not to say that they dont occasionally share similar characteristics or inclinations. JL

Dan Quine comments in Medium:

Writing code is only a tiny part of what developers do — most of the work involves solving complex abstract problems. Developers love to  take code that does one specific thing and turn it into a Swiss Army Knife that can do many different variants of that. This can be a useful instinct. But, over-generalization can end up with code that tries to do so many different things that it fails to do any of them well. Every software developer is of course completely unique.

Disclaimer: every software developer is of course completely unique; each one thinks in a very different way about the world. I have included this disclaimer because every developer believes this to be true.

That said, many developers think about the world in similar ways. Here are some of them.

Take it apart to see how it works

Developers have an endless fascination with how things work. Every time they look at a system, they wonder — how is that done? How could I make one? How can I make it better. They want to take it apart to see what makes it tick.

This applies to software, but also to vehicles, radios, lamps, the lifts in your building and, if you are really lucky, a dead cat.

What happens when you give a developer a new digital camera (photo: Steve Jurvetson)

Solve problems

Developing software is all about problem solving. Writing code is only a tiny part of what developers do — most of the work involves solving some really complex abstract problems.

Developers are fascinated with problems of all sorts, so you’ll often find them solving crossword puzzles, playing Tetris or out geocaching.

Decompose

Driven by the need to understand how things work, a key feature of the developer‘s toolset is reducing a thing into its smallest components. Small things are easier to understand and build. once you have a set of components, the can be assembled back into the original thing, or into something completely new.

The formal term for this is decomposition — breaking something down into its components, which in turn can be broken down into smaller components and so on, until you are down to the simplest possible units.

You’ll often find developers arguing about the best way to decompose an object. In the real world, the ways to break down an object are constrained. In the virtual world where you are not subject to the laws of nature, there will be many different ways to break an object down into logical components.

Automate

Developers are lazy, but in a very special and specific way. If you ask them to do something twice, they’ll immediately want to build a program to do the repetitive task for them. They have a very short attention span for things they have done before, and are quite happy to spend days writing code to avoid redoing a 5 minute task.

This is not always a good idea:

Randall Munroe’s take on the obsession with automation

Compose

Developers love to pull things apart and to automate tasks, both of which result in small units of code that do useful things. The next step is to arrange these into larger blocks that do new, interesting things. This is composition and a lot of the craft of software engineering is how best to compose components into a working, reliable system.

You’ll hear a lot of talk about architectures: how the pieces fit together into a sensible whole. These high-level structures can help developers build large, complex systems in a manageable way.

Generalize

Developers love to generalize — take some code that does one specific thing and turn it into a Swiss Army Knife that can do many different variants of that thing. This can be a useful instinct — you don’t want a hundred slightly different bits of code that do almost, but not quite, the same thing.

But, over-generalization is dangerous. You can end up with code that tries to do so many different things that it fails to do any of them well. This sort of code tends to be extremely complex as it tries to handle a vast number of edge cases. The skill is knowing when generalizing saves you time and complexity, and when it goes too far. Developers are always trying to find that dividing line.

Twain, as always, has a pertinent quote

Abstract

Abstraction is a key idea in computer science. It is a way of hiding the details of how something works, so other developers only needs to know what it does. This idea is crucial to building large systems.

Developers are intrigued by abstraction and like to use it outside the world of programming. This is one of the reasons they love to categorise everything — music, art, railways, philosophy, types of short-haired dogs. Once you have a coherent category, you have an abstraction that allows you to talk about the world in short-hand.

Craft

Software development is a craft, and developers take huge pride in their work. The feeling of shipping a great product is similar to the feeling that a painter might get from exhibiting their work, or a carpenter might feel at completing a new table.

Great developers get very frustrated if they are forced to produce shabby work.

The artisan’s workbench. It can be a little messy, but the end results are spectacular (Photo: Alan Cleaver)

Stack mind

The stack is a technical concept that pervades computing. It is a type of data storage that has just two operations: add an item to the top of the stack or remove the item at the top. This is useful in a wide variety of situations: many programming languages and operating systems make extensive use of stacks internally.

Most programming languages use a call stack to control how data is stored when a piece of code calls another piece of code. The memory used by the first piece of code is pushed onto the stack before the second piece of code is run. When the second piece of code has finished, you can just pull the state of the first code block from the top of the stack and it can pick up where it left off.

As a developer your mind has towork like a call stack. You’re working on one bit of code, then find you need to change one of the components it uses. So you switch your focus over to thinking about how the component works. All the stuff you were holding in your head has to be remembered, so you can return to that “mental context” when you have finished working on the component and need to pick up work on the original code.

This switching between mental contexts uses your own mind as a stack. If you’ve ever seen the film Inception, you’ll have an idea of the mental gymnastics required to do this well as you go down through multiple levels of code. Developers get very good at pushing one mental context aside, working on another and then returning to their previous context. It is a skill that takes time to learn to do well.

Holding everything in your mind

Writing software requires intense concentration, because you need to hold details of the entire system in your head. You have to understand the ramifications of each change you make on all the other inter-connected bits of the code.

Developers hate interruptions and context switching, especially big ones. The act of “loading” your brain with the information needed to be effective on a project is significant. Moving from one project to another requires you to drop all that carefully assembled information and load up a new context. This can take days or weeks to do.

Developers get into a “zone” where they are completely focused on a task and have a lot of short-term information organized in their minds. If they get interrupted, they will drop out of their zone. Getting back in is painful and time consuming. That is why scheduling meetings every half an hour is incredibly disruptive to a developer because it forces them to constant drop and reacquire the mental context they need to work.

Yes, this sort of contradicts the stack mind. But context switching to different part of the same codebase is less painful than switching out of coding entirely. Developers have to learn how to have a stack mind to be effective; its hard enough, so don’t make it worse by imposing yet more context switching.

Continually improve

Great developers love to learn and improve. They are constantly honing their tools and skills. They are polyglot programmers, which means they know a number of different programming languages and are always interested in learning new ones. They know — and have strong opinions about — a large number of frameworks and libraries. They have an insatiable appetite for new and interesting ways to think about the world.