This is the second part of the blog series Journey of the Programmer. Check out the first part here.
You have probably already heard the following phrase several times.
If all you have is a hammer, everything looks like a nail.
Meaning that if you only have one tool at your disposal, you’ll try to solve every problem, you come across, with that tool, and you may not even realize that it is not the right tool.
This is especially true for programmers; it can be very difficult and time-consuming learning a new tool (programming language, software etc.). So we often stick with what we already know, without being aware of the benefits we could get from a new tool in the long run:
Why should I learn how to use git when I can just copy-paste my project folder and add a timestamp to the name?
Exactly! You won’t know until you’ve tried it (or until you lose data because you weren’t doing it regularly enough).
This will be a sub-series to the Journey of the Programmer series (I know, a lot of introductions and no meat) where I will be talking about tools that I use every day and that have improved my workflow and my programming experience in general. The posts will be numbered 1a, 1b, 1c etc., and they may be scattered all over the Journey of the Programmer series.
I am aware that some of the tools I’ll cover can be an almost religious matter for some people. The tools I will be talking about are not the number one best tool that everyone should use, they are the ones that I am using and that have already brought me huge benefits. However I will also try to cover alternatives that may fit people with other needs.
This is the first part of the blog series Journey of the Programmer. Check out the next part here.
I have been coding, since I was 13 years old (that was more or less exactly seven years ago at the time of writing). I have been mostly self-taught, most of the stuff we had in school, wasn’t really news to me (I only had two programming courses, all in all only about 50 45-minute lessons). This brings the obvious benefit that a lot of things that I would have to learn in university, I will have already learned. Of course this is not the main reason why one should learn how to code. Besides it being fun (most of the times), it will also teach you another way of thinking and a more pragmatic approach to problem solving.
However, not all is well, and this is why I am writing this post. As my projects grew in size, I started running into problems. Often those problems were code duplication or just bad structure and sometimes I was able to solve those problems. But other times it just made the code unmaintainable, I lost motivation and just straight up abandoned the project. Although I knew how to code, I never learned anything about project management or writing maintainable code.
This and the last year I got the chance to work at a software company (five months altogether, in one two months and one three months block). I learned a lot while working there but I always felt like, I could do better. I wanted to know how to write good code and how to tackle large projects without the overwhelming feeling of having to do everything all at once. So, I decided to write a blog series about just that.
I will be writing posts, as I learn new strategies or techniques that make me a better programmer. As a consequence, this will not be a regular series, I will be posting whenever I discovered something that I feel like is worth sharing.
I hope you will enjoy the posts that are to come. I would also love to hear about tools or techniques that you are using and why instead of the ones I present.