I Made These Mistakes as a Junior Developer so You Don’t Have To

Ever heard the phrase “a developer always looks both ways before crossing a one-way street”? That means we’ve been burned so bad by mistakes — both ours and from others — that we don’t trust any situation, no matter how simple it looks.

We’ve all been there, right at the start of our career we think we know everything, and we can’t even realize that we don’t know what we don’t know.

It’s a common pattern and most junior developers go through it. You could even say that it’s a rite of passage and once we’ve gone through it we’ve gained the wisdom that comes from screwing up.

At least I know I have, which is why I thought I’d share that wisdom so you can skip ahead and avoid making these rookie mistakes yourself. But then again, there are very few experiences that provide such an adrenaline rush as screwing up this bad, especially if it’s on your first job.

SQL and the Dreaded Update Without a Where Clause

If you haven’t updated a production database without a where clause you haven’t lived.

No, no, that’s not me telling you to go ahead and do it.

But trust me, the feeling you get when you realize you’ve just sent the update statement (or even worse, the delete statement) out to the production database without the where clause is unparalleled. The moment you realize your mistake you want to go ahead and choke the network cable hoping the bits won’t go through. But then again, we all know that’s not going to work.

In my case, I updated a whole product table in the first company I was working for and renamed every single item for sale to “Merry Christmas.” I wanted to update ONE record but I did not write the damn where id = X part of the query.

Needless to say, I was having to explain my mistake to the CEO of the company ten minutes later. Lucky for me, my colleagues were able to restore a recent database backup and the mistake was corrected on the same day.

That being said, I never forgot another where statement in my life. So yeah, I learned my lesson.

Deleting Files From Production Without Backing Them up First

This one has a very special place in my heart because I made this mistake during the very first day of my very first job as a developer (which was also my very first job, period).

I was working for a small software boutique, we were creating websites for our customers, and “deploying to production” meant we would upload the HTML files directly to the FTP through some drag and drop program (I think we were using FileZilla back in the day).

I was using one of these. Remember them?

Remember how the “Del” key was very close to the “Enter”?

Well, I was uploading a new HTML file to the website of one of our customers, and after dragging and dropping it, I hit “Enter” accidentally, instead of hitting the “Del” key. That’s not the worst part though, because a confirmation pop-up appeared to make sure I wanted to delete that file. The problem was that I immediately tried to correct my mistake by hitting the “Enter” key; it was a reflex move. I didn’t even think about it. Of course, I ended up accepting the confirmation pop-up and deleted the selected file at the time.

Yes, on the very first day of my very first job, I had deleted the homepage of one of our customers by accident. I didn’t know how to communicate this to my manager; it was a crazy day.

Lucky for me, the problem was easily solved because my manager had a local backup of the site, and he uploaded the file a few minutes later.

That same day after coming back from lunch I found my “Del” key cannibalized and removed from my keyword by my colleagues with a sign that said, “Use only in case of emergency.” They showed me it was OK to laugh at my own mistakes, and I learned a valuable lesson that day:

Always make sure you’re not risking a potentially unique asset and make sure you have a backup policy in place.

Improper Branch Handling

Git is terrible, isn’t it? I know I hated it for so many years, and CVS was even worse! (Yes, I’m that old.)

Essentially version control is hard to understand when you’re just getting started. If you’re not lucky, you’ll end up working on a project that has a very complex branching model. This is especially true if you’re working in a mono-repo environment where you have to deal with multiple projects and teams working on the same code base.

I can’t tell you how many times I had to reclone the repo and start over with my task because I forgot to switch to the correct branch before starting my own.

So, instead of creating my new branch from the development branch, I would create it from my previous branch, which hadn’t been approved yet. That meant I was importing my untested code right there with my new code, and I would end up pushing both as part of the new task. Lovely!

Now this has a very easy solution if you’re using the terminal window: make sure the current branch is shown as part of your prompt (i.e,. the text that shows you the current folder you’re working on). Take five minutes to set this up, and you’ll never have this problem again (unless, of course, you don’t pay attention to your prompt either):

If you’re on Linux or macOS, you can add something like this to your ~/.bashrc file:

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}export PS1="\u@\h \[\e[32m\]\w \[\e[91m\]\$(parse_git_branch)\[\e[00m\]$ "

This will add the current branch in parenthesis at the end of the prompt.

If you’re on Windows I would suggest going with Git bash, which is a terminal program that is included with the default Git installation. It already shows you the current git branch, like this:

Now you can be sure of the current branch before making my mistakes. Remember to always follow the instructions of the branching model your team is using. And since this is such a repetitive task, it’s always a good idea to have these instructions written down on a step-by-step document, especially meant for new team members being onboarded. That way they can copy and paste the commands if they’re still learning the trade. So if there isn’t such a document on your team, consider pitching the idea to your leader!

---

I’ve made my share of mistakes during my 18-year career but these three are the top ones that changed the way I worked after making them. They shaped the type of developer I am today, and that is saying a lot.

Do you have a story like that? Do you remember your biggest screw-up as a dev? Share your mistakes in the comments. Let’s normalize the reality that we all make mistakes and that as long as we learn from them they serve a purpose!