I work in web development, and I’m struck, often, by what a needlessly painful career it can be. Many developers have a lot of felibility over their hours. Many developers can work on their own with a lot of freedom over how they work. There’s an element of problem solving and endless challenges. However, it’s also painful because we make it painful.

I started web development in 1996. I’d predicted that client-server hypertext engines would be big (by which I meant bigger than NewsNet, not bigger than television). I saw one and got obsessed.

In most other careers, I could be a comfortable, smug bastard firmly entrenched in my art. The web changes really fast. Very little I learned in my first couple years is particularly useful. Getting schooled by developers who weren’t born when I learned the basics of NCSA HTTPD has long since ceased to be a new experience.

My big consolation is that this progress makes idiots of us all. You have to learn so many things in this business, and those things go obsolete, and you have to learn a bunch more things.

And people’s confidence in you is a precious resource. You need your manager to believe you know things so that they’ll fight for you. You want other developers to believe in you because you’ll have to fight for your ideas. If developers disagree, the confident- sounding developers will get their plans approved.

So, unfortunately, we tend to punish each other for having to learn things. It’s human nature that knowledge, once learned, seems obvious. It is really easy to look down on people who are struggling.

My best example, because it’s happened so often, is when I’m talking with other developers about whether to hire a candidate, and someone will say, “The candidate had never even heard of react webhooks.” Or lets say had never published Kafka events, created a Docker container, published a Kubernets pod, I’ll nod for a moment and then think.

Wait a second. We learned to do that in March. Were *we* unhirable until a couple months ago?

Sometimes developers will openly mislead each other. One example from decades ago was when I needed to create a graphic user interface in Perl (I told you, it’s decades ago). I asked three people about it, and I got the same answer, “You can use Perl/TK. It’s super easy.”

I used Perl/Tk, and it wasn’t super easy, but it wasn’t too bad. I wanted to talk about some quirks about it.

But I couldn’t.

I didn’t know anyone who’d used Perl/Tk. I didn’t know anyone who knew anyone who knew Perl/Tk. Everyone who assured me it was super easy wanted to sound like they were familiar with it, but none of them knew a damn thing about it.

So developers are constantly hitting things that confuse them, and they constantly feel a level of imposter syndrome. And most of us are on some level making it harder for each other. We’re suppressing empathy to project confidence.

So here’s my suggestion:

Look stupid.

Never present a guess as knowledge.

Own mistakes as quickly, loudly and clearly as possible. Do this for the big mistakes you’re afraid of getting stuck with. Do it for the small mistakes you might get away with.

If you think something you can’t prove, be very clear that you can’t prove it.

When you’re telling somebody something you’ve learned, include where and when you learned it. People might think it was obvious to you.

When you don’t know. Say you don’t know.

And try to remember a few things about unfamiliarity that people tend to forget:

Context is really important. You can have three pages of documentation that is completely accurate that is nonetheless no help because it requires context.

Because of this, dealing with multiple unfamiliar things is exponentially harder than dealing with one thing. My first time dealing with a modern Javascript framwork, I was dealing with ES7, NPM, Babel and AngularJS.

I could look up documentation on AngularJS, but all the examples used non-transpiled Javascript, so they didn’t resemble my code. I could look up examples of ES7, NPM or Babel, but none of those used frameworks, so they didn’t look like my code.

One of the reasons PHP stayed such a success is that many sites documented the basic elements: Linux, Apache, MySQL and PHP as one technology – the LAMP stack.

Also, when you’re looking at lots of unfamiliar things, it becomes much harder to spot familiar problems. I can’t count the number of times I’ve circled a piece of code five times, trying to find out which piece of a new technology was tripping me up, when the problem turned out to be something I solved a million times. It reminds me of being in a dark and unfamiliar room and being frightened seeing your own jacket on a coat hanger.

Now, there is a cost to constantly admitting ignorance. It can take longer to build trust. Other developers are much quicker to express doubt if you make it clear you sometimes doubt yourself. But, ultimately, people want to work with people who make them feel better, and they’ll be happier talking to someone who is more honest with them.