One of the things that’s really hard to overcome as a “new” programmer is taking your failures personally.
Back in the day–when I was first learning–some of the deficiencies in my code I was willing to chalk up to inexperience. But as I learned more, developed more and got better, every time a co-worker would come to me with a bug or something that didn’t work as it should’ve… I’d automatically get defensive.
Something’s fucked up? In my code? How dare you! It works the way it works for a reason. When it doesn’t work, you’re being unreasonable, so fuck off… I’m not re-writing that code because you’re a moron… and if you’re not a moron, the only other possibility is that I suck at writing code. And I was so proud of myself for doing that bit… I can’t possibly suck at it! Etcetera.
When you’re first learning to program, you have two huge learning curves ahead of you which must be successfully navigated before you can roll out code that actually does anything.
1. You have to learn the capabilities, syntax, and conventions of the programming language that you’re going to use, and…
2. You have to learn to think logically.
If you can’t do these things, you’re going to fail miserably as a programmer.
The thinking logically part wasn’t a problem for me. Hell, any number of ex-girlfriends and my wife would probably testify that my logical thinking is among my most abject characteristics. Still, I found it relatively easy to logically work through a problem, and often found myself saying, “… and after that, it’s just math, which is easy.”
But, as you’re navigating those learning curves, your chest-puffing sense of accomplishment belies your inexperience. For the sake of this post, let me say that your capabilites fall into one in a series of levels inherent to the process:
1. You know jackshit.
2. You know enough to perform simple operations.
3. You know enough to achieve more complex operations based on external input.
4. You know enough to fuck yourself.
5. You know enough to achieve complex operations based on varying levels of external input.
6. You know enough to fuck yourself and those around you royally.
7. You know enough to achieve complex operations from multiple pathways.
8. You know enough to call yourself a “programmer”.
9. You know enough to put it on your resume.
10. You know more than 50% of the other programmers using the same language.
11. You are a resource from which others learn to program.
12. You are a master programmer.
13. You wrote the language.
In the “How dare you!” days, I was around grade 4. I was designing the code to achieve a goal… but using the application in a manner as only I would. It was logical! To me.
But users aren’t logical.
While some of us programmers may think that users really have nothing better to do than invent ways to fuck up, the opposite is usually true. What seems logical to them is–more times than not–at odds with how we designed our grade-4 code. Who’s at fault when the app explodes? The user who has a different logical process than us? Nope. It’s the programmer, for not having the wherewithal to account for seemingly infinite possibilities.
The programmer’s onus sounds impossible, but normally, there are only a handful of different situational permutations that are available to the user to perform a certain task. All it takes is a little think-through of the process, and a little help from others to put things through their paces.
At some point in my programming career (I cannot point out where), I gave up on taking it all personally. It’s so much wasted time, anger and effort.
A bug is a bug. It’s something in the code that doesn’t work right. While it very well could be “your fault”, nobody’s actually placing blame. Your users and co-workers don’t give a shit that you personally wrote the code. They only care that something is broken.
Fix it and move on.
I realized I’d reached this point at the end of last year when reflecting on my “achievements” before my year-end review. And it made me really happy.