There’s a lot of nonsense in the everyday world, but I’d like to focus on four that affect us: symbols, metaphors, white lies, and omission. They affect us as software developers, as tech consultants, and as citizens.
Symbols
Our industry is filled with symbols, right down to our job titles. I’m a software “developer”. Others go as far as to say that they are “engineers” and “architects”. Some days I feel like a code “poet”; others like a code “monkey”.
But even when discussing with other programmers, we speak of design patterns. How many coders know what a physical flyweight is? When people speak of monads, do they think of the linear algebra namesake? But we need some way to express these patterns.
A similar issue happens with method names and class names: they are often
modeling something. We have to name it after what it models. A Link object
represents a URL, with its name referencing the physical loops forming a chain.
But what else is there to name it? It’s the name that best conveys its
meaning, to other coders.
And there’s the fine line: communicating within the in-group. Naming something helps us talk about it and use it as a stepping stone. Thinking in symbols gives us objects, blocks, message passing, streams. But we must be careful with the truth and our audience.
Metaphors
The desktop was the metaphor. When Apple, Microsoft, IBM, and others were fighting to get their OS in front of everyday users, they used the metaphor of the desktop. That’s how we got the recycling bin, folders, spatial file browsing, etc.
When many people think of a computer, they think of their metaphor. Until recently, that was the desktop. Some people are clever: they’ll tell you that the desktop is a user interface, but they know that there is a command line. The command line is the computer.
Well, the command line is a metaphor. The computer – whatever that even means today – is a number cruncher. Perhaps it’s great at binary, perhaps it’s great at floating point, but regardless the computer does not care about us.
We learn this (painfully?) when debugging. When we debug we trace through code as if we were an interpreter. We become the runtime. Debugging tools are a separate set of metaphors built atop the CPU, in parallel to the desktop.
Breaking free of the desktop metaphor is how we get to the smartphone interface, the smart watch UI, the computer glasses HUD. The metaphor limits our imagination.
It also inhibits understanding. Take encryption, for example. The more we explain that a private key is like a house key and the decryption software is like a lock, the more we get governments demanding a master key. They took our metaphor and pretended it was reality – a rookie metaphor mistake, of course – but this is reasonable: we never even try to explain how it really works.
Instead let’s try this:
Alice’s public key is a number,
e. A message,m, can also be represented as a number – take ‘A’ as 65, ‘B’ as 66, ‘C’ as 67, etc. You and Alice agree on a third number,n. The message (m) raised to the power of the public key (e), modulus the shared number (n) will give you an encrypted message.
Maybe it’s too complicated. Maybe it requires more explanation. But we just
tried it. We get to find out. By explaining the math first, we make it clear
that anything having to do with locks, keys, doors, walls, and so on are all
metaphors. There’s no place in the equation (c = m ^ e % n) for a backdoor.
As consultants, we are often in a position of explaining. I’ll get to this more when I discuss omission, but it also applies to metaphor. Do we tell the client that we have finished “laying the foundation”, or do we instead say that we have the Rails app committed, the God object created and represented in the database, and high_voltage in place? What if the client has a follow-up question – are we prepared to discuss concrete and rebar?
When assigning points to stories (a practice to avoid for many reasons), do we say that one point is like two hours? How does the client know – and continue to know – that “like two hours” is a perspective for understanding pointing and not a reality for understanding deadlines? (And why would we propose such a perspective for them in the first place?)
I’ll leave this section with one of the biggest failed metaphors of our times: You wouldn’t download a car.
Omission
Moving on, another deceit to avoid is omission. This comes up mostly in our process work and when onboarding a new customer, but it can also affect code.
Omission is leaving a detail out due to laziness. It can be laziness in re-thinking a problem, or it can be laziness in telling the full truth.
A quick mention of coding laziness: this omission happens when we have a solution fully coded that we realize, just before pushing, ignores a non-trivial edge case. We pause for a moment, glance at the clock, think quickly of a quick way to fix it, and then hope no one notices during code review. A ticking time bomb of laziness. The Perl community calls this false laziness.
Other kinds of omissions can happen when interacting with clients. “Things are going smoothly,” we may say of a story, when in reality you have some concerns, you have some excitement, you learned some new techniques, and you had to re-start the solution twice.
The full set of details – the concerns, the excitement, the new techniques, the spiking – are of interest to many project managers and fellow coders. But perhaps you want to avoid a discussion about priority. Perhaps you’ve sunk so much thought and time into this story that you don’t even want the risk of it being paused. Perhaps you have a new solution that you’d like to try alone before discussing the ups and downs with others. Perhaps you are ashamed to have learned new techniques after so many years of coding. And so the details are omitted.
Omission hurts trust. Well-communicated, honest updates let everyone know that you can be trusted – that you will admit failures, which allows people to believe your successes.
Another place where we can easily omit details – and should not – centers around the question of how much to reveal, and when. During a sales-related meeting, it’s easy to let the potential client drive. “We need ten developers sitting in our office, working from 9 to 6 on our backlog,” the potential client says. “We have developers,” we could say, omitting the details of who we are, what it is we actually do, what we as a company and as individuals stand for.
In that example, telling the full details will surely lose us that client that time. But it will also make it more clear to them who we are and when they should call upon us – not for ten developers but for a strong, coherent team; not for being a warm body but for working sustainably with the full support of our coworkers; not for churning through a backlog but for grooming a backlog and planning the product’s future. The next time they call on us, they’ll know exactly what we can do and where our strengths are.
White lies
An even stronger form of communication laziness – one often the result of fear – is the white lie.
Sometimes clients want to be treated like a rock star. They want to hire someone who will tell them yes and that their ideas are brilliant. At the expense of their product, they are paying us to treat them like royalty.
It’s far too rewarding to please such a client: the more we compliment their brilliance, the more they continue to pay us. This tarnishes our reputation, though. Every failed product, every wasted dollar, is a blemish we carry. It’s a decent short-term investment at the expense of selling our happiness and in misleading a customer. In addition, we’re far too expensive for that; if they want someone to say yes, they could go with any cheaper group of coders. Our value is in knowing when to push back, and why.
Sometimes a client is too much to handle. Mismanaged, bullying, narcissistic, controlling jerks tend not to last long. There’s the lazy, white lie way out: “we can’t find anyone to staff this project”, “we think you should pause this project to work on your business plan”, “this is beyond our skills”.
The proper, honest way out is more complicated and integral to how we work: the safe, honest weekly retrospective. When we decide to part ways, it should never be a surprise – if it is, then the retros are not honest, not safe, or not happening. A good, proper retrospective will let the client know – far in advance – that they are a mismanaged, bullying, narcissistic, controlling jerk.
At that point no white lie is needed.
Conclusion
Normally an article like this would end with advice on how you can go do this, how you should run your company, why this is important for you. This article isn’t. This is how we approach things, what we’ve learned, our thoughts. The content outlined here is, in a sense, our competitive advantage. If anything, the takeaway here is that thoughtbot is a low-bullshit company.
That’s it.