In the past nine months, I’ve had the fortune of working at UpGuard. My time at the company has taught me too much to be covered in a single post, but I want to share one of the most important lessons I have learnt here. You can read more waxing lyrical about UpGuard here.
Who is this for
In my 8 years of programming experience prior to this stint, I’d call myself a Software Engineer / Developer. I frankly had no clue what it entailed and I wasn’t terribly pedantic about the word usage. I wrote code, software appeared (shameless portfolio plug) and that was enough for me.
The problem is that my code was never maintainable. Problems arose when I stopped working on a project for a few days, or switched from my laptop to desktop. I would sometimes forget what exactly a piece of code did and if it was even still useful. After each project, I would chuck it aside and hope never to have to touch it again.
There is a lot of content on the topic on the difference between programmers and developers out there, but not as much on how to go from programmer to developer. I’ve seen many of my classmates work well individually, but struggle to manage a team of programmers in group projects. Additional manpower always seemed to create more problems than it solved. This is not about how to be a decent human to other humans (I’m way too unqualified to comment on that.) This is about the technical side of things, and what needs to be done to write awesome code.
Side note: There are plenty of opinions on the definition of programmer and developer out there. For the purposes of this post, a developer is a programmer that creates software that is maintainable, while a programmer just writes code that serves it’s purpose but isn’t necessarily so.
If you are already familiar with version control, code reviews and testing then this article is not for you, congratulations on being a good software developer. Those of you can feel good about yourselves and may wonder, “8 years and only now does he learn these essential topics?” I started learning to code by reading books out of interest, school did provide some lessons but I had never applied the knowledge outside of academia. It felt like too much effort to do something I wasn’t comfortable with at that time. Of course I’m now kicking myself over all the time I could have saved if I had just learnt these things.
Programmer != Software Developer
Getting to the point (or three to be exact).
- Version Control – No exceptions.
- Code Review – Assume all the code you create is bad until you get a second pair of eyes to look at it.
- Testing – All code is worthless until tests are created for it.
This is not so much a tutorial on how to do these things, but rather an attempt to convince you why these are essential for any developer. Tutorials on these can be found anywhere on the internet. I’ve heard Google is a good place to start.
Version Control
What?
This is a way to ensure that all the code you write has a backup, and keeping the different versions of the code well organised.
Why?
Keeping a log and backup of all your work is always a good idea. Furthermore, it allows multiple people to work on the same project having conflicts and destroying your code. Even if you are working alone, you would be able to test new features safely knowing that if everything breaks, you could still revert to a working state.
I used to use Dropbox (yes really) to work with my team. We would all agree to only work on the files that we were assigned. This kinda worked, but provided a lot of limitations, and the occasional merge conflict. And each time one of us saved code that broke the program (like forgetting a semicolon), coding would grind to a halt and frantic phone calling would ensue.
Needless to say, that would not have been sustainable in teams bigger than 5 and version control solves all these problems.
How?
I personally use git but really, any versioning platform will work. There are lots of tutorials on how to get started with git a simple google away.
While versioning provides a nice backup locally, you would usually use online repositories to store the code so you can work from any computer or share the code among a team.
I’m sure you’ll have heard of GitHub, the site that has that cute octocat and lets you host open sourced code for free. Also a github profile that shows you create or contribute to open sourced code is always good for the portfolio.
If it’s a personal project, BitBucket lets you host some private git or mercurial projects for free. If you happen to be in school, GitHub provides unlimited private repos for students with their awesome student developer package.
Code Review
What?
Having another person look at your code before you let it freely mingle with your main code base.
Why?
Assume all code you write is bad. I’m not saying you are a bad programmer, but everyone makes mistakes. Be it leaving some useless debugging variables, or accidentally forgetting to remove that chunk of commented code*. This can be caused by anything from coding at 5am to all those distracting Facebook notifications that keep popping up on your phone.
* Side note: Do not comment out large swaths of code and leave it there. That’s what version control is for. The code will always be saved in your history and there is no reason to leave old unused code commented out and taking up space.
How?
The basic idea is to have a main branch of code that does not get worked on. All other work in progress should be put on separate branches.
GitHub and BitBucket both get mentions again here. Both platforms have a nice simple system to create Pull Requests (PRs) allowing you to request that your branch get merged into the main branch. Creating a PR consolidates all the code changes and puts it in one neat page for the reviewer to look through *.
Generally, the idea is to have at least one other person look at your code regardless of how simple the changes are. Even if you’re working alone, PRs also give you one more chance to look through the code and catch any mistakes you would normally have missed.
/ on GitHub / BitBucket. I’ve not tried anything else myself.*
Testing
What?
Testing to make sure what you wrote works. This can be done manually, but we want to talk about automating that process.
Why?
This time, assume all the code you write is broken. Projects can become unwieldy to manage fast.
Imagine this scenario. You’re a web developer and have just spent hours banging out the super important feature that a client requested. It’s 5am and you finish it just before the deadline, everything looks great and you send them the new website. You go to sleep after a job well done. If only it ended there, but the client calls you a couple of hours later telling you that the site’s main navigation has stopped working on mobile devices and the help page is now redirecting users to the F1 site.
While it may be a bit exaggerated, I’ve had, and I’m sure most of you (assuming you are coders) have had or will have firsthand experience of this. If only there was a way to ensure all the features worked after each new piece of code (you can see where this is going).
How?
This comes in two steps. The first is to actually write the tests. Depending on the language you’re coding for, there are many testing frameworks to use. (How to write good tests is a topic for another post.) After choosing your testing framework, you should write tests to ensure the basic functionality of the application / website / program works. I used to (and still do) find writing tests a pain in the behind, but the benefits have proven to outweigh the costs. I have spent much less time tearing my hair out over why seemingly random features have broken.
Save your hair, write tests.
The next part is further automating the automatic tests. By this I mean that you don’t even have to run the tests by yourself. There are many ways to do this, but the one I’ve used is TravisCI and GitHub. TravisCI automatically runs the tests each time I push code to GitHub. Again, how to do this is out of the scope of this post, and there are plenty of resources on the internet. If you don’t have access to the internet, I suppose you could ask random passers-by.
Software Developer?
While this may not be the only things you need to know to engineer good software, I believe it’s a good starting point. There are many software engineering principles that could be followed to make better sustainable software but that usually differs from company to company. Having this foundation is key to bettering your code and by extension, your life.
tl;dr
To be a good Software Developer, you need to at least implement some form of version control, code review system and automated testing.