From the Archives: 2016: Things I’ve learned working on a huge software project for grown ups

Intro

Now that I’ve spent a full year contributing code to a large and complex project, I thought I’d reflect on some of the bigger lessons learned that may help fellow junior developers as they enter their first jobs out of school (or just in general).   One of the major drawbacks to writing code in University is that all of the projects are small team (if not single person) and none of them persist over long periods of time. As it turns out, this makes a massive difference in how you as a developer must view your role.

Here are a few of the biggest lessons worth considering if you are planning on leaving the comfort of school for the big scary world of software development.  Enjoy!

Learn To Use Git (I mean actually learn)

Version control is your friend, especially git.  If you’re working on a large project you will undoubtedly have to use git as your version control.  

Most developers have only a basic familiarity with git from the command line. This allows them to function in basic flows (cloning repositories, adding commits, pushing to remote branches etc.)  but such a shallow knowledge of what’s going on can lead to huge mishaps that can derail an entire project for a day.  

Can you handle merge conflicts?  What about rolling commits back, or going back to a specific commit?  Can you compare two commits to see who made the mistake and when? These are all things you will want to be intimately familiar with.

Document Document Document

You can’t view the whole project at once.  there hasto be some Greek mythology reference to not being able to view the entirety of something all at once.  Maybe I just made that up, anyways. The point is that as a junior dev on a huge project, you’re given small tasks that don’t involve the whole project.  

Embracing Encapsulation (yeah remember that from class) and writing modular code is key here.  Just focus on what you need to build to get your feature released, and build it in a way that it is called/run completely independent of the other source.  Easier said than done and obviously this will depend on the nature of the feature. But try to avoid changing exisitng code as much as possible.  

The more you change the higher the chances of your changes affecting code you don’t even realize exists yet.  This is also why we test rigorously (see next point)

Test Rigorously, Compulsively, Obsessively

This one definitely comes with experience, but try and visualize all of the possible side effects of adding/changing code in a big project.  What exceptions could possibly be thrown? Am I modifying anything that other pieces of the code base might rely on? If you have an app that you can test easily and quickly, do so. Put it through as many possible real time use cases as possible.

Do Not Fear The Release

If what you’re working on doesn’t have much of a chance of crashing the application, or causing serious issues; get it out there for testing.  Often times I find myself sitting on features I’m unsure about instead of getting them into the testing environment or in front of users.  

This habit is common to plenty of junior developers like myself.  Double check your work, just don’t triple and quadruple check before releasing.  Knowledge of how to quickly roll back (ie using git!) will help increase your comfort level releasing production code.

Improve Your Code Literacy - Be able to read as well as you write.

People will rarely pay you to build complete software from scratch.  More times than not, whoever is paying you will have pre-existing code that they want you to fix, improve etc.  

This means the majority of your time will be spent reading and trying to figure out how the hell someone before you implemented various parts of the code base.  Get efficient at reading and understanding, that’s the only way you’ll be able to make the ‘minimum’ change.

Make The Minimum Change

If the system is complex with a lot at stake (like the financial trading applications I work on), whenever possible you want to make the least invasive change as possible.  

This is often harder than it looks because your first instinct will be to rewrite all the stuff you see that you’d do differently.  Focus on the feature, make incremental changes that don’t alter the structure of classes whenever possible and be wary of altering shared data members!