If you are interested in Software Engineering, but you think you lack the practical experience to land a meaningful job in the tech industry - even though you’ve studied a lot of Computer Science at the University or in an alternative way -, you’ll probably want to start working at a side project.Why? Because it can offer you a lot of benefits!
Here’s a brief list of pros that should give you the idea of why side projects are useful:
- you have the opportunity to learn a lot while enjoying the relax of having no deadlines
- you can focus on what you like most, or even automate a task that you spend a lot of time on
- you can even give a boost to your tech career, enriching your portfolio with projects different than the hated “_Todo lis_t” / “Tic tac toe” / “Random abused tutorial project”
In this article I’d like to offer you an overview of what I did, hoping to inspire someone else to follow the same guidelines.
First step: find something broken to fix
In my opinion, the best way to get started is to come up with an idea that can help you or somebody else. Usually this is an easy step, and the fact that it shouldn’t take you too long is really important: if you spend too much time on something, without having anything concrete, you’ll probably end up with a lot of code that will never see the light of a release. Start with something that has a well-defined purpose, and maybe expand it after its first release. You don’t necessarily need to create the new Airbnb or Pinterest to be satisfied of your petty project.
The problem that I’ve (rather successfully) tried to solve is the following: I wanted to be able to find all the files that contained a certain pattern in their content, be it a word, a programming language keyword, or a complicated Regular Expression. I’m pretty certain that this could be easily achieved with tools such as grep and awk, but:
- I don’t really appreciate the jargon this commands imply
- I spend way more time on Windows than on a UNIX like environment such as Ubuntu or Mac OS
- the main point of a side project is to build something on your own
Second step: decide what instruments / APIs to use
I spent quite some time with NodeJS, ever since I’ve heard about it at High School. Now that I’ve been working as a Full Stack Developer at Brainwise.it since Summer 2016, I’ve come to know a lot of tricky aspects of the V8 runtime and Node’s APIs, but I’ve never had the occasion to fiddle with the Stream APIs.
Since NodeJS is the environment I’m most comfortable with (followed by Golang) and due to the fact that I needed to scan a lot of files, using it as the foundation of my petty project resulted pretty natural to me.
Also, I kind of suffer the fact that JavaScript lacks typings (using also Golang a lot, I find them fundamental in a great deal of different ways), so I’ve decided to try the latest TypeScript version.
Third step: decide the aspect of your application
Note that by “aspect” I don’t necessarily need to think about the UI layer. I’m mainly talking about deciding how you want to interact with the app. Should it be a mobile application? Or a web one? Or even a desktop app?To keep things simple and slim, I’ve decided to follow the CLI way. Also, I wanted the terminal UX to be colorful and informative in a clean fashion: command line doesn’t necessarily need to be so grey and retro as we’ve come to expect it.
Fourth step: if there’s something you can reuse, reuse it
Since my main focus was handling tons of file scans as fast as possible, I didn’t really want to think about how to render colorful progress output in the CLI or how to filter files via glob patterns as a UNIX shell would do. So I ended up using the following amazing npm packages:
- chalk: for rendering cheerful colors in the terminal
- progress: to provide meaningful output to the user while the app is processing files
- yargs: to parse command line options
- glob: to match file names as a shell would do
Fifth step: enjoy the realization of your project and profit from what you learn in the process!
This is the step in which you have to show the world (and potential future colleagues, or even employees) what you’re able to do.
If I had to sum up which skills I’ve enhanced and what I’ve learnt, it’d be the following:
- if a module’s TypeScript definition hasn’t been posted on DefinitelyTyped, you have to create it yourself. Pro tip: if you extend an open source project, you should contribute back
- I learnt how to create generic functions in TypeScript, which are really similar to C++ templates
- I verified personally that if you open a lot of files without closing them you’re going to have a really bad time
- I discovered that in some cases using the reduce method on an array is way more efficient than map combined with filter
- I learnt how to create a custom Buffer size while reading a Stream with
fs.createReadStream. You have to use thehighWaterMarkproperty, which is barely mentioned in the official docs - I also managed to create a small NodeJS app adjustable enough to be comfortably consumed from both the CLI and another npm module
Beside that, if you think to eventually publish your repo as a package to npm, please check if the name you chose has already been taken. Mine was. Initially my project was called “Discover”, because you know, its purpose is to discover patterns inside a specific set of files. After acknowledging that somebody else took that name before me, I ended up calling it “Pate”, pronounced like the following:
It is reasonably similar to “pattern”, also I was anxious of publishing the project, and when I’m anxious I become hungry.
You can find Pate on Github and on the npm registry. I hope this article was helpful to you, I’ve tried to write it as the post I would have wanted to read before writing this console application. If you have suggestions or comments, please post a response below, and if you liked what you read so far, smash that clap button!