Developers should learn design.

Even if its just to make better software for ourselves.

Many of my friends both in and outside of the tech industry are creatives working in various design-based disciplines. Over the past decade or so one requirement has been creeping slowly into job descriptions for designers: coding. What started off as “Nice to have — HTML & CSS’’, has gradually turned into HTLM, CSS and JS being standard must-haves and some jobs even requiring the latest JS frameworks like React or Vue. This got me thinking, if coding is an important skill to be a good designer, why are design skills not considered important for being a good dev?

Just to be clear I personally don’t agree with coding skills being needed by designers. I think that it disrespects design as both a discipline and craft, but it doesn’t matter what I think because the industry has already decided. Today most design jobs have some kind of coding requirement. While I think there are pretty insidious reasons why companies are looking for unicorns¹ *cough* cheaper labour *cough* there are plenty of designers who are smarter than me and can do a better job than I ever could at breaking down those arguments in more detail. What I really want to explore are the benefits of devs learning design skills as part of our discipline.

To start off we need to actually define what we mean by design in the context of this post. Design, like any other discipline, is an umbrella term for a wide range of skills and sub-specialisations. It has its own internal problems characterising what is and isn’t design; who does and doesn’t get to call themselves a designer; and what spaces design takes place in². While this post is definitely not saying design thinking is the panacea for all our problems, there are some core competencies required to become a skilled designer that I think would worth exploring further. These competencies are not any particular hard skill like graphic design but rather soft skills such as compassion, empathy, inclusivity and social consciousness. These are the skills I think developers would greatly benefit from incorporating into our practice.

Now it’s not to say that programmers lack any of these skills, rather the craft is often presented in a way that neglects to highlight that there are human users at the end of the software building process. Programming is presented through a human vs machine lens rather than as a human for human activity. This, often implicit, act of overlooking the end user interacting with our software not only leads to worse software but also forgives programmers for thinking that the human user is not important. It allows us to view ourselves as benevolent caretakers of the matrix, observing from the sidelines rather than as active participants curating people’s digital experiences.

I think this becomes clearer when we ask ourselves, who do programmers write software for? I would argue it’s for: themselves in three months; other programmers on their team; other programmers in their company; other programmers in the community if it’s an open source project; end users. In that order.

This is evident in one of software engineering’s most well-known truisms, that developer time is more expensive than computer time. On the surface this looks like a fairly innocent assertion, observing that we should optimise for making it easier to write code rather than optimising to make it easier to run code, because running code is “free”³. It has led to many software development best practices such as writing readable, maintainable and well tested code. However, the consequence of this way of thinking is that it becomes a toss-up between the developer and the machine as to who is at the centre of the software building process, end users are nowhere to be found in the equation. This is in stark contrast to any design-based field where designers endeavour to centre the end user in the design process.

You could argue that optimising for development ease allows us to create new products faster for users to enjoy while making software building a more pleasant experience for developer. Win win, right? Well today I would like to argue against both those arguments by proposing that we actually make bad software for both developers and end users.

Calling my first witness to the stand, accessibility⁴.

I can already hear the murmurs, accessibility is pretty good, we’ve done a lot of good work in raising awareness and generally making more things more accessible.

Well firstly, I would argue most of the good work is being done and pushed by designers and a few frontend developers who either have a design background or work closely with designers. Many developers actively avoid the frontend explicitly so not to have to think about things like accessibility and end users. Secondly, being brutally honest, how many of us have actually tested our software on browsers for the visually impaired or using screen reader software or in keyboard only mode? How many of us think of accessibility as more than disability related issues; what about access for people with slow internet connections or for non-English speakers?

We currently live in a world where users expect 100GB day one downloads when they buy a new video game on disk⁵, with no care of data caps or internet speeds. Users have to live with the fact that there are, on average, 51 accessibility errors per page on the million most visited websites in the world⁶, including poorly labelled images and tables for screen readers, if they are labelled at all⁷. People aren’t using our software coz they like it, they use it coz they have no other choice.

Ironically, designers have already given us plenty of suggestions on how to improve the development process so we make better software for users. Remember progressive enhancement⁸? No, never heard of it? Well it doesn’t matter anyways, designers are second class citizens in the tech industry. The “deadlines” are always a little too tight to pay them any mind.

And as I alluded to earlier it’s not just the non-technical users that would benefit from programmers having more empathy for the end user but other programmers as well. There is a lot of software designed for developers that is so obtrusive it’s become a meme.

Calling my second witness to the stand, softwares favourite meme, Git⁹.

Let’s talk about git and its user interface. Where do I even start. It wouldn’t be a stretch to say git has one of the worst user interfaces I’ve ever used. Now I know there are a few of you in the audience thinking, “yh that’s just coz you cant use git, noob” but believe me I know how to use git. I have a good understanding of its internals, regularly use commands like git rebase -i , git commit –fixup=<sha> and in the last two months I’ve definitely used git add --patch to manually commit chunks of code without a gui. I use git every day in a decent sized team and it still never seems to get any less terrible.

There are so many commands. Many of them it is not completely obvious what they do while others do completely different things based on the context or the flag(s) used. Case in point, what does git checkout actually do?

git checkout <a-file-you’ve-made-changes-to> deletes those changes i.e. restores the file to its last committed state; git checkout -b <branch-name> creates a new branch off the current commit; git checkout <commit-sha> can be used to move up and down the tree, putting you in a detached head state. On the surface three totally different use cases for the same command. The documentation for git checkout says git-checkout Switch branches or restore working tree files, why does it do two seemingly unconnected functions? Even if there is a reasonable technical explanation you would need to have a fairly deep understanding of git under-the-hood to make sense of it, not something you can expect from your average user.

Then there is the dreaded merge conflict. So many developers are literally so scared of seeing merge conflicts that they would rather not make the change than to deal with it.

From my perspective there are two main parts to a merge conflict: completing the actual command, this is usually a merge or rebase, by ensuring your new changes fit with the existing state of the file system at master; and keeping your commits clean by containing only the relevant changes to each one. It’s usually that latter that really gets people confused. Depending on how far down the tree the conflict takes place it can “bubble up” to any other commit in the branch. In order to maintain clean commits, you can find yourself deleting changes you want to keep because those changes will be added “later” up the tree during the conflict resolution. Until you’ve done this a few times its hard to know whats going to remain in the current commit and what isnt. I really believe this is why so many teams have one commit per branch workflows as it does go some way to avoiding these headaches.

Git’s ‘dumb-ness’¹⁰ does not ease noobs in at all. It actually makes it all too easy to shoot yourself in the foot when you don’t know what you’re doing¹¹.

The reality is that in order to use git comfortably you must understand gits “world view”. Understating that world view comes in the form of a 550 page book¹² or, like I had, really nice senior developers who are willing to give a crash course when you start the job as a junior. There is nothing intuitive about it and we all know this. That’s why we create tools like git-gui, fork and lazygit to work around the horrible interface.

I think the most frustrating thing about git is how incredibly useful it is and how well it does its job. It’s a perfect illustration of putting the machine at the centre of the development process and having end users as an afterthought. If Torvalds had worked with a designer for a few days on the CLI we could have had an amazing tool in every way but alas, he’s a git¹³.

Ok, so version control kind of sux but at least actually writing code is ok, right? RIGHT? Sorry to break it like this but writing code also kind of sux.

Although most developers consider programming languages to be a tool, I take the view that a programming language is a type of user interface¹⁴. The other side of the coin to a gui. When viewed through that lens, the lack of improvement in programming language usability over the last half century is disappointing. There is a sense that programming languages, as interfaces have not quite decided on who they’re for. Are they to make it easy for computers to understand and run programs or are they designed to make it as easy as possible for us humans to get the machine to do what we want? Maybe it’s a bit of both? But if we take our earlier premise that developer time is more expensive than machine time should we not be completely throwing our lot into the latter category? Should we not be making programming languages that are as easy as possible for people to learn and write?

Alas, in the last 10 years the script kiddies¹⁵ have discovered type systems¹⁶ and now they’re all the rage. We’re trying to stuff types into every nook and cranny we can find. We’re back to debating “static vs dynamic” as if this wasn’t all done back in the 60s. Are statically typed languages more bug free? Maybe, maybe not. The more important question in my eyes is should we even care? If the recently created “type systems” for scripting languages have no impact on runtime performance; the rewards of static typing on runtime performance are debatable¹⁷ anyway; and literally does the opposite of trying to make programming languages more accessible and easier to use by adding extra layers of indirection, then what’s the point of the discussion?

No one will ever persuade me that type systems are a step forward in the evolution of programming languages, no one. What happened to utopian goals like natural language programming or visual programming? I’m not saying we would ever achieve either of these but user centred design (UCD) approaches to programming language design would surely lead us closer to those goals.

Its controversial but I would argue that excel, if viewed as a declarative domain specific language (DSL), is more progressive in terms of language design and accessibility than typescript (TS) or rust. I want to emphasise that this is not to say that TS or rust are not good languages or that they are not improvements on what came before each of them. All I’m saying is that if we designed a language using principles from the design community, such as UCD, we’d have something that looks closer to excel than to rust. There is a level of intuitiveness in excels “what you see is what you get” visual approach that I think no written language quite matches.

I remember watching a video once where Brian Kernaghan said, “a programming language should affect the way you think”. As a psychology grad I instantly recognised the roots of the comment¹⁸ but I’d never extended that thought to programming languages, it really blew my mind. What it made me realise is that currently programming languages encourage us to think like machines, they don’t give us the space to think like humans. There are abstractions with the intention of bridging this gap such as object-oriented programming (OOP) which attempts to help humans model the world around them and declarative programming which attempts to allow humans to define an outcome rather than a procedure and while these were great first steps toward improving the interface back in the 60s, we’ve not really moved on from them. We largely write code the same way we have for the last 50 years.

So whats the moral of the story here? Software Engineering (SWE) is a very young craft that’s still not set in stone, there are no formal qualifications to earn or specifications describing exactly how to “do” software engineering so it can do with all the help it can get. There is precedent here, SWEs older sibling computer science borrows a lot from other academic disciplines like maths, linguistics and neuroscience. There is no reason for SWE not to do the same by borrowing ideas and techniques from adjacent disciplines like design. There is no shame in asking for help to improve the craft by working with and learning from people who spend most of their day thinking about end users, especially when the potential user base for any given piece of software is the entire human population. Will that mean reinventing a lot of wheels? Yes, probably but I think its sometimes worth starting from scratch rather than trying to build clunky fixes on top of what is already a poorly cobbled together foundation.

Footnotes

1. Unicorns, Foxes, Hedgehogs, the UX Design Bestiary
2. Design Justice
3. Historically this has been due to Moore’s Law but this is now ending
4. The A11Y Project
5. How game sizes got so huge, and why they’ll get even bigger
6. The WebAIM Million
7. The Internet Is for Everyone, Right? Not With a Screen Reader
8. What is Progressive Enhancement, and why it matters
9. ELI5: What is a GIT and Github
10. This is a feature not a bug
11. to its credit, git also makes it possible to undo almost anything. Thank you reflog 🙏🏾
12. Git Pro (book)
13. Git name
14. AllProgrammingIsUserInterface
15. I learned to program in 2016 so yes, I include myself in this
16. Type Systems Explained
17. Benefits of Static Types
18. Language Affects What We See