5 Things I Wish I Knew as a Junior Developer
As a highly unqualified source of advice, I began my software engineering career back in 2013. Wide eyed and fresh out of college, I was ambitious and not yet dead inside. To be blunt, I thought I was awesome and could face and conquer any problem that meandered my way. However, over the years as my morale desiccated, (and as I have begun to observe junior engineers, and the self actualization of my short falls), I have started to compile all the revelations I faced as a junior engineer (and observed) in an effort to teach the younger folk the wise lessons of balding 30 something-year-old.
1. Solidify and Optimize your tool chain
From derpy college products to production code is a giant leap. Unless you are a born and bred coder from a spliced gene chain of Ritchie and Torvalds, I would unaccurately estimate greater than 80% of college grads haven’t done the deep dive into a large code base that is larger than a couple thousand SLOC and a continuous integration build system. This is where optimization of a tool chain becomes so important. Note that not all of these apply to all jobs as parts of these are often abstracted as a different job title.
Knowing Your Text Editor/IDE
This is the best advice I can give to any young programmer. Being able to quickly navigate code lowers the learning curve and time for implementation. Being able to goto the definition of a function immediately and see what it does is a simple task, but too often have I seen developers to a ‘FindAll’ in project folders and have to wade through all the calls of the function to find the definition. Additionally a good text editor will enforce syntax and formatting to create ‘prettier’ code that is not only easier to follow but by nature lowers bugs through good practice. The levels of a coder using their editor can be related akin to screwing in drywall. It ranges from using a screw driver to a drill all the way to a drywall screw gun in terms of speed an efficiency, and operating a text editor/IDE a the speed of a drywall screw gun lowers onboarding time and increases productivity.
Build System/CI Systems
Knowing the build system is the important task of any developer. Gone are the days of a 10 line makefile. There are dozens of questions that need to be addressed when building code. In a perfect world, you should be developing on your own isolated branch that will be reviewed and pulled into the master later, but more often than not especially at older companies the repo system lacks the organization. So before committing and building, make sure it doesn’t break a build or ruin the productivity of a coworker who may be operating in the space.
Secondly is compile times. With large systems, the compile times are non trivial in the range of hours sometimes, and nothing is worst then seeing a 4 hour compile crap out due to an errant semi colon. That being said make sure your compile system is utilizing as much resources as it can to build as fast as it can.
Lastly, make sure unittests are all updated so that you don’t get the morning email of shame for breaking the build or breaking the tests. It will inevitably happen, but staying ever vigilant helps.
2. How to ask the right questions
Annoying your mentors isn’t he greatest way to start of a work relationship. They are there as resources and their time is valuable so you want to make the most of it. First and foremost, make sure you do a basic search as a coders job is less coding and more of being able to look something up, comprehend and apply the knowledge.
For myself the answer was to role-play the scenario in my head and have an internal dialogue. I would rehearse the question and imagine what follow up questions they would ask me and I would make sure I would research the follow up questions. 8 out of 10 times I would stumble upon the answer myself. The 2 out of 10 times I found actually were intelligent questions that needed an answer derived out of experience rather than naivety.
3. Learning to read documentation
Stack overflow is that flaky friend that’s only helpful if the need the ride to the mall. Granted this varies for various languages and libraries, but the a majority of answers especially needed by junior developers lie in the documentation. This avoids the most ‘why didn’t you just’ scenarios. Plus as you’re growing your coding arsenal it adds fun tidbits of methods and options that probably optimize your code and functionality for the better.
4. Finding the right mentors
Not all software mentors and supervisors are equal and to some degree you may never have a choice. Everyone learns differently and on top of that everyone teaches differently. I myself am guilty of just information overload akin to throwing handfuls of darts and hoping a couple stick on the dart board. Learning the right skills from the right mentor helps tremendously in your career. For instance, most experienced developers have knowledge you can derive from.
The code expert is the language nuance expert that cares if you do ++a vs a++. The architecture expert is usually the person that designed the infrastructure of the whole system. The systems expert is the developer familiar with linking the overall goal of the project with the minutia details that lead to the the 30 requirements required of your module. Lastly the product manager expert is the person that knows how to manipulate all these people properly to create a well oiled machine. Identifying each of these experts are monumental in drawing the right knowledge in improving your software engineering repertoire.
5. Accept that you know nothing
Going in with a humble mindset is probably the most important. These people have been developing and coding for a long time and it is in your best interest to be a sponge and learn as much as possible. Sure you may know a cool library from college or had crazy futuristic research projects, but your colleagues are worth the benefit of the doubt that they know their job and do it well enough to still be doing it. Most projects have the complexity living in their infrastructure rather than the actual difficulty of the coding concepts.
*Granted alot of software projects need to be pushed into the future so with discretion push the envelope. Just don’t be a rabble-rouser.
Chances are a good portion of junior developers will have at least some of these skills ironed out to some degree, but over the years I have definitely experienced and observed all of these aspects from junior developers.
