Smart {Code};

Why ‘No Code’ Website Creation Services Will Not Be Stealing Your Job As Web Developer Any Time Soon

Today I feel like writing about web development jobs and the services we offer as web developers. I have always wanted to have the power to manipulate code to my will. Back then, being a web developer was a secure thing. How secure is it now as a career? I am going to talk ever so lightly about services like Squarespace, Wix, and WordPress. Could it potentially ever get to the point where I lose my job as a web developer because of the services they offer? These services offer a good solution to making websites for anyone with no technical expertise, which raises two main questions. Do we need to worry about that? Is it something that could one day replace us as developers?

. . .

The thing is, we are working with two different markets that might not be obvious at first, especially to someone who is not familiar with web development. One of them is for creating static, basic content, web pages, which is something that services like Squarespace, Wix, and WordPress offer. The other one is for creating bespoke web apps. Services like Squarespace, Wix, and WordPress the market that is for the creation of basic static websites, which only hold some information or e-commerce websites, which allow you to take your products, put them on that website, and sell them.

It is no lie that there are so many aspects of web development that these services offer. Tools like creating your backend for you, managing your data, managing your secure payments, your SEO, or in other words, the positioning of your website on Google search and how high you rank in the search. Said services are handy for a non-techie. The disadvantage of these services is that they are pretty limited in terms of what they can offer with built-in themes because even for more extensive and complex customizations of those websites, you would still probably need to refer to a developer. What is going on? Why are people saying that the world of web development is being taken over by such services? In my opinion, that is completely not the case, and to be frank, those online services do not cause a problem for us web developers.

There are very few minor scenarios that I can think of which might affect someone. If you are a developer who creates simple websites for people or websites that just dealt with simple e-commerce aspects, I would say you might find it hard to compete against them unless you are offering more than what said services offer on top of what they already offer. Take me, for example. I can create both simple and complex sites. I have a lot of WordPress clients, and I manage to keep being in business because I offer customization whether in design or functionality. I never use prebuilt themes nor page builders. I code the pages from scratch then add them onto WordPress as themes, except they are exactly what the client asks for.

Think of a web app like YouTube. You can make any site look like that using services like Squarespace, Wix, or WordPress. No argument there, but what about your watch and search history?

What about things like being able to create a channel? What about creating functionality to rank my videos as the YouTube algorithm does? You will never be able to create things like that with DIY services. This is where the clear line comes in between simple websites and bespoke web applications.

A Web application is something that needs an actual developer to sit down, think about, to plan the structure, the architecture, the databases, and all the seamless integration.

There is a lot of processes involved that would never be available on websites like Squarespace, Wix, or WordPress. Sure, WordPress can try and get a little deeper because of the plugins being actively developed, but that is usually not advisable because it affects the size of the site.

How has the presence of these services impacted us as web developers? Well, most probably in some small way, because they did take away that chunk of services that we used to offer. If you are on a path to becoming a web developer, do not lose hope because there are so many custom features that cannot be achieved with a basic template on one of those online tools. Do not get me wrong.

Sometimes I usually refer some clients to such services if I feel like what they want does not require a lot of coding and or customization. It is so effortless for someone to be able to do that, especially when you need something quickly. I refer some clients to such because it just seems like a convenient thing. There is no shame in saying that.

. . .

If you are someone learning or wanting to learn web development, and you were just unsure about a future in web dev, you have an amazing career in front of you, and you should definitely not stop.

How Many Programming Languages Do You Need to Know?

How many programming languages do you need to know as a developer? The main reason for this question is that most newbies see a lot of developers out knowing multiple languages or technologies, and that is the image they associate with when someone talks about a software engineer or any developer in tech. In this article, I am going to try and give my view on the subject with the hope that you will find it helpful and informative.

Now I want to start by saying that this is a very subjective topic. If you ask different software engineers, you are probably going to get a lot of different answers, and it is hard and virtually impossible for me to give an actual number on how many languages you should know. Why? There are a lot of different reasons why someone would choose to go with a specific language or a specific number of languages. Rather than me focusing on telling you to learn, say, five or six programming languages, I am going to focus on the type of programming languages that you should know and what you will gain in terms of knowledge of computer science fundamentals from learning those programming languages.

. . .

Before going into the types, I think it makes sense to discuss why you might want to learn multiple programming languages, even if you are not planning on using them to build applications or work on projects. Simply put, it makes you a better and more well-rounded programmer. I find that you learn more about programming when you learn different languages. There is no way to learn everything about programming from one or two programming languages or languages of the same type. It is valuable to learn different types of programming languages because they introduce new concepts and new features that you may not have seen before.

Another big reason is that it allows you to have a lot of tools under your belt and be able to make a better judgment about what language or technologies to use for a specific project. After all, programming languages are just tools used to accomplish a task. Ideally, you want to use the best tool for the job, and if you only know one or two programming languages, you might not even know that there is a better option out there for what you are trying to do.

. . .

There are two main categories of programming paradigms, and I am pretty sure all programming languages fall within these categories. We have either imperative programming languages or declarative programming languages. Of course, there are more specific categories within those, but first, I will explain the two main categories. An imperative programming paradigm is one in which we tell the computer how to come up with a solution. The important concept in this type of programming paradigm is how to design an algorithm in the process of finding the solution to a problem.

A declarative programming paradigm entails stating facts, asking questions, and having the computer come up with a solution for us. In this type of programming, we are less concerned with how we got that solution but more concerned with if the solution is correct and what do we need as inputs such that it gives us that correct solution. A good example of declarative programming would be something like SQL. You do not describe how you are going to come up with the query. You need only type it out, and the computer gives it to you.

. . .

Programming Paradigms Within the Context of Imperative Programming

The main paradigms that belong to imperative programming are object-oriented and procedural programming. There are a few others as well. There are many different programming paradigms, but these are, kind of, the main ones. It is worth noting that some languages implement multiple paradigms. For example, Python implements both the object-oriented paradigm, as well as the procedural paradigm.

When you look at the object-oriented programming paradigm, you will notice that the idea is to represent the program as a collection of objects that store their internal data and have external accessing parts like a method. Object-oriented programming languages use principles like encapsulation, inheritance, polymorphism, and so on.


  • Features like inheritance can reduce redundancy and allow the same functionality to be used in multiple classes without having to rewrite it.
  • Programs are typically easy to maintain.
  • Code is easily reusable.
  • Some security benefits can be achieved through data abstraction that you cannot get in some other programming paradigms.


  • The size of your programs will be quite large.
  • It takes a lot more effort to design and create programs using this paradigm. This has to do with its complexity, in general, and the larger amount of code that you need to write it.
  • The speed of programs created using said paradigm is usually fairly slow compared to programs built in something like functional programming or procedural.

When you look at procedural programming, you will notice that languages in said paradigm execute a sequence of procedures, which are usually called routines or sub-routines. In case you do not know, a routine or subroutine is simply a series of computational steps that need to be carried out in a specific order. Procedural languages usually rely on block and scope. You will see keywords like if, for, while, e.t.c and these are used to implement the control flow of the program.


  • They do not require much memory to run.
  • They also work well with interpreters and compilers.
  • They have a simple structure and require a minimum amount of code.


  • They do not protect Data very well.
  • Error catching and debugging is pretty difficult.
  • A deeper knowledge of the language and computer instructions is required to write in a procedural language.

At this point, I have covered two main paradigms within the field of imperative programming. Again, the point of this is only to give you an idea of how programming languages differ, and again, why you may want to learn programming languages that are from different paradigms in that there are different concepts, advantages, and disadvantages to them.

. . .

Programming Paradigms Within the Context of Declarative Programming

Now within the field of declarative programming, there are three main paradigms, which are logic, functional, and database. To avoid repeating myself, I am only going to cover functional and logic paradigms. The database paradigm language would be something like SQL, and you can probably imagine why that would be a declarative programming language based on the explanations I gave previously.


The logic paradigm is based on formal logic and, essentially, lines that state a fact or rule about some domain. When you want to solve a problem, you ask questions or write queries that return results about the facts that you have declared. Logic programming allows you to express knowledge in a way that does not depend on the implementation. This means that you are not really telling the computer how to solve it but simply giving it a problem you want it to solve.


  • Facts or information is separated from how it is used i.e separated from the implementation.
  • It is useful for non-computational disciplines.
  • It is very efficient at proving the correctness of solutions.


  • It is not easy to learn or use.
  • It serves a specific purpose that is not appropriate for many of the tasks that you want to achieve.


Functional programming avoids shared data, state, and any side effects using only pure functions that return values rather than modifying the state of a program. This means that functional languages rely heavily on recursion and the passing around of functions as arguments and return values. This paradigm evolved from Lambda calculus and is implemented in some popular languages like Lisp, Scheme, Scala, and even R.


  • Pure functions always return the same result for the same input, making them easier to test, easier to debug, and easier to comprehend.
  • Functional programming also makes parallel processing and concurrent programming much easier.


  • It is hard to represent or implement some notion of state.
  • Recursion is used almost anywhere, which means that there are no standard loops and a lot of people do not like that.

. . .

The main goal of this article was to share these four paradigms and to illustrate that there are many different programming languages, each with a lot of unique features and use cases. Yes, some of the languages within some paradigms are outdated, and you probably will not want to use them. That does not mean that there is no value in experimenting with them for a few hours. I will leave you with a few languages that you could learn that cover those paradigms. I am not necessarily recommending that you learn all of these. I am simply trying to give you an idea of some languages that are in those paradigms that, I think, have some value in at least looking into.

Starting with some older programming languages, Scheme and Prolog are first in line, not that I would ever use them in any real-life project. I, however, think that learning the concepts of how the languages work can be beneficial. If you are looking to get into more modern programming languages that cover some of these paradigms, I would recommend learning Python or JavaScript. They are both scripting languages, and they are both dynamically typed. So, that already gives you a good introduction to a specific type of programming language that you can do a lot of projects in.

I would also recommend learning Java because it is a strongly typed language. It is also an object-oriented programming language, and it teaches you a lot about object-oriented design, good programming habits, and ways of writing production-level code that you might not get in, say, Python or JavaScript. My last recommendation would be to learn C or C++ because they are lower-level programming languages. In C and C++, you would need to use things like pointers, you would need to learn about memory management, and there would be a lot of programming concepts that you may not have seen in languages like Java, Python, or JavaScript.

. . .

Again, these are my thoughts and recommendations. There are a lot of other paradigms out there. The ones I have mentioned in this article are the main ones people use. You can do more research before deciding on the ones to learn. You do not have to learn all of them at once. Programming is not going anywhere. You have a lot of time to stretch yourself as a developer.

3 Lies Software Developers Put On Their Resume

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.

Should You Learn TypeScript?

I have been putting writing this article off for a while now, but I thought it would be nice to share my thoughts on TypeScript as something that you might want to add onto your belt. TypeScript is a fairly new programming language. Since 2012, the language has become massively popular to the point of taking over front-end development, especially in large applications. Simply put, it is an enhanced version of JavaScript.

The relationship between TypeScript and JavaScript is similar to that of C and C++. The nice thing about TypeScript is that it is interchangeable with JavaScript. Any TypeScript code can be transpiled and translated into native JavaScript. You can therefore use the JavaScript that you already know inside of TypeScript. Most developers are adopting the use of TypeScript because you can use all its features, then translate into a native JavaScript file when you need to run it. Doing this may seem redundant at first because you can do a lot with plain old JavaScript, but TypeScript has better features.

TypeScript shines when it comes to large scale projects and enterprise-level applications. The use of TS should be judicial though because it would be a little bit of an overkill to use it for small side projects or an application where you merely have one or two JS files. I think one should reserve its use when you get to a point where you have a lot of structure involved in your program.

If you know JavaScript, you pretty much already know TypeScript, anything you can write in native JavaScript, you can write in TypeScript almost line for line. The core features it adds is the ability to add static typing to JavaScript. This feature does not change the fact that JavaScript is a dynamically typed language, nor does it change anything during runtime. It just means that when you are writing TypeScript code, you have type enforcement and you can choose if you want to declare the type of variables, method, parameters, return types, whatever it may be. The reason static typing is so important is that it comes with so many different advantages.

When you have static typing, and you have type reinforcement, the first thing that is a big deal is that catching errors becomes a lot easier. In dynamically typed languages like Python or JavaScript, almost all your errors are happening at runtime. That raises a lot of issues because you have to figure out what the problem is at runtime, which is more complicated than before, at compile time. There are also chances that you may miss errors because they just have not run yet. Take Python as an example, you can write some random code that makes no sense, but it will still run. Unless you hit that line of error-prone code, you may never know that that error exists, which is the same as in JavaScript.

When you have TypeScript, about 90% of the errors that you are commonly getting in a dynamically typed language, will be eliminated. How? In TS, the errors will be visible to you before you can even execute the program. You are going to have to fix the errors even before running your code. Without TS, you are going to have to debug your code at runtime that will require the use of a debugger which you might not have access to. This becomes hard for the most part when you are dealing with a large scale software, that is going out to millions of people. You want to make sure that you are catching all those bugs, especially any detrimental ones, and that you are getting them in your IDE before you go to the software. The idea is to give your IDE more information about your code so that it can do more work for you. Think about it this way. If you can have your IDE carry a lot of the weight, you will be saving yourself time and probably a bit of money too, especially if you are paying employers to code.

TypeScript comes with a bunch of other great features too, but the one I wanted to dial in on here is “typing”. Some people might think that it is going to be hard because you have to declare the types. It is not very difficult. The thing to take home here is that using this technology is entirely optional. If you are in a situation where it does not make sense to use it, you do not have to. In my opinion, TypeScript is a great language. It is an easy language to pick up specifically if you already know JavaScript. It just makes things way more powerful.

I have seen people online saying that it takes a little bit longer to write because you have to put the types. It is true, but I think that that is a marginal difference. I believe the types are just way more beneficial than they are harmful, and I would encourage all of you to look into TypeScript. Do not be intimidated by it. If the doubt comes along, just remember that TypeScript is just JavaScript on steroids. It is a great language to add to your resume because it shows that you are keeping up with trends. If you are already familiar with JavaScript, why not?

The Beginner’s Guide to Web Development: Starting Out Right!

Are you stuck wondering where to start? It is hard to find the right advice without suffering from information overload.
In this article, I have laid out all the basics you will need to learn web development. With this, you will have an understanding of the basics of web development and what skills you need. I will take you through the basics step by step. I recommend learning the basics of both the front end and back end before specializing.

. . .

Do You Have an Understanding of the Subject?

Before getting your feet wet, you will need to understand some general concepts like how websites work, the difference between the front end and back end, and the use of a code editor.

If you strip a site down to its core, you will notice that it comprises of a bunch of files stored on a computer called a server with an internet connection. You can then load that website through a browser, which is referred to as the client in this situation. So every time you are on the internet, you, the client, are loading data from the server as well as submitting data back to the server. This back-and-forth between the client and the server is the basis of the internet.

Web developer roles typically fall into front-end, back-end, and full-stack. These terms describe what part of a client-server relationship will be your specialty. Front end means that you work mainly with the client side. The back end is a part of the website that handles a lot of the logic and functionality that are necessary for the website/web app to work. Both front-end and back-end web development serve separate but critical functions.

When you build a website, one of the tools that you will use is your code editor or IDE ( integrated development environment ). This tool allows you to write the markup and code that will make up the website. There are quite a few good options out there, but currently, the most popular editor is VS Code.

. . .

Basic Front End

HTML, CSS, and JavaScript files are what make up the front end. The browser loads these files on the client side. HTML (hypertext markup language ) is the foundation of all websites. When you look at a website, the HTML file contains all the content on the page, and it uses tags to denote different types of content. For example, you can use text to create headline titles, paragraphs, bulleted lists, images etc.

HTML tags by themselves do have some styles attached but are pretty basic. CSS (cascading style sheets) lets you manipulate that HTML content so it looks more appealing to the viewer. You can add colors, custom fonts, and lay the elements of your website as you wish. People sometimes tend to gloss over CSS so they can move on to things like JavaScript, but it is good to note that there is much more depth to CSS than what meets the eye.

JavaScript is a programming language designed to run in the browser. Using JavaScript, you can make your website more interactive. For example, you can build a pop-up that shows the menu links when a user clicks it.

. . .

Tools to Get Familiar With After the Basics

Now that you know that HTML, CSS, and JavaScript are the basic building blocks of front-end web development, there are a few other tools that you will want to learn before going forward.

Package managers are online collections of mostly open source software. Each piece of software — usually referred to as a package — is available for installation and use in your projects. Think of them as plug-ins. Instead of writing everything from scratch, you can use helpful utilities that other people have already written. The most popular package manager is called NPM (node package manager). You can also use another manager called yarn. Both are good options, but as a beginner, it is probably best to start with NPM.

In addition to package managers, you will need to become familiar with module bundlers and build tools for they are another essential part of the front-end workflow for running tasks and processing files. You can use them to compile your SASS files to CSS, transpile your ES6 JavaScript files down to ES5 for better browser support, run a local web server, and many other helpful tasks. The most popular tools that you are going to come across a lot are gulp, Webpack, and parcel. You will have to choose the one best suited for your project.

The next thing to learn about in this stage is version control. Version control keeps track of every code change that you make in your project files. You can even revert to a previous change in case you make a mistake. The most popular version control system is an open source system called Git. With Git, you can store all your files and their change history in collections called repositories. You may also have heard of GitHub, which is an online hosting company owned by Microsoft, where you can store all your Git repositories.

. . .

Going a Little Deeper

At this point, you have a choice to either delve into additional front-end skills or learn about back-end web development. If you choose to go deeper into front-end, there are some more intermediate skills that you will want under your belt. I recommend that you look at SASS, responsive design, and a JavaScript framework. SASS is an extension of CSS that makes writing styles more intuitive and modular. With SASS, you can split up your CSS into multiple files for better organization, create variables to store colors and fonts, and use mixins and placeholders for reuse. Even if you utilize just some of the basic features like nesting, you’ll be able to write your styles quicker and with fewer headaches.

Responsive design ensures that your styles will look good on all devices. The core practices of responsive design include using flexible sizing for elements as well as utilizing the media queries to target styles for specific devices and widths. Building your website with responsive CSS is a must these days since mobile traffic is outpacing desktop traffic.

After getting the basics of vanilla JavaScript down, you may want to learn one of the JavaScript frameworks — especially if you are looking to be a full-stack JavaScript developer. Frameworks come with prebuilt structures and components that allow you to build apps quicker than if you started from scratch. Currently, you have three main choices: React, Angular, and Vue. React, which is technically a library, is the most popular framework right now. The truth is, there is no best framework for everything. There’s rarely a single choice that is 100% the best choice for every person in every situation. The framework you chose will depend on either your job or your comfort level.

Don’t worry too much about which framework to choose. It’s more important that you learn and understand the concepts behind them. Once you get a handle on one framework, it will be much easier to learn other ones after that.

. . .

Back End

Three main components make up the back end or server side of web development. The server, a server-side programming language, and a database. As mentioned at the very beginning, the server is a computer where all website files, the database, and other components are stored. Traditional servers run on operating systems, such as Linux or Windows, and are centralized because everything is stored all together on the server. These days, there are serverless architectures, which are a more decentralized type of setup. This type of application puts up those components and leverages third-party vendors to handle each of them. Despite the name, though, you still do need a webserver to at least store your website files. Some examples of serverless providers are AWS and Netlify.

Serverless setups are popular because they are fast, cheap, and you don’t need to worry about server maintenance. They’re great for simple static websites that don’t require a traditional server-side language. However, for very complex applications, the long-established server setup might be a better option on the server.

To write the functions and logic for your application, you need a programming language. The server will compile your code and convey the result back to the client. Popular programming languages for the web include PHP, Python, Ruby, C#, and Java. There’s also a form of service-side JavaScript, Node.js, which is a runtime environment that can run JavaScript code on the server.

Finally, you’ll need to learn about databases. Databases, as the name implies, are where you store information on your server for your website. Most databases use a language called SQL, which stands for Structured Query Language. Data resides in tables within the database, sort of like complex Excel documents on which one can write queries in SQL to create, read, update, and delete data. The database is run on the server using servers like Microsoft SQL Server on Windows servers and MYSQL for Linux.

There are also no-SQL databases that store the data in JSON files as opposed to the traditional tables. One type of no-SQL database is MongoDB, which often goes hand in hand with React, Angular, and Vue applications.

. . .


As a beginner, I would recommend you start your journey into web development following these steps. From here, you’ll learn different stacks should you want to go deeper down the rabbit hole. Happy coding!

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

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

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.