I have had this blog post in my mind for a while. After finding the source code of this old project of mine from the last year of high school I figured that it could be a good opportunity to not only make fun of my awful code from back then, but also to take a step back and reflect on where I am now, how I got here and what I learned since then. In the hopes of helping others walk a similar path if they so desire, or if this analysis of my own experience inspires others to reflect on their own careers as well.
As with most of the topics I enjoy discussing, I ended up writing quite a bit. So I decided to split this blog post in three parts, in case you want to skip one that you aren’t interested in. The first one, which is the one you are reading right now, is about why I ended up pursuing computer science, what I liked about the field, how it compared to other fields that I was also interested in but ultimately decided not to study (and the reasons behind that), and what I discovered that made me fall in love with CS.
The second part will be a view on what I knew (or better, what I didn’t know) when I worked on the project that this series of blogposts is about, and, most importantly, a deep dive into the code. Analyzing how I could have made things better and showing how I was lucky to even know how to tie my own shoelaces back then, based on the intellectual level I was displaying. This might be useful for the folks who are studying programming-related fields and want to understand a bit about how bad code looks and why.
And the third and last section goes a bit deep on what happened with that project, some conclusions I am taking away with me after this code analysis, and some further reading material if you feel like it.
Mind you, I am not an expert in the field. I am barely finishing my 4th year of professional experience, which I imagine is quite low for some of the folks who are reading this. My intention is not to insinuate that I am some kind of code guru, because there wouldn’t be anything I hate more than that. I am just a guy who has been making stuff for some years now, learned how not to do them fairly recently, and want to share those mistakes using my previous work and myself as a perfect punching bag.
Having said that, if you want to challenge some of my observations, either because you’re more experienced than I am or simply because you want to share your point of view, please do so! Let’s spark some discussion so we can all keep on improving our skills even further :)
Hopefully, this series of write-ups ends up not only being an analysis of who I was back then, but also works as a time capsule for who I am now. And who knows, maybe I can come back in ten years to look at this and see how much of a moron I was back then. Because if we don’t think of our past selves as idiots, then have we really grown since then?
So if you are in for the ride, hope you enjoy reading me rambling about stuff.
Knowledge is power
Programming has always fascinated me since I was a kid. In middle school, I had this fantasy of being able to create my own games, which I imagine was pretty common for my generation. Going to the extent of messing around with RPG Maker, but I was too young to learn the ropes of what programming was even about. Fast forward to the technical high school with a focus in electronics I attended, and I was faced with the basic concepts of the field for the first time.
Learning the ins and outs of these basic concepts felt like learning the actions in a puzzle game, with the difference that these would allow me to do anything (that is allowed by a Turing Complete language, mind you). It felt very empowering at the time, and still does to some extent. Which is why, when pursuing a higher education at the university, I ended up choosing computer science instead of electronics.
Despite being scared to do this switch (I even first enrolled in electronic engineering, and even did some of the introductory modules as well), I was very relieved to have my choice reconfirmed while I learned more about computer science as a whole, and about myself and my preferences. Turns out, math can be super fun and interesting (as long as it is discrete math and doesn’t involve those fake imaginary numbers engineers deal with). It made me realize a lot of things that I appreciate about the field and industry besides the ones I listed when comparing it to electronic engineering back then, when I had to make a choice. I have been thinking about these points for years now, having listed them in a note I keep around for when I am asked about career and industry options from younger folks or people thinking of switching careers. Which I will now talk about.
The first aspect that I have learned to appreciate is the massiveness of information on the internet. The internet was originally conceived by programmers and electronic/system engineers back then, so such field topics have been present in the bus of information since day one. The amount of information you can find in any tangential topic is stupidly big, to the point that it has become a problem to actually filter the good stuff (which is even more relevant nowadays with the amount of AI slop spreading through our dear interweb).
This might be obvious for anyone in the industry already, but it’s not an aspect I take for granted. Some years ago, I was tasked by a relative to look up a PDF for a specific technical dentist book (I know, I know, this is, however, the usual modus operandi of the free higher educational system of a third-world country), and I was surprised to find, well, that I couldn’t find it. It made me realize how lucky we are that, in computer science and software engineering, we get to read entire books, papers, and blog posts entirely for free, with some authors even putting their own books in HTML form for people to read them freely and reference them more easily in a day-to-day setting.
It’s astonishing, really, how generous people are with their knowledge in computer science. This is, of course, also the case in various scientific fields where you can simply send an email to an author asking for a copy of their last paper, and they will most probably send it to you freely, no questions asked (which tends to happen because of how academic journals work, it’s wild). Maybe it’s because they are just happy that anyone is interested in what they want to say, and God knows how hard it is to find someone like that in an age where everyone has something to say, if such a comparison could be used with non-academic people.
But in any case, if you are a curious mind with enough critical eye to distinguish what’s worth your time learning-wise, the internet is filled to the brim with blogs, books, and videos available for free. Hell, nowadays you even have entire computer science lectures and courses uploaded by MIT freely on the internet. How many other fields have this volume of knowledge freely available at your fingertips?
This amount of information available also means that, if you are dealing with a problem in your code, chances are you will find a thread or post from people experiencing the exact same thing, I must sound like a broken record at this point, but I don’t think a dentist would be able to look up online a problem they are having with a patient and get out with something to try at least (I am sure they are doing so with LLMs nowadays, with varying results and none to make responsible besides the person following the potentially hallucinated instructions).
Granted, like the dentist, there probably are a lot of false positives and local minimums that will detract you from the right path to reach the solution, but I still believe it’s a very useful source of knowledge to draw from, if you are conscious about its biases and limitations.
This, however, has been shifting quite a bit since the explosion of LLMs, and how people interact with them, resulting in these error->potential solutions for things to not be out in the open anymore, and instead stay in the programmers’ LLMs chat of choice. I have little sympathy for Stack Overflow, both its active hostile userbase (or at least part of it) and how they treat the answers people give on the forums and their original commenter have made me a bit disgusted with the platform in general, but knowing that this collective well of knowledge is getting dryer by the day is not great either.
Open source and the holy hobbyist
One of the aspects I enjoy the most about this emphasis of the field in sharing knowledge is open source. It makes a lot of sense if you think about it, if X needs a software that does A, and Y also needs it then it doesn’t make sense to reinvent the wheel and to instead work together. There are innumerable advantages to this: transparency in the development process, anyone can try to contribute to it, big companies may come and sponsor the project to make sure it receives the support it needs for their usage, allowing a fork to survive if things go south, and so many more.
The fact that you can find a niche project made by a dude in the Himalayas, that is useful to you and maybe 100 other people, and being able to collaborate together to make it better, feels like magic to me at times. It is one of the most fantastic experiences I have encountered when interacting with human beings on the internet.
Also, the ability to use these personal projects of yours, being open source or not, as part of your portfolio and experience makes it even better. Showing to your potential employer what you are capable of in a more transparent way than solving some random leetcode (which I would argue is one of the bad aspects the field has), while also working on stuff that is fun to you, is a great way to justify spending time on hobby projects.
…But that’s one of the problems, isn’t it? The fact that one must “justify” spending time having fun building stuff. The ever-increasing necessity of being so-called “productive”. Don’t get me wrong, I do love the fact that my day to day work is so closely related to what I would consider my hobbies (on a good day, that is), which is not something I see in other industries, but it’s a double edge sword. If the productivity mindset starts crippling what you once enjoyed, it can spoil the entire thing if left unchecked. I am lucky enough to have so many interests that I am rarely bored, but I would lie if I said that, after a long workday, I would want to keep doing “the same thing” instead of catching up with literally anything else. There is a reason burnout is so rampant in our profession, and it might be hard to see it when we are young, but I guess it’s good to keep it in mind. Remember, it’s not a race, it’s a marathon.
The comparison might be a bit off topic here, but in his book ”Designing Games: A Guide to Engineering Experiences”, Tynan Sylvester mentions how, in the context of a game, if you are rewarded for doing an action, you might tie the feeling of fun with said reward instead of the action itself. And when the player stops receiving said reward, they find the activity dull or don’t feel like engaging with it anymore. As with the rest of the book, it is not difficult to interpret this in the context of using your same skillset to do personal projects that you use for your day work and get paid for.
Maybe complaining about your work abilities, mixed with what you enjoy doing, is the kind of problem “high-class” citizens experience, and complaining about it might sound weird depending on who is there to listen. But mental effects aside, it’s undeniable how empowering it is to know that you can start most projects with just a computer and free time. It might seem like a romanticized author-y view of the engineering process, and one would still probably need investments depending on your expectations and necessities, but the feeling of having the ability to create out of nothing is magical, or at least that’s how it feels to me.
Short circuit
I talked about what I enjoyed about programming in general and why I decided to pursue computer science because of it, but I believe explaining why I didn’t pursue electronic engineering is just as enlightening as my earlier reasons for pursuing computer science—if not more. The main thing that drew me out of electronics is the physicality aspect of it. If there is a problem, actually diagnosing where it’s originating can be a long, arduous, and not pretty at all process. Because of all the moving parts, I always felt like the debugging process was full of friction.
Now, mind you, software engineering in general (or in some of the places I have had the misfortune of working on) is no stranger to this. But I would argue, at least based on my experience, that despite all of the potential failure points, it still ends up being faster because of how quickly you can move through the whole process, as well as being able to, well, look up your problem on the internet. Still, relying on the past knowledge of internet minds is so incomprehensibly useful.
The other characteristic of this physicality is the tools. Me being a HS kid I barely had the necessary tools to do things “the right way”. Sure, it’s useful to learn how to work with the minimum indispensable; it builds character, which is what most engineering universities here pride themselves upon, but I also don’t think romanticizing marginality and low budgets is the answer. In software, you may have some proprietary tools that make some aspects easier, but I have yet to hear from someone who argues that they can’t work without X. That’s mostly also in part because almost all the tools we use for work, including the operating system I am writing this on, are open source. So I would like to take this ooportunity to thank all of the open source developers for their contributions, as they will never receive the appreciation they deserve, and the current engineering landscape (and most services around the world) would be way worse without them.
And of course, all of these points aren’t even taking into account what happens if something breaks/burns in the circuit that you are working on. “Oh, you burned this super-specific chip? Uff, bad luck champ, that is a 50 bucks mistake. What is that, you don’t have a replacement at hand? I guess you would have to wait 6 months for one from China to arrive, too bad”. In comparison, trying stuff in software doesn’t result in an economic hit, nor an irreparable damage, most of the time, that is (it’s always a good time to check that you are making backups of your data bases, dear reader).
One could, of course, say it’s a skill issue, and you wouldn’t be wrong, but I have lost count of how many times I felt I was wasting time dealing with things unrelated to the problem I had. Like if these were an overhead to the real, actual problem I am trying to solve, and you are forced to walk back 5 steps when trying to advance just one. I do, however, have to say that I have gone multiple weeks dealing with stuff that wasn’t originally related to what I was trying to solve at work. I like to think this is often the exception and not the rule in programming. This also depends a lot on the technologies you are working with, of course. So if any of this resonated with you, don’t work on embedded systems.
Working hard or hardly working?
There are other aspects that have been great perks from working in the field, like all of the work opportunities that are available. Sure, we are at a particularly low point in that regard, with companies firing left and right, overqualified people filling the market, and leaving no room for new junior hires. I wouldn’t like to be in a position to need to enter the workforce today, absolutely, but at the same time, my other professional friends who work in other industries have had a hard time trying to break in, if they even managed to do so at all. And with the ever increasing need for software maintenance, I like to believe that, at least eventually, people with the right skill and mindset will be able to enter if they want to.
Because that’s another aspect of it, while other engineering fields might require you to be on site because of the physicality aspect, most branches of computer science and software engineering don’t require your presence in an office. This makes it great for companies to hire cheaper people abroad, increasing the number of job offers you have (but also increasing the number of applicants, depending on time zones and work permits). And of course only benefits folks in positions similar to mine, and makes it harder for people living where these companies tend to operate. To those folks, I am sorry that you have to go through this.
Another aspect of this is the existence of jobs that offer relocation without the need for a formal degree to do so. I have had friends relocating to the UK with only a fraction of my formal education (granted, they are amazing engineers on their own), and it is not uncommon. But such a thing would not be the norm for other industries, and if there happens to be a relocation opportunity in those, chances are that you would eventually need to take some exams in order to get the necessary certificate to work in your field in that country, besides having gotten your degree here in the first place.
Relocation is, however, not for everyone. And being able to work anywhere in the world, earning a pretty decent salary compared to what my friends and family are used to, must be one of the biggest advantages we have (although depending on the industry and branch of computer science you want to work with, it might be difficult to get an opportunity without relocating, sadly).
Too dumb cool for school
Of course, I owe a lot to my formal education at the university, which, most importantly above all, gave me the tools to learn. I have tackled many side projects because of personal interest, and I was able to learn all the necessary languages and tools to do so, thanks to the baseline of knowledge I got from it. If I could give a recommendation to anyone interested in pursuing a computer science adjacent degree is to look for one that teaches concepts, not technologies. Having said that, I have been taught so many “concepts” while working on my degree that working on an average software company feels a lot like killing a mosquito with a bazooka.
Despite me praising the field because of the opportunities it has, how its currently treating those without a formal degrees, and how it looks like there is never enough people to fill all positions (or at least, it used to), having a formal degree under your belt (or at least the knowledge and way of thinking that one helps you develop) will make a world of difference to make you stand out across other applicants in what I believe would be a future filled with people that “know how to code”. All of these free courses and lectures that companies have been offering for over a decade now, besides an opportunity to train their own employees, are an attempt to massify the market of potential workers so as to raise the competition with each other and bring salaries down. I believe we are not that far from there, if we are not there already, so whatever you decide to pursue, there are worse choices than trying to get a uni degree, even if the only worth it has for you is writing it down in your resume. Or maybe this is just me trying to justify the 8 years it took me to get my degree, but I guess time will tell.
And it’s quite ironic if you think about it, because for all of what the university taught me, it didn’t teach me how to write “good code”. Which checks out when you start seeing code written by people in academia, I guess (fittingly enough, my master’s thesis code was also pretty bad). That’s not to say that the knowledge you get when studying a degree like computer science is useless. I want to believe that all of those subjects I studied back then (or at least most of them) molded my mind and way of thinking to what it is today, and inform my every decision at work. And the ability to write “good code” is the type of stuff that you can, no, must, learn outside of an academic institution and out in the field. It’s by no means easier, and you have to not only look for places that push for that code to be of quality, but also be open to absorbing how more senior people write code and question your own. It feels like a never ending race, but it’s one of the aspects in this field that I am always looking forward to.
So, if you happen to be studying a degree and get frustrated about all of these seemingly useless math and functional programming topics you are forced to learn, I get it. You want to go out, do a webdev course, and start doing what you actually enjoy, which is making stuff. Because you know your shit and what you need to do to get where you want to, right? Well, maybe consider that the things that you would learn in these formative years you may not get anywhere else, and that after those, you will have the rest of your life to learn what the industry wants you to know.
Most of the time, it’s not the topic itself that is important, but what surrounds it. Being able to get better at absorbing and internalizing new information, and thinking about problems abstractly, by solving them in progressively increasing difficulty with the presence of a safety net, is something that, I believe, doesn’t exist organically in a work environment, and genuinely makes you a better engineer.
Absolutely take this with a grain of salt, but despite its problems, the number of coworkers I have had who don’t regret their time at the university vastly outnumbers the ones who wish they hadn’t pursued it.
The second part of this series, in which we discuss how bad the code from this old project of mine is and how things should have gone instead, will be posted at a later date.
Hope you enjoyed reading this one! Have a good one.
