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:
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.
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
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.
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.
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:
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:
fs.createReadStream. You have to use the
highWaterMarkproperty, which is barely mentioned in the official docs
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!