Smart {Code};

Author: samuel

Self-Taught vs. Bootcamps vs. Getting a CS Degree: Which Path Is Right for You?

Posted on by samuel

The comparison between the different ways of getting into tech is one of the most discussed topics of all time. Some are for the idea that one specific option is best compared to the others. 2020 has given us a fair share of setbacks, inclusive of the pandemic, which is why I thought it was better to go back to this topic and look further into it. After reading this, you’ll have a different opinion about this topic because we’ll have looked at the dimensions in which it’s usually discussed from other perspectives.

. . .

1. Accessibility

It doesn’t require much to start your development career. For a self-taught route, the only things you need are a computer, your time, and an internet connection. Getting into a Bootcamp requires you to pass an assessment test for your skills in programming. Some will even send you what you need to know before going forward with your application. The most inaccessible route is getting a CS degree because you need to have some qualifications from your high school or other institution to apply.

. . .

2. Price

As a self-taught developer, I’d say the self-taught route is the cheapest. There are a plethora of free websites, courses, and books on the internet to get your feet wet with any technology out there. If that’s not enough and you need specific direction or structure, there are a lot of paid courses where instructors take you on a journey from beginner to whatever stage you want to be. The highest you might end up paying maybe a couple of hundred dollars for the paid, guided courses.

The Bootcamp route is not as cheap because you will have that instructor-student physical relationship. It is less expensive than going for the CS degree. The best part about paying for a Bootcamp is that they have different payment options. You can pay nothing upfront if you go with the deferred tuition modal or income-shared agreement model. You can also pay for everything upfront, which might cost something like $15k-$20k. If you look at the CS degree route, you’ll end up paying more than $40k a year even with government support and all.

. . .

3. Relevance

Starting with the self-taught route, you’ll notice that you’ll only have to learn the most useful targeted material to get you ready for the market. The only issue is that most beginners never know where to begin, which is why they end up confused when it comes to deciding what to do. If I were to prepare a course outline for my younger self with all the information I currently possess, I’d go with the most targeted approach. I’d be clinical about what to learn amidst the chaos.


Bootcamps are best when it comes to this attribute because they are a controlled environment. Yes, they may teach you a little bit of what you will not use, but they will ensure structure. In a Bootcamp, you get to dive in and get your hands dirty with modern technology and proper direction in case you ever get lost in the noise. A CS degree is by far the most bloated way of learning a particular discipline. I know software developers out there who say there are some things they wished they never wasted their time with because they have never used them anywhere in their career. I am in no way bashing the CS degree route, but in comparison to the other two, you will have to learn some units that you are never going to apply in your career.

. . .

4. Difficulty and Support

I believe you are going to agree with me when I say that teaching yourself how to become a developer is the hardest thing to do. It is not impossible. It is just hard. As a beginner, you will not know where to begin. You are going to need a lot of discipline, commitment, and determination. The estimated time of completion might be longer. You might get lazy at some point, lack motivation, or experience the impostor syndrome. The only support you will have is forums, and thank God for Stack Overflow, am I right?


Bootcamps are a bit easier to go through when it comes to this because you have structure, deadlines, and instructors checking up on your progress. The only hard part about a Bootcamp is that you are required to go through the whole experience in just six months or less depending on the Bootcamp attended. If you have some development before joining a Bootcamp, you have a better chance of shining. A CS degree route is the easiest to go through because you have enough time to catch up and polish on your weaknesses. You might have support from your instructors, but this largely depends on the institution and your instructor’s availability.

. . .

5. Speed

The speed in learning goes hand in hand with the relevance concept. If you choose to learn targeted material, you’ll end up learning faster within a short time, which is where the self-taught route shines the most. Assuming you have done proper research, have a clear sight of the path you want to take in development, and all the material you need to get started, you can finish your course in a short time with the necessary skills for the market. Your speed in a Bootcamp will largely depend on how long the Bootcamp is supposed to take. You might finish faster if you knew a little bit of development before getting into one. A CS degree takes the longest time to complete. A typical CS course takes four years.

. . .

6. Opportunity


I believe for most people, the possibility of getting hired is a crucial determinant. Here is why. If you choose to go with the self-taught route, you have to prove yourself to your employers. At this point, you don’t have any credentials to your name, you don’t have a lot of people in your network, and 99% of the freelance jobs you get will be dependent on referrals together with a well-built portfolio.
With a Bootcamp, it is easier to get hired. Some Bootcamps even have companies that have partnered with them to make it easier for their graduates to get into the industry immediately they are through.
With a CS degree, you have a better shot at getting internships or an actual job. The backing of an institution and that piece of paper is enough to get your foot in the door.

. . .


I have a few views of my own about all these. Regardless of the route, you’ll end up putting in a lot of effort. In other words, you’ll end up learning things on your own. I know most self-taught developers and Bootcamp alumni consider a CS degree as a partial waste of time. I do not entirely agree with this because CS starts from the fundamentals of programming and computers with a clear direction compared to self-taught and Bootcamp. Why not take a hybrid approach? Get a clear path through the area of your specialization. Then get into a Bootcamp that offers what you want and get ready to work very hard.


Another important thing to consider is your current life situation. If you cannot afford to pay for a Bootcamp or a CS degree program, the self-taught option is for you. It is also an acceptable choice if you already have a full-time job but fancy going into development. The Bootcamp option is sort of in the middle because you’ll get the most out of it if you have prior knowledge in tech and can’t afford a CS degree. If you are fresh out of high school with nothing to do and a lot of time in your hands, you can go for either the Bootcamp or get yourself into a CS degree program.


All roads will lead to where you want to go. Just choose wisely the path on which you want to start your career.

Writing “Clean Code” Is a Myth. Code Is Never as Well-Organised as You’d Expect

Posted on by samuel

When we think about writing clean code, we often think of code written with purpose where each line is perfectly thought out. Code that was planned out before it was written. So well-planned that the first time we run it, it just works. No errors, no flaws, first go. But why is it that for most of us, when we write code, it is far from this ideal?
A lot of times writing code can feel like being in an intense battle with your machine. No matter what you do, the errors just keep coming. To make matters worse, the error messages are unspecific, which means that when you google them, you get nowhere. Your frustration keeps rising, and the bug that you thought would be a quick five-minute fix, ends up taking hours!

. . .

I think that the perception that we have of what clean code is and how it’s written is flawed. That perception is dangerous because it can scare off a lot of beginners. The reality of programming is often far messier, where you pretty much write a line of code and all of a sudden an error occurs in the old part of the codebase that someone really should take a look at and refactor, but since you’re under a time constraint, you end up writing a quick fix and list like that, the tiny feature that you were going to implement has become a complete mess.

Code will always be messy at first unless you’re working on a project where you’ve done all of it before, where you know exactly what to write and where to put it, which is sometimes the case. If you’re doing anything that’s new to you or that you haven’t done a thousand times before then the experience is a lot different. Do not worry because there will be code reviewers and assigned documents that are to help you write clean code.
At the end of the day, in most software engineering jobs, things are not as well organized as you would expect. Mostly, the code that you write on a day-to-day basis is subject to a lot of outside factors. I mean things like time constraints, old code basis that is not maintained or even other people’s bad practices.

The expectation that you’re going to be able to write a piece of code that works perfectly, and is purposeful every single time, is far from what writing code looks like. You should still, of course, aspire to do all those things, but in most companies, it’s not only your job to write a clean piece of code. There’s also a trade-off between writing clean code and being efficient. Thinking that every code you write has to be perfection is neither realistic nor what anyone expects from you. Trying to write perfect code is super inefficient because to do that, you need to spend so much time thinking through everything that you do, and that ends up slowing you down.

The way that you should usually work or think about your work is to write, refactor and review. That is, you first focus on writing the code and making it run without errors. After you’ve got to spend some time refactoring the code you’ve written, it’s easier to refactor existing code than it is to write it like that from the beginning. Finally, once you’ve spent a bit of time refactoring and essentially cleaning up your code, you can send it in for code review. After review, I would say that you have successfully written a pretty solid piece of code while also maintaining a reasonable level of efficiency.


What I’m mostly trying to say is that the perception that we have that clean code is equal to perfect code is usually far from the truth. That is why big companies have practices like code reviews. The first implementation of something is usually far from perfect. Even though it may be inefficient to write clean code from the start, it doesn’t mean that you shouldn’t try. The fact that writing clean code is inefficient is not an excuse for writing bad code. The aim should be to write the best code you can at the time.

As you write, you often know a fast and a sloppy way of doing something and the slower but more proper way of doing it. This is when you should opt for the slower, more proper way. Instead of writing three nested for() loops, it may be worth spending a couple of minutes trying to figure out if you could come up with or google a recursive function that could remove some of the loops.


I believe that most of us know when we are being sloppy and just cannot be bothered doing things the right way, even though we know how to do it the right way. This is when I would suggest spending that extra amount of time doing it the right way from the start. On the other hand, let’s say that we’re implementing a new feature. Usually, there are a lot of ways to implement the said feature. In this case, I would not suggest spending several hours trying to research the most optimal way of implementing that feature. Instead, I would prefer just implementing the feature in the best way that you can, and then spending some time on refactoring that and making your implementation a lot more elegant.


A trendy term right now is “action bias”. It means being biased towards taking action over inaction. That is how you should be thinking when you’re creating clean code, meaning you can spend time researching things and trying to do it better, but you’re biased towards taking action. I think you’ll be well off if you keep that in mind as you code.
The thing to understand is that clean code is the product of several people working on a project together and not just one individual. I believe a lot of people feel like crappy programmers because their code looks like a giant mess.