For people who write code: devs, engineers, programmers, you’ve probably been subjected to one of these sorts of things at some point.

Most people will already understand that it’s never that simple. (Almost?) nobody is purely introverted or extraverted, and our behaviour will differ at different times, different energy levels, and different situations. But it’s a useful axis with which to understand our own behaviours and tendencies. Am I more introverted in general or extraverted? What are the factors that seem to alter that? Which environments to I thrive in? Which do I find more challenging?

Any number of other tests will give you further axes with which to judge your own behaviour and sense of self. Are your thoughts more ‘emotionally led’ or more ‘analytically led’? Are you more driven by material goods or by experiences? Is your gender identity male, female, or somewhere in between (or on a different axis altogether)?

I would argue that most of these are useful, but usually to a limited (sometimes trivial) degree. Some people may be lucky to have a strong innate sense of themselves, but for others having guidelines can help form a useful picture of themselves that can help them find environments that are well suited. Or they may find things about themselves that they don’t like, and they wish to change. Having a language with which to talk about these things can help.

Which brings me to the axis I want to introduce you to: control vs acceptance (or controlling vs accepting). Like all the axes I’ve mentioned so far, this is not a question of absolutes. It’s about understanding behaviours, situations, environments that can lead to you being more controlling, or more accepting. It’s about understanding that, and perhaps identifying some situations in which you want to change that behaviour.

And to be clear, I don’t want to present either of these as a universally ‘good’ or ‘bad’ thing. Sometimes being accepting is preferable, in others taking control would be beneficial.

Here’s two examples to hopefully make that clear:

Lucy is in a meeting. It’s not going well: there’s no clear agenda and the conversation is veering into discussing unimportant minutiae. Nobody else seems to be trying to rally the situation. Is it better to accept this or take control?

Geoff is in a meeting. It’s a meeting with the whole team. There is an agenda but the thing he wants to speak about is not on it. He’s desperate to talk about his topic—it’s really important. Is it better to accept the situation or take control?

Both of these examples are ambiguous, you could come up with any number of circumstances in which either approach would be appropriate, but taken at face value, it would be better for everyone if Lucy took control of the situation and brought the meeting back on track, or ended it. In the latter example it would probably be better for everyone if Geoff accepted that this was not his chance to speak.

There are many situations in life where you will be automatically reacting with more controlling or more accepting behaviour. In particular you may find that controlling behaviour can emerge when dealing with emotional attachment—something that’s often tough to negotiate.

I’ve written previously about how programmers should be treated more like creatives, as their work is much more similar to the work of other creatives than it is to many other types of work. One of the strongest attachments can be to things you have created, and it can cloud rational thinking. This can be particularly hard when it’s time for a substantial piece of code or project into which someone has put a large part of the effort. Nearly all software will have a short life, and when the time comes for removal or replacement of something you consider to have ownership over, do you react with a controlling or an accepting mindset?

Hopefully this has given you a perspective on which to reflect. Over the next few days and weeks, check in occasionally and evaluate your behaviours. Are there times when a different approach on the control/acceptance scale could have benefitted you?

Many successful companies codify their approach to collective creativity, for example one of Pixar’s rules for fostering collective creativity (go read that article, everything in it applies to your engineering culture!) is the concept of ‘plussing’:

…you may only criticize an idea if you also add a constructive suggestion.

This and many other techniques ensure that the focus of the creative people working together is on the work rather than the individuals creating it.

As I’ve written about before on this blog, it’s time that we start treating programming—as in the fundamental work that software engineers, developers, data analysts, etc. all do—as creative work.

One of the core concepts with doing creative work as a team is that once ideas are in public are no longer owned by the individual who submitted them, but rather a part of the body of work that the whole team is working on. This is an important part of creating an environment that’s psychologically safe - and that’s an essential part of a team that can be creative.

Of course, as programmers, our ideas are often rendered in code when we submit a PR or document like a spec., ADR or RFC. We are working together not in a writers’ room, but in PRs, documents and sprint ceremonies. It is in these forums that sometimes our attachment to our work can get the better of us. We can fall into disruptive patterns of behaviour that serve to prove the validity of our own ideas first, rather than engage in a dialogue about how to get to the best outcome.

Our Tools Foster Ownership

The tools we use don’t help, especially for those of us working remotely. In a room where people are talking, an idea can come up, and be shaped by the collective, each person adding their perspective until the concept loses any sense of who owns it. Participants in a creative meeting may struggle even immediately afterwards to identify who exactly contributed what to the finished plan.

With digital tooling we are not so lucky. Every line of code can spew up a name with git blame, every Slack message is archived forever with your name against what you wrote. Every comment on a document has your name and profile picture next to it. The train of thought and each individual’s contribution is written in stone, to be pored over as required.

Since being creative effectively means being ‘wrong’—or at least not neccessarily ‘right’—a lot of the time, this means having your name and probably face attached to an essentially indelible record of all of these statements.

I’m not saying these tools should change, but it is good to be aware of the way that they don’t make it easy to detach yourself from the work you do, and to consider the tools you do use when working collaboratively. What tools help blur the boundaries of who did what? Do you need to use a tool at all?

The Pain of Cognitive Dissonance

To do creative work collaboratively without losing our minds, we must disassociate ourselves from our work. It’s easier said than done! Often the hardest part can be recognising when problematic instincts are in play.

Cognitive dissonance is the unpleasant situation that occurs when the brain must hold two contradictory truths side by side. This can happen when we receive feedback because the brain almost axiomatically believes itself to be competent, correct, and most importantly consistent. Therefore when faced with the realisation that perhaps we made a mistake, or that we didn’t think through a particular scenario, or that we need to make some corrections, our brain is forced to go on the defensive to deal with this.

To admit that we made a mistake challenges the brain’s idea that it’s competent and correct, and to change course runs the risk of inconsistency. So instead we go on the attack: trying to figure out how to change the field of play so that we were right all along, that the proposed changes are not required after all, that the person making the suggestions is wrong, that communication was at fault, resulting in our misunderstanding, etc.

This all happens—unless you’re well practiced at spotting it—without realising that this is going on at all.

Getting the Better of your Instincts

Fostering a safe, supportive creative environment relies on a strong group dynamic and a shared understanding of what the pitfalls lie when working collaboratively. This means achieving a good collaborative creative environment cannot be something that can be achieved through individual action alone (unless, perhaps, you’re managing said team).

Above all it requires deep trust. One person falling into a defensive stance about their idea can trigger a cascade as others adopt a similar stance in response, or get locked into discussion of that one suggestion rather than moving on.

However, mastering your own instincts is still an important part of the battle, but if you are aware that your team is falling into bad patterns of behaviour, take the time to focus on fostering a creative environment that feels safe for everyone.

It goes without saying that what makes a good engineer a good engineer very rarely translates into making them a good manager. Different companies structure themselves very differently too which doesn’t help - team leads, tech leads, technical product managers, software architects, staff engineers there are a multitude of names and roles given to the most senior engineers within an organisation, and no clear consensus on what the best structure is - often they can emerge reactively from trying to retain key people.

This can make it tough for those in a senior role looking to progress to the next step. Are you a staff engineer or a software architect? You may find two roles with those two names that present very similar requirements, however two roles for staff engineer - even within the same company - may have very different requirements!

It seems it’s best to ignore roles, names, the specifics of what individual companies may want their most senior engineers to achieve, and instead focus on developing the skills that will get you there, regardless of what the roles might be.

In no particular order I’ve listed a few key areas of development I think are neccessary—in some combination—to get you through the threshold of senior engineer and into roles above:

1. Holistic Engineering

   This is the skill of understanding the context in which you are working as broadly as possible. For a system, product, module you are working on, you should be able to trace its value all the way back to fundamentals. For a given piece of work, however big or small: Who does it benefit (probably multiple personas, internal and external)? How does it benefit them? Where are the lines of communication to those people? Do they know what you’re doing?
   
   Understanding this at all times—and if it’s not understood making efforts to make sure it is so—pays dividends. It aids everything else you do as an engineer, especially in a product organisation.

   
   A key side-effect of this skill is that, in the right organisation, it can engender trust and autonomy. When the trust isn’t there, the same effect can be approximated with stakeholder meetings, where all of this is worked out ‘on paper’. This process is expensive, time-consuming and often frustrating, but it’s a habit many organisations fall into.
   
   The right engineers, with the right team around them, empowered in the right ways can—sometimes—cut through this.

2. Decision Making

   Opinions are something that develop most noticeably with engineering experience. People just starting out are likely to follow blindly, or adopt the opinions of those around them without question. As you become more experienced, some opinions will burnish, others might change. You may come up with some of your own ideas. A large-enough collection of engineers will always disagree about some things, big and small. Choice of language, choice of architecture, team structure, meeting schedule, there’s an endless list of sources of friction.

   
   Decision making sounds trivial at first, but it’s a key leadership skill. Can you deal with making a decision that you know will make at least some people unhappy, and own it and the disgruntlement that comes with it? What about a decision that makes most or all people unhappy but you know is for the greater good?1

   
   For example you may find yourself in a situation where a key production system is written in, say, VBA. It’s difficult to maintain, breaks frequently, and it’s very hard to hire new people into the project. But the people maintaining it have put years into understanding its many quirks and are experts in it. To break it up and re-write it might be the best decision for the company, but might meet resistance from those for whom it has become their speciality.

3. Wrangling Data

   Being able to be fluent in data is useful in a multitude of situations within and without engineerning itself. You probably have some capability here already, but it’s worth getting really good at it. Finding and fixing the nastiest of bugs can often require a data-oriented approach, and quickly and reliably being able to extract complex metrics from your observability platform or log data is the kind of skill that will make you very useful to a lot of people.
   
   For example, are you reasonably fluent in a data-wrangling tool, for example Jupyter Notebooks? Can you build something that takes in 100MB of csv log data and produces a graph of something using string matching? Can you take a spreadsheet from finance and validate it against the transaction log in your database? Can you make a detailed case for a new approach using a fully worked cost estimate?

4. Understand the whole stack at some level

   Similar in concept to holistic engineering, it’s important to understand a bit about the whole stack of software within which you’re working (and at least a rudimentry understanding of the hardware too!). In an online application there’s probably at the very least a front end or client, a back end, some data stores, some caches, potentially split across many (micro?) services and using quite a few pieces of technology and third-party services.

   
   Other systems may involve more or fewer layers of complexity, but there are always layers. If you are writing a native application you will be dealing with the operating system. If you are working as a data scientist you will be using tools like pandas or R as well as plenty of other libraries. It is important to understand not just how these tools work at some level but also why they work, why they’ve been chosen, why they’re popular (or unpopular), and what the alternatives are.

5. Write less code, communicate more

   In a commercial setting, there’s a cap on how useful an excellent programmer can be if all they do is write code, and if all you really want to do is write code, it’s probably best not to pursue advancements in your career.
   
   This is because advancement will always be related to impact, and by working essentially alone there is a limit to how much impact you can deliver. Working alone is also a liability for your employer, particularly if you’re working on critical or complex systems - what happens when you’re not around? This is also a short path to burnout.

   
   If you do want to pursue that advancement though, a fundamental skill you will need to develop is leadership. Line management is one type of leadership, and a trap many organisations fall into is providing this as the only path to its engineers. However technical leadership—which involves just as much communication—is just as important to an engineering org of any substantial size.

   
   Working with others - pairing, mentoring, guiding, etc., as well as participating in meetings about larger decisions will become a more and more useful application of your knowledge and skills.
   
   Building good relationships with others and helping them understand engineering constraints and capabilities is a very good use of your time too. Managers, leadership, and whatever structure exists in your organisation outside engineering will benefit from your insights, especially if there isn’t a clear communication path already. Your data wrangling skills and the ability to answer interesting questions or present novel information will help a lot here!

I hope at least some of this was obvious to you, and I hope at least some of these skills are things you’re aware of and developing, even if I didn’t articulate them in the way you might be used to - I’m learning too!

At a glance the work may seem quite different too: a visual artist will spend their day sketching, possibly without the aid of digital tools at all, in order to create visually aesthetic, meaningful visual works. The programmer on the other hand is solving a complex logic puzzle with lines of code in a very rigid environment, they are probably working to a specification detailing exactly what it is they need to produce and potentially even how.

If you look at how creatives are hired there are very different approaches too: At a large agency you will find creatives are rarely hired alone, instead partnerships or even teams of people will be interviewed and hired together. There is so much value bound up in creative partnerships that breaking them is not beneficial for anyone involved, whereas programmers will often change teams and companies frequently, potentially switching languages, stacks, industries all at once as they do so.

However, I would propose that programming is as creative as any of these other fields, and programmers (I use that term as a blanket to cover those who primarily code as part of their job) and the companies that employ them might create a better, more productive working environment if they were treated as such, and used some of the same approaches for hiring and managing them.

One of the places where people fail to see this parallel is due to—broadly speaking—the differences in personalities you will find in these roles. I am going to talk in big generalisations here!

I know, and I’m sure you know many people who break this rule, but on the whole you’d have to agree that if you were to do a Myers-Briggs (or whichever personality horoscope you prefer) you would find that on the whole you’d find programmers on the more analytical side of the axis, and your traditional creatives on the more emotional.

This confuses us, because in our minds we’ll typically see emotionally-driven creatives and analytically-driven programmers, and yet the work that programmers are doing is fundamentally just as creative in nature.

Another confounding factor is that the output of a traditional creative’s time is typically something that is tangible: an image, some music, copy or prose. The output of the programmer’s time is likely only really understandable by their colleagues.

Sitting at a text editor or IDE a programmer with nothing more than an idea in their head will wrangle it into being through their own insight and creative will. Most programmers will have an urge to make, to build (an instinct that often needs to be reigned in!), and that’s what got them into it in the first place.

The tools look very different, the ideas are a very different shape, and yet the fundamental act of creation is the same as someone turning their ideas into prose, copy, sound or visual media.

Many of those who write for a living have a personal project like a book they work on in their spare time. Someone with a job in UI design may have an artistic side project as an outlet for the creativity which has its wings clipped by company requirements. Do you know programmers who also work on creative projects outside of work?

Another misdirection (for now at least) is money. Getting paid to write is hard, and getting paid to write truly ‘creatively’ (beyond e.g. marketing copy) is harder still. Salaries are often low, creative jobs subsidised by others, and only those who make it to the top of the tree, who get their big break—their book gets published, their art gets noticed—will make serious money from their passion.

For the past few decades, programming has been in such high demand it is easy enough if you are moderately profficient at it to command a comfortable salary with good perks and great job security. Of course it was not always thus, with programming being considered a secretarial role in the very early days of computing!

This disparity in status can make the work that programmers are doing feel more important, more serious, more valued compared to the work of other creatives.

It is interesting that in the latest leap forward in AI technology many creatives are nervous for their jobs - LLMs like ChatGPT can convincingly write meaningful-sounding prose to a specified style. Stable Diffusion and other visual AIs can produce images to a very tight spec instantly, mimicking any style and with any arrangement of subjects.

For the first time it also seems that AI is coming for the jobs of programmers themselves too - ChatGPT can write code to spec in a variety of languages, explain how it work, and fix its own bugs when prompted. It is likely that it will only get better from here. We may be entering a new chapter very soon where programmers and creatives find themselves on equal footing again.

But for now at least nothing seems to be changing yet. The tools may change but we will still need people who can understand them, and while the job of programming may change, in the past when massive labour-saving inventions have come along, the result has been more work put into other things, and there is no shortage of demand for software.

So how can an organisation do better by its programmers? I’d suggest in the following ways:

• Respect flow work

  All programmers know about flow - to be deep in a difficult problem, with all the context in your head at once. This state is hard to achieve, and impossible to achieve with distractions. Artists and writers attend retreats to find the time and space for big thoughts. Perhaps your programmers could benefit from some extended periods of thinking time too.

• Don’t disrupt great partnerships

  A team that’s working well together can be hard to find, and it’s difficult to engineer. Sometimes the magic just happens and you have a team that’s firing on all cylinders. Reject the temptation to spread that good practice around and leave them to get on with it. Just as great creatives form great partnerships, let your programmers do so too.

• Understand & manage the emotional impact of creation

  The IKEA effect is a bias everyone displays towards things they themselves have created, or had a hand in creating. You instinctively feel ownership over something you have put effort into. When managing programmers, be aware of this. All code typically has a short lifespan of a few years at most. Deleting, deprecating, decommissioning things that you have put months or years into creating can be a surprisingly emotionally hard thing to do. Understand this toll.

• Give freedom but with clear boundaries

  Creation is exhausting, an in particular with programming there are many decisions to make, even on a single line of code. What to name a variable? Use a case statement or if else? Where to handle a potential error? This is exhausting, and one of the ways to help programmers out is by making as much of this as obvious as possible with clear, concise style guides, automatic formatters, and clear guidance about How Code Is Written At Company. But it’s a fine line - too proscriptive and it can feel like all the creativity has been sucked out of the job, and that’s probably the motivation for doing the job in the first place.

• Understand that creation is a two-way process

  You cannot be a writer without reading voraciously. You cannot paint without appreciating the work of others. So it is with programming. However unlike works of great literature or art which are freely or cheaply available to consume and learn about, most code is tucked away within the organisations that own it. However, the masterstrokes, the key ideas, the clever hacks live on in the heads of the programmers who worked there even once they have moved on. Encourage programmers to share not just what they are working on now, but the best things they’ve worked on before (while respecting their NDA’s, of course).