As a developer, it can be difficult to separate oneself from their code. Our code, in reality, is seen as a representation of our abilities. The resulting product is then a representation of our code and ourselves as well. We pride ourselves on what we write and feel ashamed when the code we put out is not up to our standards.
There is something interesting in the way we see and interact with our code. On the one hand, a code review/peer review done well can alleviate any negativity or confidence loss based on the review remarks. We’ve all been there where someone tore our code apart and we had to start over but it’s definitely not as bad as releasing bad code into production causing bugs and causing heads to turn toward you at the company meeting when discussing these bugs. Yet a good review can be a learning lesson and if we approach it as such, our ego doesn’t get marred in the process.
But what happens when that peer review gets taken away? Or, god forbid, bugs slide through code review and QA? Or what if there is no QA to begin with? Such is the struggle of a startup developer.
I’ve been working as the senior engineer at Landdox, a company with a land document management product, for about seven months now, five of those, I worked as the sole developer. Bringing the project from nothing into a reality where users are eager to join the private beta, and the founder demoes the application frequently as the word spreads of our product.
As a sole engineer on the project, I was pretty damn proud of what I’ve done so far, especially since some of the technology was entirely foreign to me (for example OCR). But I’ve managed to do my job really well, at least I think. Remember, I have no peer review.
I setup a testing system that tests the basics (no time to test everything in a break-neck development cycle), a workflow, a deployment strategy, code linting, and so on. In fact, I’d say that most of my code doesn’t smell and the code that does smell is pretty simple to understand and just workstm.
But no matter what I do, bugs still creep in. And that can feel debilitating. It’s like when you write an article or publish a post on reddit (or HN) and you get 50 positive responses but it’s that 1 response all the way on the bottom that you just can’t stop thinking about. It’s like that for me.
I get the system deploying, files uploading, and files OCRing yet the second some weird bug creeps up where you can’t create a folder in some special section, a great deal of questions pop up in my head:
- Why is this bug cropping up again?
- Is it something I could have foreseen?
- Is the quality of my code low?
It throws me into a whirlwind of emotions. I start to see overly complicated code everywhere, incomplete migration to ES6, tests that aren’t thorough enough, and it makes me want to shut down. It makes me want to say “Alright, we have to stop, I need to redo this. All of this.” to my manager but I can’t. And it really would be a bad idea even if I could.
What all of this takes me back to is reading books like Code Complete, Prammatic Programmer, and others that repeat the mantra of:
- do not overcomplicate.
- test everything.
- be responsible for your code.
No matter what. The last bit, I often translate to what I said at the beginning: “My code, my failure”.
Starting over is as irresponsible as deploying buggy code (when you’re actually aware of the bugs!) so that’s not an option. I tried to convince myself one way or another but in the end, I just could not justify a rewrite to myself, to my boss, or to anyone. A rewrite was a scapegoat that I wanted to use as a justification for production-level bugs. Whether I wanted to blame Angular (and try to switch to React), or blame Node (and somehow learn Go on the way), or just generally blame the lack of another developer (we hired another developer so I can’t use that excuse either!), I sought a scapegoat.
I feel like we all do. Maybe the data input was unexpected, or the load was unexpected, or something wasn’t in the spec.
In the end, I did the responsible thing: I fixed it. I fixed the problem, I kept going, and I’m still going, seeing less and less bugs as I go.
The first step to being responsible
The first few steps to feeling better was being responsible. The way I did that was no just by fixing a problem but by introducing tools to help find the problems and keep them away.
One of them was a logging system. A proper logging system allowed me to find the cause of bugs faster and I quickly found out that many bugs occurred and reoccurred quite often but simply slipped by rudimentary QA we set up (my boss testing stuff out before deploying to production).
Monitoring software was a good upgrade, too. I knew that the app had crashed or exceptions occurred before being faced by one of those “Did you know X is down?” emails.
Another was saving errors into the DB for job queue actions. OCRing documents is taxing on a system and errors of all kinds can come up. This made looking through errors much easier. I could look at a document in our product itself and see that something went very wrong and what happened. It also gave our users a clue as to why a document was blank.
Lastly, I realized that I easily knew the system inside and out and that gave me confidence regarding bug-fixing. I knew what I had to do once a problem popped up.
But all of that can be for naught when the system crashes down all around you and you can’t figure out why.
The person that could make me feel better about it was me and how I handled myself:
It’s not okay to blame technology, people, or whatever else for your mistakes. Owning up to what happened, “I fucked up” really helped me deal with it.
It’s good to be proud of finding solutions to problems. Fixing bugs and enhancing code quality is not a “given”, it’s an accomplishment, and a damned good one. When faced with bad code or a problem, take it as a challenge to make yourself proud of it once again.
And finally, it’s important to realize that you’re not alone. Last week, I experienced a major application crash but just the day prior, I had the chance to read CircleCI’s post-mortem of their application crash and it made me realize that shit happens. I’ve been through a bunch of shitstorms but never as the sole developer responsible for fixing that shitstorm.
Just about every large tech company out there releases post-mortems, the accounts of why a major application crash happened and how they fixed it. Hell, Reddit is down several times a week!
So if you’re out there, feeling like shit about your code
Remember that you’re not the only one. And what’s more important is that the only way to deal with it is not by being a developer, but by being a human being first.