Our interns were a few months into a guided curriculum of discussion, lessons, and hand-holding run by some of the senior developers at my company.
I overheard one conversation where they talked about our existing developers as though they were a race of superhuman intellectuals who conveniently gathered to perform black magic rituals that make code happen. The implied conclusion of that conversation was “I’ll never be a “real” developer!”.
While they were thrilled at how far they had come, they were discouraged by all that they still didn’t know.
It is a common but amusingly contradictory thought:
Here are some of the greatest minds to ever assemble and I, a worthless nobody, have fooled them all into thinking I’m one of them.
It is a thought made of equal parts fear of the unknown and self-importance. Fear, because we assume that the land of giants must be much bigger than we can imagine. Self-importance, because we believe our role is so critical that failing to perform it will have earth shattering consequences.
I wanted to share with them this excellent talk by Brian Fitzpatrick and Ben Collins-Sussman; from which I have shamelessly stolen the title. As I put together the slides to summarize that talk they quickly became corrupted by my own thoughts and biases then morphed into this stream of consciousness essay.
What follows is the presentation that I gave. If you, like the rest of us, find yourself among the fearful self-important then hopefully this article can help us burn this pervasive myth to the ground.
The Myth
The Genius Programmer sets out to write a piece of software.
They know everything they need to know to handle the task. They set off alone into their cave where flawless code flies out of their fingers for months. When they finish typing they run their code for the first time and everything Just Works™️! They emerge with something brilliant and world changing. Their code is bug-free, robust, and even has a poetic beauty to it.
The world is forever altered; probably for the better. The code is memorialized and never needs to be changed.
Sounds stupid right? Yet unfortunately, I have seen it used to describe what it means to be a “real” developer.
Geniuses Are “Fake News”
The Genius Programmer sets out to write a piece of software.
There are no geniuses.
Rather, they are so rare that they are a statistically insignificant category. The number of people with an IQ over 140 make up about 0.25% of the population. That’s about 20 million people worldwide, which sounds like a lot until you remember the global population is upwards of 8 billion people.
Stories of “geniuses” are more often stories of people whose achievements are exaggerated and mythologized. We ignore the numerous failures and setbacks that a person has overcome before becoming an “overnight success”.
We elevate them to celebrity status and focus only on the most salient parts of their lives; ignoring anything that makes them ordinary, like the rest of us unremarkables.
Ask anyone who has accomplished something impressive and you’ll find that they have failed at it a lot. Like a lot, a lot. Like, more times than most people have thought about trying, a lot.
You Don’t Know Jack
They know everything they need to know to handle the task.
This is something most people get wrong. They’ll run across an unfamiliar word or concept, then decide “oh, I’m not smart enough to understand this”, and stop reading.
If, in your estimation, your current set of knowledge is already complete then by all means stop reading, but then why were you reading something new in the first place?
If, on the other hand, your current set of knowledge is incomplete then it is not reasonable to expect new concepts and ideas to fit neatly within the knowledge sandbox that you’ve built so far.
Some intellectual humility can go a long way here.
You Don’t Know Jack… Yet
They know everything they need to know to handle the task.
When you see an unfamiliar thing, read up on it right way. Keep reading until you are satisfied that you know what it is.
You do not need to learn everything there is to know about a topic; just enough to learn it’s role, pros and cons, when it might be important, and where to go to learn more.
Google it. Read the Wikipedia page. Just get a rough idea of what it is.
It is the default state of human beings not to know things. Therefore, you are guaranteed to run into things that you don’t know. You best get comfortable learning!
You CAN Know Jack
They know everything they need to know to handle the task.
You can learn anything.
The major barrier to skill acquisition is not intellectual; it’s emotional. It comes from overvaluing the scope and consequence of the problem at hand.
I have something of a mantra that has served me well:
“I can solve any problem that I can describe”
When you cannot put the problem into words, your only chance at fixing it is to take some shots in the dark and hope to hit the right thing. That’s assuming you could identity the right thing if that were to actually happen.
As you improve your understanding of the problem, you also improve your ability to solve it. The more robust your understanding the better your solution will be.
Get your understanding to a place where it enables you to solve the problem with the right level of sophistication. Less than that and your solution will feel lacking. More and you risk wasting a lot of time on the theoretical aspects of your problem.
But, You Still Don’t Know Jack
They know everything they need to know to handle the task.
So now you’re an intellectual juggernaut who is comfortable learning new things to tackle whatever problem comes your way. First off, congrats! You’ve come a long way!
However, don’t fall into the trap of thinking that you finally know enough and can coast on this collection of knowledge. You will be repeating this knowledge acquisition loop forever, so reflect on your experience getting here and refine it, because you will be doing it a lot.
Always question your skills. If you think you found a better way to do things, don’t be afraid to go back and change the existing implementation.
Never assume that you have perfect knowledge. You’re probably wrong about something, so look for clues about what you may be missing.
If you feel like surely there must be a better way to do something you are probably right. Go find it!
Programming is a Collaborative Activity
They set off alone into their cave…
Seek to work with people who know more than you in a given topic. Knowledge is not a linear scale but rather peaks and valleys around discrete topics. Find someone whose knowledge topography is complimentary to yours. Seniority is not an important factor here.
Share your knowledge with others and listen to what they have to say.
Explain your ideas out loud; you’d be surprised how often you can’t explain your thoughts because they aren’t fully formed.
Ideas should be tested and the best ideas should win. The value of an idea has nothing to do with the person that had it. Seniority cannot turn bad ideas into good ones any more than a lack of it can turn good ideas into bad ones.
Give your ideas away to anyone that’ll listen. Knowledge wants to be free.
Code Reviews
They set off alone into their cave…
Don’t be afraid of looking dumb in front of others.
Again, it is the default state of humans not to know things. Concern yourself with being knowledgeable rather than appearing to be so.
You can learn as much from giving reviews as you can from receiving them. There is no such thing as not qualified enough to give a review of someone’s code. Even the best developers miss things, especially under deadline pressure.
Point out complex or confusing code; if something confuses you there’s a chance it is too complicated and will also confuse others.
There might be a better way to accomplish your task that you are unaware of, or your code may overlap with someone else’s and you should take it into account. Wouldn’t it be great if someone could make you aware of this?
A code review is an interpretation of the work in the context of the entire system, it is not a judgement of the individual or their intelligence. Don’t make me a liar by doing it any other way.
Ask for Help
They set off alone into their cave…
How long would you drive before asking for directions?
If you have no understanding of what it is you are doing, by all means read and try to figure it out yourself. However, learn to distinguish between when you are learning and when you are just spinning your wheels.
Reach out to your team, they are there to accomplish the same goal as you. Allowing someone to explain something to you gives them an opportunity to check their own understanding. #teamwork
Sometimes you can solve your own problem just by trying to articulate it. This is called Rubber Duck Programming and is something I do quite often!
Writing Code is Hard
flawless code flies out of their fingers…
You will probably not get the solution right on the first try. When you fail, try something different and fail, then repeat. You will learn something new every time.
Just like writing prose, you never get a perfect first draft. Once you write something that works, revise and polish. Given what you now know, how would you tackle the problem if you had to do it again?
The most important skill for learning is not caring how good you are and just going for it.
Fail Faster
flawless code flies out of their fingers…
As you fail and retry, the size of your failures will get smaller and the successes will get larger.
The faster you fail the faster you can build this momentum and improve.
Tackle the hardest things first. Pursue the things you are uncertain about, make minimum proof of concept changes to ensure your solution is viable.
Version control is your friend. It is always possible to roll back code and deployments. Don’t be afraid to make mistakes.
Make Small Incremental Changes
… for months.
Do not submit large code changes at all once. I usually see this when someone is afraid to show their changes too early because it just isn’t perfect yet.
It is hard to reason about the impact of a change when it is very large. It is unlikely that people doing a code review will be able to understand all of the changes enough to find significant issues in it.
Do not let your code evolve in a vacuum. You run the risk of diverging from the rest of the project and getting to a place that is not compatible with the rest of the system.
You’ll only learn where things are wrong once, at the very end, when it might be too late to change direction.
Users get no benefit from your code until you are done, whereas they could have gotten small benefits from small changes delivered along the way.
At the start, write code that you are comfortable throwing away. Improve it as you learn more about the problem and solution.
What If You’re Building the Wrong Thing?
They emerge with something brilliant and world changing.
You know what’s worse than being wrong? Being right about the wrong thing.
It is possible — in fact, likely — that you have not identified the right problem or the right solution. So before you invest all of your time and creative talents into building it, you might want to double check.
The best way to validate this is to test it. Put smaller versions of your solution against smaller versions of your problem. The things you learn from testing the smaller bits can often change your understanding of the problem and solution.
Your solutions should always solve real problems for real people. Don’t lose too much sleep over the perceived ghouls waiting for you just beyond the horizon.
If in fact you are heading in the right direction (you aren’t), and make it all the way down the path without changing direction (you won’t), and the ghouls actually exist (they don’t), you will be better equipped to handle them from having iterated on smaller versions.
Put it out there. Software that nobody can use because you won’t release it until it’s perfect is not as good as crappy software that some people can use to solve some problems they have.
All Code Sucks
Their code is bug-free…
Lol
You Are Not Your Code
… has a poetic beauty to it.
Don’t get sentimental about what you have created. Programming is an inherently creative activity, but your code is not part of you or your identity.
Don’t get fancy without reason. It can be fun to play with new technologies or techniques, but the more moving parts something has, the more ways it can break. Try building the dumbest thing that works and scale the sophistication of your solution to match the difficulty of your problem.
Try not to outsmart yourself. A problem cannot be solved at the same level of consciousness at which it was created. If you build something clever, make sure you have enough cleverness left over to debug your own code.
Premature Optimization
the code is memorialized and never needs to be changed.
The majority of your time in the life-cycle of code will be spent maintaining and updating it.
When in doubt, optimize your code for the human maintainer; let the computer figure out how to optimize your human friendly code. Code as if Future You is someone you care deeply about.
Do not optimize for convenience of inputting the code. You will only benefit from this once, and might pay for it every time the code needs to change.
Since we love acronyms in this industry here’s one of my favorites.
YAGNI: You ain’t gonna need it.
Don’t write code that you may never need. Don’t solve problems you aren’t sure you already have. Resist the urge to build the perfect system and instead build the good-enough system that can be easily changed or replaced over time.
Abstraction
the code is memorialized and never needs to be changed.
Defer abstraction until you feel you understand the problem well enough. Often this understanding comes after a few failures and attempted solutions.
A bad abstraction is worse than no abstraction at all.
The quality of an abstraction is determined by how easy it makes it for you to change things in the future. I’ve seen large and complex abstractions that result in systems that are difficult to modify. Just because something is complex doesn’t make it abstract.
Iterate, iterate, iterate. The best ideas are had in revision.
How To Be Considered A Genius
- Adapt to change
- Change your mind based on other’s ideas
- Admit your mistakes
- Fail fast
- Share knowledge with others
- Embrace criticism
Often, the people asking you to solve a problem don’t know how to solve it themselves. Your job is to become the expert in that area so that we can all move forward. Your ability to work through uncertainty is more valuable than your prior experience.
If you do these things, people will think you are a genius.
Additional Inspiration
“Ever tried. Ever Failed. No matter. Try Again. Fail Again. Fail Better”
— Samuel Beckett, Playwright
“All life is an experiment. The more experiments you make the better.”
— Ralph Waldo Emerson, Philosopher
“Anybody can do something that can be done”
— Oz Lopez, No one of consequence
