4 common mistakes junior developers make at work

Written by

Walter G.

Published on

August 09 2021

Modified on

October 16 2022

Filed under

career

Everybody is a junior at least once. At least for a portion of their lives. And during that time, mistakes will happen and servers will go down in the process. And that's really what being junior means. You haven't quite yet had the time to click on every button and to see the outcome in a console. And as such, you are going to click on the wrong ones sometimes and things will go down.

Here are 4 of the more mistakes that I often see junior developers make. I myself have been guilty of some of these. So let my experience be a guiding light of sorts for you.

4. Coding too much

So you're a programmer. So yes, your job is to program applications . It's what you do in college or what your learn in an online course. In a corporate environment though, things typically run a little differently.

For one, that code that you are working on? It's probably expensive. It's paying for your salary, and probably for a few other people's as well. So typically, you can't just jump in and start deleting and modifying things. Which is what most entry-level developers that I have worked with tend to want to do. I get it, I also did much the same.

Typically, this probably won't cause any major issues. But there's alot more that goes into working with an actual large-scale application. Things that you might not be aware of. A few of those include:

- Server configurations
- Scheduled task management
- Security settings
- Network configurations
- Database architecture
- Code dependencies

Non of these things really involve any form of writing code. But they are there running daily, hourly and by the minute and at some point, they will need some kind of maintenance.

I made the mistake early on in my career of essentially ignoring how any of these things worked. I enjoyed coding and I figured that somebody else would take care of these things. And while in the beginning of any career, you can kind of get away with this mentality, at some point, you are going to find yourself alone in your cubicle with a request that you have no idea how to fulfill.

So before you get too excited with the code, definitely spend some time learning how an application is running but more importantly why it's configured to run in the way that it is.

3. Not commenting enough

Whether you have 3 months of total coding experience or 3 years, at any new job, you have 0 experience with any of the projects that you will encounter.

So it's important to comment whatever it is that you are doing. Not so much for yourself, but really for anyone else that is working there and that has to work with your code.

And this is mainly because you will make a mistake early on in the process and being able to locate that mistake quickly and efficiently is important for both yourself and for your company.

Fret not, you won't be fired for accidentally not encoding an input form in a new contact page. But at some point, you will probably have to fix it. And being able to locate your changes, and even when the changes were made, can make your job a lot easier.

As an example, I made it a habit to almost always leave my signature behind on any changes that I made to a codebase.

// wg - added functionality 'x' - 01.01.2021
function renderAMap(){
...
}

Nothing too convulsed or cryptic. Just a small message that I can quickly track down just in case anyone wants to know who updated the function, without having to check through a long list of commits in GitHub. Every programmer should own their functions at the end of the day.

While it may seem like overkill, my co-workers enjoyed the meta data and began using it themselves. Within a month almost every major section of code had the initials of the programmer and the timestamp.

So comment accordingly.

2. Not validating user input

Truthfully, we'd all like to avoid doing any kind of tedious and added work on top of our normal jobs. Validation is one of those things.

Validation essentially involves cleaning any data that is coming from the outside into the system. That includes data in web requests as well as file uploads and form inputs. Content such as emails should reinforce the current email standards to avoid future complications.

This step is often saved for last, but many times it's also overlooked. This is often the reason as to why data breaches can occur on even the most secure systems.

While most frameworks often times have some methods of validation already built in, they might not correspond to your companies particular needs.

As an example, think of any order form that you fill out online that includes a quantity. You can specifically set the <input> element to be numeric and to have a set maximum value, such as 100. Maybe you can physically only accommodate 100 units.

The browser will reinforce that constraint on the UI level. However, that's just for visual purposes to the client. The server that you are making the request to has no such constraint built into place. And the last thing that you would want is for a quantity of 10000 to go through into the sales process and to potentially corrupt the database.

So you have to validate the data everywhere. On the client, on the server, and even at the database level. Again, this is a tedious step and one that different companies might implement in their own way, but it's quite possibly one of the most important as well.

1. Not taking criticism (advice)

I don't think this is something that anyone ever gets used to, or gets good at. For good reason. Whatever task it is that you complete, to you, it's probably the best work that you could get out, at least given a deadline and your particular skill level.

But there's a good chance, that on a wider scale, the work isn't ideal. A senior programmer might look at the code and immediately see areas for improvement. You can either take it personal and assume it's some form of attack on your skills (which we all do at some point). Or you can suck it up and realize that whoever is giving your the feedback probably has much more experience and is only trying to help make you into a better programmer.

I often times worked much too hard to try and defend my code at my first programming job. Truthfully, I thought it was pretty fantastic code. But my senior lead developer (who had 15+ years of experience) was not at all impressed and would often times have me rewrite massive sections of code under his particular guidelines.

While back then I did not see the value in any of this, as I got older and slowly worked my way up to become a lead developer in my own right, it began to make sense.

I've worked with many entry level developers during my corporate years. And I often times found myself doing code reviews and requesting changes in areas that I felt needed more work. I am fairly certain that I annoyed most of these younger developers. But I can only hope that since that time, they have also slowly begun to appreciate it as well.

It takes years to become proficient at anything. And in the beginning, things will go awry more often than you would want. You can mitigate those growing pains by taking your time, asking questions and by continuing to learn best practices and new techniques as often as you can.

Comments

No messages posted yet

Add comment