Smart {Code};

Category: featured

Featured Articles

3 Lies Software Developers Put On Their Resume

Posted on by samuel

How many jobs have you applied to this year alone? How many jobs have you landed? Is there a common denominator? Is there an art to job applications? Lately, I have been thinking about developer resumes and whether it is good or bad to lie when applying for a developer job. First of all, I will not tell you what to do, but it is not as black and white as you would think it is. Why? There are a couple of factors that can hinder you from getting that dream job. Allow me to go through the three that I think are major.

. . .

1. Job Gaps

Job gaps are probably the most prominent things on a resume that can destroy your chances of getting a job. In my opinion, that is pretty unfair. See, when you have a job gap, people think that there is something about you that makes you unhireable because why else would you not have a job by now? It has to be something that you are doing. It has to be your fault. And that is the thing with job gaps. The longer you have a gap, the harder it is to get a job because you have been out of the industry, you are out of touch, you are all washed up just by having a job gap.

To other employers out there, having a job gap implies laziness. I am sure some of you lucky ones have had experiences with people that do not care about job gaps. For most people, employers care about the job gap. So, should you lie about having a job gap? Should you leave your last employer, even though you do not work there, as current? Again, it is not as crystal clear as you would want it to be. Here are a few scenarios that employers do not consider. Say you got fired without warning around the holidays, say, November. Companies do not hire people during that period, so you might not be able to find a job. That is not your fault, but you will probably have at least a three-month job gap, which is not that good.

What if you have a major medical procedure, and you need to take care of yourself first? What if you have to take some time off to look after your family? What if a member of your family gets sick and needs care? What if you have had a job for 20 years and you cannot land a job because you spent those 20 years working with proprietary software? I mean, these are things that you are not allowed to talk about because you also signed an NDA, and no other company has access to it. What then? In such cases, I would leave my last job as current even if I am unemployed.

“I have been freelancing for the last 6 years.” This statement does not usually go smoothly with employers these days. You will get questions, to which if you do not have proper answers, you can kiss that opportunity goodbye. Go ahead, try it. Watch them ask, “Were those freelance projects paid? And can you show us, or were they your friends’ photography website?” They will do anything to dismiss any project you did during your job gap. Also, the employers dismiss the narrative of the personal project. For some reason, they will always interpret it negatively. They always say that personal projects do not count as experience.

The way I see it, you have two options when dealing with the job gap. You can go ahead and leave the last job that you worked at as present on your resume, or you can go through the honesty route and pray that they let you in. I hope that you can manage to find a decent human that believes you and understands that life happens. But in my experience, most people do not care. Do not get me wrong. Job gaps do not apply if it is your first job in the industry. If you come from working at a fast-food joint and have a job gap to go to school to get yourself job-ready, you are safe.

. . .

2. Background Checks

Do these even work properly? Last I checked, background checks usually verify that you do not have a criminal record or something like that. They do not run background checks to check your previous employment, and I do not know how they would do that anyway. How many companies have people on their websites that no longer work there? Probably a lot.

What about when they contact your last employer, Sam? Well, the companies usually ask you if it is okay to contact your previous employer. This is a double-edged sword and a stupid mind game that companies play, in my opinion. If you choose to have them contact your last employer, they will interpret that as you leaving your previous job on good terms with everybody.

Here is the funny part about that: if they are serious about contacting your previous company, they will ask you for the phone number, right? That is where you can provide your friend’s number and have them say nice things about you, hence the double-edged sword. No person in their right mind would give the honest details, especially if you had a manager you would rub shoulders with every day.

. . .

3. Job Titles

This is a juicy one. Personally, I never put the job title that the previous company gave me in my resume. I always put a job title that reflects what I did on the job. Is this lying? Well, let’s dive a little deeper. Let’s say your title at your last job was frontend engineer, but your responsibilities were everything. Frontend, backend, design, marketing, WordPress, you name it. If your previous company was a startup, I am willing to bet that you did almost everything. So, let’s say you apply for a full-stack job, but your resume has the title of frontend engineer because that is the title your previous job gave. You know, you are qualified for this full-stack position. You did all the heavy lifting at your last job. Is it really fair that the company you are applying to assumes that your ability extends as far as your title goes?

Even if you have done way more and you know that you can do the job, you will not get a chance to explain yourself if you do not get your foot in the door. So, on my resume, I would put full-stack engineer. Is this lying? Yes. It is not what the last job gave you, but you did it for a good reason, right? It is actually better than using the title that your job gave you. It makes yourself and your abilities more transparent and gives the prospective company a better insight into what you can do. So, you changed it in a positive light, but technically yes, that is lying because it was not the last title your previous company gave you.

. . .

How About the Other End?

Think about this for a second, do you think companies are 100% transparent with you during those interviews or when they are posting for vacancies? Do you ever look at the absurd requirements? “We are looking for a passionate developer with expertise in Java, C#, C++, x86 Assembly, Python, Ruby . . . ” and the list goes on. Where on earth are they going to find a junior developer with said requirements? Finding a senior developer with those requirements alone is a challenge. Really?

Companies can lie and mislead in the job descriptions and on interviews. They can promise you that you will get to work from home and then require you to be at the office because that privilege is only for the CTO. How about the vacation period? Do they ever deliver on that? Here is the big one, the reviews. Companies will promise a yearly review or every six months, and they can say that full well knowing that they are about to go on a budget freeze and no one is getting a raise at all.

. . .

Why Do We Even Use a Resume?

The entire goal when using a resume when applying for a job is to get a conversation. A conversation will give you a chance to explain your job gap. Guess what, that conversation would not happen if you include a job gap on your resume. Let that sink in for a minute. If I think that I can do the job, I will apply, and I will do what I need to do to make that happen. If I am a perfect fit for the job, I will go for it. I am not talking about security clearance for government jobs here. I am talking about you saying you worked somewhere for two years when, in reality, you worked there for one year and eight months.

I would like you to ask yourself this question: Why are you required to be 100% transparent with a company when it does not have to do that with you? Pro-tip, you are not. It is just what good and honest people do. People like you and me, and in the end, it ends up hurting us. This is very hard to learn and understand because I want to be a good person. I want to be honest. I want to be truthful.

. . .

My Take

The truth is, like with everything in life, there is a game when applying to jobs or working a job, and there is no opting out of playing the game. You have to play the game, or you will get played. Again, I am not suggesting that you tell them that you trained monkeys for Nasa or something like that, but do not let the companies rob you of the opportunity you deserve. You have worked so hard to get to where you are. Let your job be your proof when you get in. Until then, do anything to get that foot in the door.

These are just my thoughts and feelings based on what I have seen and experienced. Sure, you can be good at what you do, but you need to prove that when you get in. I do not think it is lying. I think it is just being true to yourself and omitting the words that will get your application thrown in the trash. I am certain if everyone took the genuine route when applying for jobs, many people would not have jobs anyways. Think about that for a while. I would love to hear what you think.

Array Methods That Every JavaScript Developer Must Know

Posted on by samuel

Arrays are one of the most common things that you’re going to use as a programmer. In this article, I’m going to be covering important JavaScript array methods that are going to make your life as a developer so much easier. As an example, I am going to use a student array of student objects for all of these different array methods

. . . 

const students = [
        {name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
]

filter()

So let’s assume that we want to get all of the students in this list whose ages are less than or equal to 24. All we would need to use is the filter method to filter out every student that’s not under 24.


const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

/*

this filter method just takes a single function, 
which is going to have one parameter of student which 
is every student/item in the array. we'd need to 
return a true or false statement on whether or 
not we want to include them in the new array

*/

const filteredStudents = students.filter((students) => {
	return students.age <= 24        
})

/* 

This line basically stashes all of the students 
whose ages are less than a 24 in the new 
filteredStudents array 

*/

console.log(filteredStudents)

This filtered array method is super easy to use. All you do is return true or false for each item. If it’s true, it is added into the new array, and if it’s false, it is not. The great thing about the filter method and all the other methods in this article is that they actually don’t change the underlying object that you’re filtering over so we can log the students array and it will still have all its items. This is very convenient because we don’t have to worry about changing the old array when we use these new array method to create new arrays.

. . .

map()

map() allows you to take one array and convert it into a new array. In this one, all the items in the new array are going to look slightly different. So let’s just say, we want to get the name of every student. we can get an array of the names by using map().


const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

/*
the method takes a single function, with the 
students/items as a parameter here we just 
return what we want in the new array
*/
const studentNames = students.map((students) => {
        return students.name
})

console.log(studentNames)

/*
If we print out these student names, console.log(studentNames)
we get a new array that is just full of all the different
names of the students.
*/

This can be done with anything within the array. The method is very useful when you want to take an object for example, and just get the names or a single key, or take one array and convert it into another array. This method is one of the most popular ones in JavaScript arrays.

. . .

find()

This method allows you to find a single object in an array. This is straight forward. Say we want to find a student with the name john,


const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

const singleStudent = students.find((students) => {
return students.name === 'john'
})

console.log(singleStudent)
/*
  console.log(singleStudent) will give the everything 
  associated with john in this example, I.e

   Object {
    age: 25,
    name: "john",
    score: 86
  }
  

*/

In this method, the logic is that there is a true or false statement, and it’s going to return the very first array item that evaluates to true.

. . .

forEach()

Unlike these other methods, forEach() does not actually return anything, hence no need for a return statement. Let’s say we need to print out all the names of the students within the student array, we would go about it as:


const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

students.forEach((students) => {
  console.log(students.name)
})

/*
  the result is the name property printed out on the 
  console line after line like so

  "sam"
  "john"
  "dean"
  "timothy"
  "frank"

 */

this is going to work very similarly to a for-loop, but it’s going to take a function instead. So, for every single array item, it’s going to do execute the block of code within the function. This approach just makes working with arrays where you need to loop over items so much easier since you don’t have to write out the clunky long for loop syntax as you’d normally have to.

. . .

some()

This method is a bit different than most of our other functions in that, instead of returning a brand new array, it’s actually going to return true or false. So we can check if some of the students in this array are underage,

const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

const hasUnderageStudents = students.some((students) => {
   return students.age < 18
})

console.log(hasUnderageStudents)
/*
  this will return false because there is no 
  underage student in the array.
*/

So if any student item has an age value below 18, the function will return true. The method just checks to see if anything in the array returns true and if it does, the entire thing returns true.

. . .

every()

This method is very similar to some() except for instead checking for at least one item to evaluate to true or false, it checks to make sure every single item falls under a given condition.
if I use the same code used in the some() code example,

const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 

const hasUnderageStudents = students.every((students) => {
return students.age < 18
})

console.log(hasUnderageStudents)
// this returns false because there are no ages below 18

If I am to change the condition to one which every item evaluates to true, the whole thing returns true

const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 
const hasUnderageStudents = students.every((students) => {
  return students.age < 40
})

console.log(hasUnderageStudents)
// this will return true because every single age property is below 40

. . .

reduce()

This method is quite different than all the other methods because it is actually doing some operation on the array and returning a combination of all those different operations. Let’s say I wanted the total scores for all the items in the student array, normally one would go for a for loop and add the score every single time, and at the end of the loop, you would print out the total score. To avoid the long process, you can use the reduce() method to do this.


The syntax for the reduced method differs from the other methods. Instead of taking the array itself, it takes an array and a property for what we want to reduce everything into and in our example, score. it also takes a second parameter aside from the function, which is going to be your starting point, and in our case, we want to start our total at zero.


const students = [
	{name: "sam", age: 26, score: 80},
	{name: "john", age: 25, score: 86},
	{name: "dean", age: 20, score: 78},
	{name: "timothy", age: 18, score: 95},
	{name: "frank", age: 21, score: 67}
] 
const totalScore = students.reduce((currentTotal, students) => {
  return students.score + currentTotal
}, 0)

console.log(totalScore)
  • As the code reads, we have the reduce() method, which runs a function on every single item inside the array.
  • The first parameter of that function is going to be whatever the previous iteration of this array returned and the second parameter is the actual item in the array.
  • The currentTotal is going to start on the very first iteration with whatever we pass in as the second parameter of the reduce() method which is zero in our case.
  • The first time this reduce() method runs, so we get zero and the ‘sam’ item. So it just does 80 plus zero and returns that, which is 80.
  • The second time the method runs, that return value of 80 becomes the current total, and our next item is ‘john’, so it does 86 plus our current total of 80, which is 166, and puts that back in for the current total. It does that until we get to the very last item in the array, which will output as the total in the totalScore variable.

This method is a bit more confusing, but it is incredibly useful when you need to do some kind of operation cumulatively to all the items in an array, such as grabbing the total price for all the items, daily stock prices e.t.c

. . .

includes()

This method doesn’t take a function as an argument. It takes a single argument. It is usually used in simple arrays that don’t need a lot of heavy operations. Let’s say you have an array of fruits, const fruits = [ ‘mango’, ‘apple’, ‘orange’, ‘pineapple’, ‘lemon’]. a simple way of showing the implementation of the includes() method would be to check if a certain fruit is in the array.


const fruits = [ 'mango', 'apple', 'orange', 'pineapple', 'lemon']

const includesApple = fruits.includes('apple')

console.log(includesApple) 
/* 
this will return true because 'apple' is 
one of the items inside the array. 
*/

. . .

In my opinion, these methods are a must-know for any JavaScript developer because arrays are one of the data structures that are most commonly used for organization. Having a good grasp of these methods will greatly improve your skills and problem-solving ability when it comes to arrays.

5 Design Patterns Every Developer Should Learn

Posted on by samuel

In tech, most developers tend to think about a career progression as junior to senior, to lead, to architect and so on. To some extent, I think something is usually missing from that progression, technical proficiency. One can describe it as going from a consumer to a creator. Think of it like using something like React or Angular in the beginning, and then moving up that technology proficiency chain. From where you are just consuming that framework to where you end up creating a framework that is used by other developers, and they become your consumers.


To get to that point, you have to build up your skill-set, and you start with basic proficiency in your language of choice. From here, you work up to data structures and algorithms, and finally into design patterns. Design patterns are general, reusable solution to a commonly occurring problem within a given context in software design. They are reusable, extensible, and are of industry standards. In this article, I am going to go through five different design patterns that I believe every developer should learn.

. . .

Singleton Pattern

This pattern involves a single class which is responsible for the creation of an object while making sure that it is the only one created. This class provides a way to access it, which can be accessed directly without the need for instantiation of the class object. The most common reason for this is to control access to some shared resource.


As an example, the pattern may come in handy when doing things like a database driver. If you are over on the client, it comes in handy when you want to know the current state of the app that is in a Singleton. The advantage is that you can go and get to that data anytime that you want. The disadvantage is that once you have added that constraint, instead of everybody being able to go and access it directly, you have got narrow down to whomever the consumers are.


This pattern is one of the most misused. Singletons are for use when a class must have exactly one instance, no more, no less. Some developers frequently use Singletons in an attempt to replace global variables. For intents and purposes, a Singleton is a global variable, in that it does not do away with the global variable, it simply renames it. The use of a Singleton is uncalled for if it is simpler to pass an object resource as a reference to the objects that need it rather than letting objects access it globally. You, therefore, have to know and make sure that you are using it the right way and at the right time.

. . .

Facade Pattern

Simply put, this is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes. A facade in the real world would be the front of a building, which it hides all of the internal mechanics of the building. These would be the insulation, the rooms, the plumbing, the wiring e.t.c. The facade pattern gives you the ability to put a nice external veneer on your app. Take a compiler as an example. It has a parser, a lexical analyzer, a tokenizer, and all kinds of fun stuff that no consumer sees.


The advantage of using this pattern is that it gives your consumer a good interface. You can also choose to allow your consumers into the internals if you wish. One of the things to watch out for is the possibility of an oversimplification. You may end up oversimplifying the interface of that compiler that it is no longer usable or valuable. Another thing is over verticalization. You may end up creating a facade that is so specific to a single use case that it is no longer generalized enough to be generally useful.

. . .

Bridge Pattern

This design pattern that lets you split a large class or a set of closely related classes into two separate hierarchies which can be developed independently of each other. Another way of explaining this is progressively adding functionality while separating major differences using abstract classes. A problem that requires this pattern occurs because sometimes developers try to extend subclasses in two independent dimensions. That is a common issue with class inheritance. The Bridge pattern attempts to solve this problem by switching from Inheritance to the object composition.


This pattern involves an interface that acts as a bridge between the abstraction classes and the implementation classes. In a development example, the bridge interface would be something like an API. This approach simplifies code maintenance and minimizes the risk of breaking existing code.

. . .

Strategy Pattern

This design pattern lets you define a family of algorithms, then put each of them into a separate class, and make their objects interchangeable. Consider a scenario where you have a code that is going to go and find customers, filter through them and then send out notifications to them via email and text. You can use the strategy pattern to significantly clean this up by taking the mechanics of getting access to the customer records, sending out the messages and emails, and then creating that as an infrastructure layer. Factor out the filtering of those customers into one strategy, which is the strategy that helps you find the target customers you want. Take the notification strategy as a different strategy which helps to decide when, where and how you want to contact those customers. You can then use that library or that system in a whole bunch of different scenarios, and it becomes much less stressful.

One thing you got to look out for on this is to make sure that you have decent default strategies. So in the case of our refactoring, we go and take the existing logic around the customer filtering and the customer send-outs and turn those into the default strategies, which people can extend later. Otherwise, you get a system whereby default, you are asked to do a lot up front, and no customer wants to do that.

. . .

Observer Pattern

This pattern is the most popular by far because it is almost everywhere. It allows for loose coupling between the publisher, that is creating events and the subscriber or subscribers that are listening for those events, and you can use it anywhere. The con on this particular pattern is that you can go overboard with it. If everything is communicating by events, you can get into nasty event loops, which make the code hard to debug and it just gets chaotic.

There are a couple of solves for this. One, do not use the same message bus for everything, have a specific purpose for each message bus. Two, keep these systems localized. If you are on the client and you have got a button, and it is an admitting and event, you are good to go. You do not need to go beyond that.

. . .

So again, as with all, all of these patterns, use them wisely but use them because most people understand those systems when they see them. For people, who are interested in learning the design patterns, these are just 5 to get started with as you get your feet wet. There are more patterns out there, and many tutorials online that can help you get a good grasp of the different ones.


Do not just learn or read about the different patterns, practice them at least in small projects. The ability to see where specific concepts might be useful in larger codebases comes only with practice, experience, and time. Do not be in a hurry to get as many as you can under your tool belt. If you do not get a pattern instantaneously, look for different explanations and tutorials online, and you will get the hang of it after investing time to research.

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.