Building Your Tech Portfolio. - Part 1
A series on building your coding projects the right way, from the very beginning.
Photo by Joshua Aragon on Unsplash
Introduction
A portfolio is an excellent way of showing off your skills and interests to potential employers, but building and maintaining one can sometimes be daunting.
Throughout this series, we’ll take a look at some of the ways to lighten the load and integrate various best practices in your hobby projects early on. That way, you won’t be rushing to dust off your 3-year-old TODO App, which, let’s be frank, could do with a bit of polishing up before you share it with an interviewer.
Who is this series for?
Anyone looking to start building their coding portfolio or tidy up their existing one. If you can genuinely say that your projects are up to the highest standards — in terms of best practices, testing, documentation, and all the other things we would like to see in a project — then this article might not be for you. But let’s be honest, you wouldn’t be here if that was the case.
It doesn’t matter if you are just starting in the engineering field or if you have been around the block a few times. This article is aimed at anyone who wants to improve their portfolio projects.
Why should we do this?
For me, the reason was quite clear: I had created most of my hobby projects before I was a professional engineer, and at the time my engineering knowledge was fairly limited. I would build a project and if it worked, it worked! No tests, no comments, no documentation, no refactoring, etc.
Of course, this is common practice for students and junior engineers that have just begun their careers and are trying to stand out. However, it left me in a tricky situation a few years after my first job.
During my early career as a software engineer, I wrote more than 50,000 lines of code. Even though not all of it was good, I was constantly learning more about designing and writing better code. Besides that, I learned the importance of unit testing, reusability and clearly documenting your code. Nevertheless, I encountered one big problem:
I had nothing to show to my potential employers.
All my hard work was hidden behind private repositories, closed-source projects, and non-disclosure agreements. All I had was a few old and poorly written python scripts, some screenshots that a previous client had so graciously provided me with, and the promise that I was a half-decent engineer.
Of course, there are technical assessments, take-home assignments, and live coding interviews, but you need a foot in the door to partake in those. So this series is just that, a way to stand out and get your foot in the door.
Where should I start?
“The first million is the hardest to make, so start with the second million”
-Arnold Schwarzenegger
I know right, it’s a crazy analogy and what does it have to do with your portfolio? But stick with me here, I promise it will make sense.
When Arnold said this on a podcast, everyone seemed confused. Arnie played it off as a joke and everyone laughed. Perhaps I am looking too far into things and it was actually just a joke. But what he said seemed to have a deeper meaning and it really stuck with me.
Growth is usually exponential and though you can never skip the beginning, you might be able to accelerate it by adopting the mindset of already having that first million in the bank.
This translates rather conveniently to the field of software engineering. As you probably know, it is just as hard to maintain a codebase as it is to create one. That means we need to write our code with that second million in mind.
Of course, I am well aware this means that it will cost us more time to create a project. You might think that this is where my growth analogy falls apart, but keep in mind that speed does not equal growth.
By creating our projects in a clever way from the very beginning, we are setting ourselves up for low-maintenance success in the long term.
To be perfectly honest, I haven’t always done this in the past. If you look at my GitHub Repository today, it would probably make me look like a hypocrite. But that is exactly why I am writing this, to prevent other people from making the same mistakes and to motivate myself to continue to improve my own portfolio.
Throughout this series, I will discuss some basic strategies and best practices for writing code that you can be proud to show off. Furthermore, we will take a look at different ways you can organize and deploy your projects in a way that is easy to maintain and easily scalable.
In the next article we will start with cleaning up any existing projects you already have, so stay tuned…