---
title: Fuck Bullshit
teaser: We cut through the nonsense of the daily world.
tags: business
author: Mike Burns
published_on: 2016-05-12
---

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].

[name it]: https://thoughtbot.com/blog/name-it
[we must be careful with the truth and our audience]: https://motherboard.vice.com/read/googles-lawyers-tried-to-explain-apis-to-a-jury-using-a-physical-filing-cabinet

## 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.

[committed]: https://twitter.com/Huth/status/378306063520374784/photo/1
[pretended it was reality]: http://blog.erratasec.com/2016/03/sometimes-techy-details-matter.html
[limits our imagination]: http://coding2learn.org/blog/2013/07/29/kids-cant-use-computers/
[a computer]: https://www.nngroup.com/articles/sketch-of-an-archetypal-computer/
[avoid]: https://thoughtbot.com/blog/user-story-points-scrum-kit

## 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.

[weekly retrospective]: https://thoughtbot.com/playbook/planning/meet-weekly-to-discuss-successes-failures-and-plans

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.