S3E4 - The top 5 Technical mistakes that Junior Developers make

CareerCareer AdviceDevelopersSoftwareEngineers
Written By Philip Gannon

Show Notes

In this episode we take a look at the Top5 Technical Mistakes that Junior Developers make. Mistakes are fantastic, and an essential part of the learning process! However there are some mistakes that Junior Developers make that hinder their career, and can be incredibly difficult to recover from. We’ll discuss those here, as well as how to remedy them so you can level up and become a stronger software engineer!

Show Transcript

Intro

This one is going to straddle the hard and soft-skill line, but I feel it’s relevant and useful, so here we go!

I see so many juniors making mistakes. And don’t get me wrong - mistakes are good! They are actually great! Getting things wrong is the very first step to getting things right. Failure, just like rest, is an essential part of the journey!

However, the mistakes I’m talking about go catastrophically beyond. They are cliff-jumps,  not speed bumps! They are signs that your journey as a Software Developer is going horribly wrong, and can take a very long time to recover from, if at all.

1. Learning too many things at once

With such a vast industry as software development, it can be incredibly overwhelming for new folk starting out. There’s just so much to learn!

One of the biggest mistakes is learning more than one big thing at once - especially when it comes to programming languages! I see so many juniors trying to learn python, javascript and ruby at the same time because someone told them that you can only solve one type of problem with each. Just to be clear, this is not true in the slightest!

You’ll also come across complicated tutorials that cover html, css, javascript, node/php/.net and SQL or mongodb all in one go. Not every tutorial labelled for beginners is actually for beginners!

Pick one language and stick with it. When you've built up a significant body of work, then you should start perusing other options. You’ll be viewing them through the lens of experience, and will enjoy learning these new technologies or languages so much more!

2.Not understanding Version Control  

If you didn’t know, Version Control is effectively a mashup of both Time-Travel and the Multiverse for your codebase. It allows you and your team of collaborators to work upon multiple versions of your code, and see a full history of what happened when and by whom. Git is probably the most popular flavor (sorry SVN folks!)

The problem arises when devs don’t understand how VCS works. Common issues include

  • They forget to commit all of the files they changed

  • Putting files in VCS that don’t belong

    • Preference files for their IDE

    • Environment variables

    • Build files,etc..

  • They push changes to the wrong branch

  • They overwrite their work (or the work of others!) by being in a rush to do a merge, or apply a stash! 

  • They forget to pull before pushing

  • They try to force-push. 

  • Or, they Commit but then forget to push!

All of these can mean a lot of wasted time for you and your colleagues in order to understand what exactly happened so that it can be fixed.

Another aspect of this is understanding the branching strategy that your team is using. GitFlow and GitHubFlow are the most popular for GIT users. The nuances of what is a feature branch, what is a release, what is a hotfix branch, etc. Messing this up can mean code that hasn’t been finished or approved can end up being used or deployed in places it shouldn’t. Be diligent here! 

Even if you feel like you understand, please always ask if you’re even the slightest bit unsure. I know all senior devs would rather spend 5 minutes double-checking something with you, then several hours trying to fix a bad decision later!

You can use a tool like https://ohmygit.org/ to learn Git. Also take some time to reference the workflows here:

3. Not knowing enough about data formats 

Basically, covering the main types of Storage/Exchange formats. We’re talking CSV, JSON, XML. 

I have seen so much bad code that has been for working around someone’s poor understanding of the storage or transit format that they’re using. The codebase ends up being chockful of loopholes, special cases and bubblegum and duct-tape. Not a great place to be!
Do yourself, and your team, a favour and please understand how to use them. You don’t even need to write the parsing or storing code from scratch. There is a very large number of people who have already solved this problem, and you’ll no doubt quite quickly encounter a mature and standardised library or package to help you deal with them. 

  • CSVs 

    • Please wrap all text values with quotes

    • Use UTF-8 encoding

  • JSON

    • Understanding the difference between javascript and json

    • Understand what makes valid json

    • Know how to validate for your json data with json schema

  • XML

    • Understand attributes, elements

    • Understand how it is different from HTML

      • This can have very dramatic consequences if you’re not tuned in on this one! 

    • Know how to query it with XQuery or XPath

    • Knowing that it’s case sensitive

    • Understand usage of CData and how important it is.

4. Not referencing the Docs

There’s this form of masochism in the industry I see where many new or junior devs believe or are told that it’s a weakness to google or use references. That if you don’t know how to do your work without looking things up - then you’re not a real software developer. I’m here as an Engineering Lead in a prominent multinational to tell you this is utter horseshit.

The docs exist to be referenced. The devs who make the tooling you use make a point of creating the documentation. Only a fool would ignore it!

The other side of this is that many junior devs don’t know that reference documentation, example implementations, etc exist, or they just may not understand them. Don’t let that stop you! Grab a friend or coworker and ask them to walk through it with you. You will be surprised how willing they will be to help!

5. Not knowing their tooling

SO when we talk about tooling, we talk about the innate array of tools within your development environment. These might seem like surplus to requirements, or some kind of dark art. Please trust me as someone experienced when I tell you that these will make your life SO MUCH EASIER as a dev!

So what are we talking about here? Stuff like:

  • Debugging

    • Stepping through your code, inspecting variables, setting normal and conditional breakpoints, watching variables and traversing callstacks

    • Calling your language’s equivalent of Console.log is not good enough!

  • Profiling

    • Basically understanding the resources that your code uses

      • Finding and fixing CPU hotspots

      • Spotting and addressing Memory leaks

    • Hotspot fixing with crazy callbacks, sprinkling async everywhere or littering Thread.Sleep won't always work!

  • Build Tooling

    • Ability to make builds of different configurations

      • Debug vs Release

    • Ability to make builds for different targets.

      • Web vs Desktop App in Elektron vs Mobile App in Cordova

  • Testing Tools

    • Unit test - how to run them and get reporting

    • Code Coverage Analysis Tools

      • To understand what parts of your code are actually tested with your unit tests, and which parts are not.

Each of these are what really brings the engineering part to Software Engineering. Once you get into the habit of using them, you will use them everyday for the rest of your life. And you’ll also wonder how you lived without them!

Conclusion

Now, I realise that there’s a lot here. You have to remember these are topics that you learn and refine across the breadth of your career. You can’t be expected to learn it from one day to the next. However, it is expected that you’ll learn them over time, and that allows you to be a stronger contributor for your teams and projects.

You can read all the advice and war stories you want - and that means you’ll know the pit-falls. However if you don’t fail, you’ll never understand them; and that’s what makes the difference between a good and a great developer.

Making mistakes is a natural part of the journey. It’s essential even! Just make sure that if you’re making these mistakes that I’ve called out there, that you take some time to re-evaluate what you’re doing and get some help!

Philip Gannon
Previous

S3E5 - Industry Insight: Changing Landscape, with Steve Orrin
Next

S3E3 - Turning up as yourself