Coding with Honour

The personal blog of Sam Stokes.

Let's stop talking about quality

| Comments

I don’t like discussions about quality in software.

Don’t get me wrong. I want to build software I can be proud of. I want to be part of teams that build great products. I aspire to craftsmanship. What I dislike is the word “quality”, and how it tends to polarise conversations.


Quality is subjective

A lot of factors go into software quality. Good software is fast. Good software is maintainable, readable, scalable, and well tested. Good software has attractive UI and intuitive interactions. Good software has no bugs, or at least no serious bugs, or at least no bugs that our customer support team can’t work around.

In practice, quality means whatever you want it to mean. To a fan of unit testing, quality means investing in unit testing. To a designer, quality means beautiful screens and careful interaction design. To a customer support manager, quality means all bugs are documented and the serious ones have an ETA.

If you tell people that your estimates are higher than expected because you want to do a quality job, some of them will think you’re spending time refactoring and writing tests, and some will think you’re going pixel-by-pixel in Photoshop. Some of them will end up disappointed.

Programming is not magic

| Comments

When people who program want to convey to others the joy and satisfaction we find in our craft, we often liken it to doing magic. The analogy evokes a sense of empowerment, possibility and freedom. But I think comparing programming to magic actually does unintended harm, because it has another connotation: that programming is a mystical ability, something you are born with, not something you can learn.


I want to get a lot more people programming, and I think we need a better analogy to get there.

What programming is like

| Comments

What is programming like?

We in the software profession have done a terrible job of explaining to the public what it is that we do. Everyone has interacted with a teacher or a doctor. There are TV shows about lawyers, cops, even government officials. However warped our impression of their day-to-day, we can relate to these professions. TV depicts programmers as modern-day wizards, socially aloof, hacking into systems or bringing the new algorithm online just in time to stop the cyberterrorists — totally disconnected from people’s experience of the software they use every day. Software remains mysterious.

This isn’t just a problem for awkward “so, what do you do?” conversations at parties. I believe one reason why so many demographics are underrepresented in software is that unless you grew up with it, you’re unlikely to have the faintest idea what making software is actually like. Why would you strive — particularly against economic obstacles and systemic biases — to enter a profession you know nothing about?

Programming sucks

Inspired by a friend who couldn’t see what was so hard about programming, Peter Welch wrote a hilarious, heartfelt and all-too-true rant about what writing software is like. His title, and answer: “Programming Sucks”. The whole, long post is enjoyable reading, but here’s a representative excerpt:

Imagine joining an engineering team […] for a bridge in a major metropolitan area. […] The bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. […]

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.

Vim wizardry #1

| Comments

(I wrote this as a response to an Ask Hacker News post about learning Vim, but I thought it deserved a life of its own.)

This is one of my favourite Vim features. Say you have the following code:

do_something_with(some + long * complicated * expression)

Say your cursor is where the caret indicates. Typing ci) (“change inside parens”) in normal mode will:

  • delete all the text between the two matching parens
  • place you in insert mode with the cursor between the two (now adjacent) parens
  • put the deleted text in the yank buffer so that p will paste it.

The use case here is obviously so you can assign a name to that long complicated expression. ci) is much easier than selecting it with the mouse, and keeps your hands on the keyboard where they belong ;)

The genesis of a building

| Comments

Witnessing this is pretty cool from a “making things” point of view. Shame it’s happening right outside our flat.

Limerick Lisp-style

| Comments

In honour of the Functional Programming eXchange, on a bus to which I am writing this.

 (a (program (writtenp :in 'lisp))
     (may 'be (and (simple) (elegant) (crisp)))
     (but (cry '(C pros) "too *fancy();"
             "for (i; simply(); &cant++ + ++see)"
             "{ the code; for (;;) { the parenthesis; } }")))