Just like in the Matrix, everybody falls their first time. You don't know what you don't know and what you don't know can sometimes cause the entire website to go down.
And after almost 20 years of coding, believe me, I've made mistakes. Mainly early on in my career at my first programming job, with a flattening curve the longer I've been at it. So in the hopes that you avoid a few of those yourselves, here's a list of the 3 most memorable ones that have stuck in memory.
Deleting the database
As much as you want to avoid it and as much as everyone makes it a point to tell you "Don't delete the database", sometimes, you delete the database. And if you are thinking "How??". That's a valid question, because it's not exactly as simple as clicking on the "Delete database" button and then confirming with a "Yes".
For one, you obviously don't want to actually delete it. It's an accident, and most of the time, it happens like this.
Someone asks you to update a record in the database and because it's in an obscure database table, there's a chance that no one has gotten around to creating an actual web form for it just yet. A web form with validation and security measures built in to prevent such things.
So you log in to the database server, open up the query editor, and you write a quick SQL statement:
UPDATE Sales SET Amount = 0 WHERE ID = 234
Seems easy enough. And it's probably the quickest way to update this record. You might get asked to do this several times afterwards. And eventually, this will happen:
UPDATE Sales Set Amount = 0
And just like that, in the blink of an eye, you've just gone ahead and reset the entire Sales table with millions of records. This might take seconds, or it might take minutes. But there is no going back once you hit enter.
Lucky for me, the database backups at this company were generated every hour or so, and the sales table wasn't getting hammered every second. I told the lead developer, he panicked, laughed and as quickly as he could ran a restore with the latest backup.
It's only happened once in my career and that's it. It's an expensive lesson to learn, but performing any type of update on a live database should always be done with extra caution.
Over-engineering
This was probably the most common challenge that I faced early on and it took me a while before I learned to take a step back and to re-focus on the goal at hand. Early on you have a tendency to want to do everything perfectly so that you can stand out and be the ace programmer in the office.
What ends up happening most of the time, is that you miss deadlines as you yourself navigate through your overly-complex code. I'm not the only one guilty of this.
Every programmer that I worked with pretty much had this tendency to go above and beyond the requirements and to build this grand application. Here is an example of such a situation.
A manager asks you to build an email capture form. There's a fancy design with images and background patterns and such, and dead center there's an input box and a big bold button. Easy enough. If the user enters their email, you add it to the newsletter or save it somewhere. If you want to know how to add a user's email using the MailChimp API, check out my article here.
Instead of just saving the email though, you decide that you want to create a form framework, that way you never have to build another form ever again. You build it once, and then you can generate forms on the fly with a few lines of code.
I'll say now, I have done this. It worked and it was a fun challenge. But it took much longer to implement and it was much harder to maintain in the future. And the worst part, was that I only really got to use this 'futuristic framework' one time. Then it never really came up again.
I think it's important as a growing to developer to learn how to gauge these type of situations. For example, if I foresaw that in the next month we would need to implement a dozen or so forms with different fields, parameters and such, then perhaps a form manager would make sense. But in my particular case, most of what I ended up generalizing and externalizing became just one-off projects.
Misreading specifications
To highlight the importance of paying attention to detail, there were some times when I did in fact read the specifications and they made sense enough that I could start building something. But that was it. I just read it once and assumed that I was good to go.
Until a week later when a business person tested the application out and began to ask questions. They might mention features that you have never heard of. Or even worse, features that you kind of remember reading about but you were too much in a hurry to really pay attention to it.
Essentially, I read the spec sheet wrong. I made assumptions that I shouldn't have, and instead of asking questions to clarity, I kept going and kept piling on the code.
And I spent a considerable amount of time on this new project mind you. It was complex and I'll admit, fun to work on. But when it was all said and done, the person that had requested it, had no clue what it is they were looking it. "Isn't this what you asked for?". Only to hear back "I just wanted a report with these 3 things".
A report that would have taken 20 seconds to generate mind you. But instead, I jumped the gun and made assumptions.
This happens to everyone at some point pretty much. Maybe it's not your fault because someone wrote down the wrong requirements, that happens too. Point being, it will happen and whether it is your initial fault or not, you are the one that has to fix it.
That's why it is important to read, re-read and to verify afterwards just to be sure.
Last words
Don't feel bad about making mistakes at your job. You won't get fired (probably). There is a good chance that most mistakes can easily be fixed too. It is a part of the learning process. The newer you are to anything, the more excited you tend to be which causes you to rush right into the work. But slowly you learn to take your time, pay attention, ask questions, and in the end you end up writing less code, but code that works.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.