You may have tried every trick you know but still feel lost. But have you tried creating a visual representation of the problem so you can see how the code actually works?

I’m talking about using a flowchart.

In this article, you’ll learn how flowcharts work along with some common symbols and labels you can use in your flowcharts. We’ll also discuss some popular diagramming tools you can use to create flowcharts more easily. Finally, we’ll walk through how to actually build a flowchart so you can start using them in your projects.

Table of Contents

• What is a Flowchart?

• A Flowchart’s Symbology, the Limitations of Symbols, and Solutions

• Common Symbols and Labels Used in Flowcharts

• How to Add Shapes to Your Flowchart: Generalization vs Refinement

• Popular Diagramming Tools for Creating Flowcharts

• How to Build a Flowchart – Methodology and Example

• Conclusion

What is a Flowchart?

Simply put, a flowchart is a diagrammatic representation of an algorithm. It’s called a flowchart because it not only represents the steps but also depicts the direction the “job” flows as tasks are transferred to the next entity.

In many cases, a flowchart is considered part of a larger family of diagrams, usually referred to as flow diagrams. And although both names are commonly used, we’ll stick to the use of flowcharts to represent algorithms for now.

Here’s an example of a flowchart:

You’ll notice that it uses certain different shapes and colors – we’ll discuss these further below.

How Common Are Flowcharts These Days?

“Aren’t they from the time of, like, Cobol?” you might ask. Well, yes they are – and from even before that. Flow diagrams were quite popular from their introduction in the 1920’s all the way to the 1970’s. But their use started to fall off soon after that.

So you might wonder: are developers actually using flowcharts – or any kind of diagram – nowadays? I did some quick research across different developer community chats. I found that while not all devs say they use flowcharts, many of them mentioned that they were important in helping them sketch a vizualization of the code or the system.

I also found that senior developers were less interested in the use of diagrams because they usually knew the algorithms or the codebase almost by heart. But newer developers who were exposed to a codebase for the first time, revisiting a forgotten algorithm, or those needing to share some code with others tended to use flowcharts more often.

Why Do Devs Use Flowcharts?

Here are some of the most common reasons developers use flowcharts these days:

• Focus: A visual resource to help you think about a problem.

• Planning: Map out your steps before diving in.

• Sharing standard processes: As a tool to facilitate the reading of standard processes.

• Communicating and teaching: Explaining your code to both technical and non-technical people.

• Documenting: Keep track of your work in a way that’s easy to follow.

• Analysing existing code: Break down your code and others’ to see what’s really going on.

Of course, there are other methods you could use to cope with the situations listed above. But there are advantages to using flowcharts over other methods that have to do with the way we process information in our brain.

Still, making flowcharts is an intellectual process that entails some risks, particularly when it comes to clarifying information. So we need the right tools and a methodology to work with them.

In the following sections, we will go through all those points in more detail:

• The semiotic of the flowchart – that is, the use of symbols to convey information. We’ll also discuss the role of the flowchart as an information tool, its limitations, and how to address them.

• The most common symbols, their meanings, and how to use them

• The intellectual processes of constructing flowcharts and their risks

• A methodology to help you reduce those risks

• The available tools to create flowcharts with a quick introduction to the one we will use for our examples

A Flowchart’s Symbology, the Limitations of Symbols, and Solutions

Earlier, I defined a flowchart as a diagram of sequences of steps, or workflow, of an algorithm. But we can also understand the flowchart as a “language”: when using a flowchart, we are translating the description of an algorithm from a verbal / textual language to a more symbolic one.

In other words, we can define a flowchart as a visualization of a streamlined workflow where we identify steps and relations by substituting meaningful symbols for verbal / textual descriptions.

How Symbols Work

What are the advantages of using a visualization based on symbols to understand an algorithm?

Physically, our brain has to make more of an effort to extract meaning from either text or numbers than it does from visual attributes and shapes. For example, after some learning and under the relevant context, it is easy to get the meaning of this street sign:

This sign may work better than writing a board explaining that drivers should be careful as there are kids crossing the road.

In our example, if you have to pause to read the explanatory board, by the time you learn what the message is it could be too late. But our brain makes a faster evaluation of the situation when presented with the sign after some training.

Also, visual attributes and shapes can not only refer to concrete, tangible objects, but also to concepts and actions. For example, if you have done arithmetics before, you’ll know the meaning of the following symbols:

When we use a symbol to convey meaning, whether concrete or intangible, we usually talk about semiosis. Semiosis is the process of producing and interpreting signs and symbols to convey meaning. It involves the interaction between a symbol, its meaning, and the person or machine interpreting it. This process is central to the communication, understanding, and creation of knowledge in both people and machines.

Symbolic communication takes advantage of our innate visual processing skills. This helps reduce the need for long-winded explanations because the observer has learned somehow what the sign means. Instead of “semiosis”, some people prefer the term abstraction to refer to the same process.

That it is what we do with flowcharts: abstracting meanings through symbols.

The value of semiotics in a visualization is substantial. Using meaningful symbols in a visualization such as a flowchart allows you and your audience to focus on patterns that written text, such as code or a script, can’t easily tell or describe.

And that is where the power of visualizations like flowcharts resides.

But flowchart symbols are not operators like you’d find in mathematics. Rather, they’re representations. In fact, they might represent something specific to the person who draws them.

Because of this, the symbols alone are often insufficient to fully convey abstract concepts. For example, the term "database” can represent many types of systems or technologies, and can have many different setups and uses. Also, as technology evolves, some symbols may lose their relevance.

To address this, clear textual explanations should accompany the shapes, ensuring the flowchart remains meaningful and avoids vagueness. You can also add styling and even images to strengthen the symbols’ meaning.

Common Symbols and Labels Used in Flowcharts

When creating a flowchart, you can use custom symbols, but it’s typically a good idea to stick to certain conventions. Conventions ensure better communication as well as consistency of messaging across different flowcharts.

The ANSI/ISO standards list more than 30 recognized flowchart shapes, though their usage isn’t strictly regulated. This allows vendors and developers to agree on best practices.

Since these symbols require textual and styling support anyway, some devs argue that you can reduce the number of shapes to a “necessary few” versatile symbols instead. I refer to these as "wildcards”. Wildcards can represent broader abstractions when paired with clear text and or styling. But don’t hesitate to use other standard symbols if you think that they bring more clarity to your flowchart.

For our example, we will focus on the most common shapes. Some of the most common and most versatile shapes are:

As you can see in the table above, we have the following shapes:

• Oval (a start or end point)

• Arrow (a connector that shows relationships between shapes)

• Parallelogram (an input or output)

• Rectangle (a process)

• Diamond (a decision)

Let’s go through each of these now and examine how they work and how to use them.

The Terminator (Oval) Shape

This is the oval shape, called the start/end shape. It marks the starting and ending points of the process/system. The oval indicates the beginning or end result of the workflow, and the potential outcomes of a path.

Many devs use the oval shape, along with the words “start” and “end/stop/finish” for clarity.

Some people prefer to use a single circle to represent the start and a double circle to represent the end of a flowchart:

I personally prefer the circle – but it’s up to you. Just make sure you pick one and stick with it for consistency.

The Arrow or Flowline Shape

Also called the link or the edge by vendors and practitioners, this shape represents the connection between two steps. Also depending on its shape, it might indicate if that flow is broken, failed, or if it is an alternate path or process, and more.

The most common representation is the arrow, which indicates the direction of the workflow between two steps. The arrow points in the direction of the next step in the process.

When working with flowcharts, I accompany arrow flowlines and any other flowline with concise descriptions about the next step, sometimes with information about variables and, when it makes sense, the current state.

The Process (Rectangle) Shape

You can represent a process using a rectangle in a flowchart. It’s also referred to as a box:

A box can represent a single step, like an expression (for example, x = y*x²), a entire block statement, like “loop through array and update values by multiplying by 2”, or an entire sub-process, like an existing function or even a module.

The process shape is a proper wildcard and it can morph into many things, so it’s important to add a label to it and using text or other resources like formatting to clarify its meaning.

The Decision (Diamond) Shape

The decision is represented by a diamond. It is an abstraction for a condition’s test, a YES/NO, or TRUE/FALSE question. It is the equivalent of an IF/ELSE statement in coding.

The text accompanying this shape is a question formulating a comparison between an entering value and a control value. The flowchart usually splits into different branches depending on the answer or consequences after you use the decision shape:

The result of the decision box determines the next step in the process workflow. It’s usually declared to only answer a simple question, but you can abstract the question so it looks similar to an IF/ELSE IF/ … /ELSE control statement in coding, with lines representing different decisions.

When one of the flows returns to the decision shape from where it left, we are talking about a loop:

The interpretation is like asking to test the condition again after going through some steps along a specific workflow branch, then checking if the answer has changed.

The Input/Output (Parallelogram) Shape

You can use the parallelogram shape as an abstraction for data that’s available for input or output or for resources used or generated. It indicates that some information is required at this point in the workflow.

The input/output shape is typically accompanied by the following text:

• Either “input” or “output”, so you know which is being represented. You can also write other similar words like “get” / “put”, “in” / “out”, and so on.

• An input or an output could be related to a variable that you are planning or you already have in your code. If that variable should have an expected type when either entering as input or output, I would also add the type.

• Its corresponding state, as long as it provides more clarity to the flowchart.

• Optionally, it would be also useful to mention the source of the input / output. Is it a dataset? A manual entry? A form? Will it be printed in the console?

Notice that the whole point of the use of this shape is to trace the entry or the exit of data into or out of the process. Therefore, this shape is valuable when you want to have at least an idea of data exchange.

Finally, a less common symbol, but one that I use often is…

The Preparation (Hexagon) Symbol

The preparation symbol is represented by an hexagon and it abstracts the setup for the following step. I usually use this shape to declare all the initial conditions when the workflow begins. I accompany this shape with a list of variables, their types, and even functions or initial event settings, like event listeners, together with their initial values.

How to Add Shapes to Your Flowchart: Generalization vs Refinement

Now that you understand the basics of the symbols, you may be wondering how to insert them into the diagram.

Especially for large diagrams, you’ll want to be very intentional about adding shapes. You’ll need to make careful decisions about placing and the number of shapes you’ll use, otherwise your flowchart could become unreadable.

You’ll need to make decisions about things like:

• where to place the shapes so it results in a tidy flowchart.

• which of those shapes are essential to the understanding of the workflow, and which are not.

Placing is perhaps the most difficult task of making a flowchart. If you are manually constructing your flowchart, unfortunately there’s not a simple formula that instructs you where to place the shapes in order to prevent overlapping. It’s up to you to visually resolve the placement and to decide when any overlap makes your diagram unreadable.

As you’ll see later, there are computationally-based solutions for the placing of shapes. But there is a simple rule that applies to all cases: the smaller the flowchart, the easier it is to place the shapes. So reducing the number of shapes and only including the key shapes is key to creating a clear flowchart.

Keep in mind that I’m not suggesting that you try to create the most minimalistic flowchart you can. Just that you try to make the simplest one that conveys enough information to help you understand the workflow.

How to Choose Which Shapes to Use

Deciding which shapes to use can turn into an iterative process of adding, moving, or removing text or symbols into or out of the flowchart.

There are two competing tendencies here: generalization and refinement.

For example, the next figure shows three different flowcharts that demonstrate how to use a coffee machine:

In the image above, you can see that the example on the left is the one with less explanations and fewer shapes, while the one on the right has more details.

In the same way, depending on your needs and the specific details you want to get out of the visualization, the flowchart can be more generalized or it can be more refined. In fact, it might acquire some elements of subjectivity, which usually rely on the amount of information and knowledge you have about the process before looking at the flowchart.

Generalization:

In the case of flowcharts, generalization, also known as lifting, is when you enclose several steps into a few words and / or symbols. There are two reasons to use a more generalized approach:

1. You and your audience are competent enough to complete the information not provided by the flowchart.

2. You and your audience don’t know much about that specific step.

In the second case, there are two situations you might be dealing with:

1. Even if you don’t know much about that part of the process, you can keep that step generalized because that step plays a small role in providing information that’s essential to you. Or,

2. The point is critical for you to understand the process, but you and your audience simply don’t know more.

It’s in the second situation when you have to try to “open the box”. And this is done through refinement.

Refinement:

Refinement consists of adding more steps and more words and symbols in order to add more detail to a procedure. It usually follows researching and studying.

When you’re refining your flowchart, this doesn’t necessarily mean that you know absolutely nothing about the procedure. What you’re looking for is something that allows you to point to specific details, and what comes before and what comes next.

But how much generalization is helpful? And how much refinement?

When your flowchart is too general, it results in a simpler visualization but it doesn’t contain much information. You might have to use more words or rely on inner knowledge in order to explain what the chart or a step means. The first flowchart in the previous image is the most generalized of all of them.

The risk of over-generalization is non-information.

The process of refinement involves the opposite risk, and is, in my view, more dangerous. If you don’t control the refinement process, you might end up with an absolute mess, like this:

The above diagram isn’t a flowchart, but the risk is the same. The risk of excessive refinement is noise.

There are several rules and mechanisms that help you prevent reaching an unnecessary level of either refinement or abstraction. This is what we are going to learn in the next sections. But first, let’s take a quick look at the available tools you can use to make diagrams and flowcharts.

Popular Diagramming Tools for Creating Flowcharts

Now that you know the shapes, what they are for, and have some idea about how to use them, you can start building a flowchart.

But before doing so, I’m going to make a short detour to talk about the tools you can use to build flowcharts.

Nowadays, the options are many. You can use online as well as offline resources. Some are specialized for building diagrams, while others are more general. Some you can access for free, and others are more for enterprise operations and come with high fees.

Below, you’ll find a quick table categorizing some of the dedicated tools I have used in the past or that I have been investigating recently.

No-code or low code tools:

The large majority of the existing specialized diagramming tools are designed to help people without coding skills.

When using these types of tools, you have to manually construct the diagram by dragging-and-dropping shapes into an (online) editor: you select the shape and move it around until you find your preferred place for it on the screen. There are functionalities to draw the flowlines (“connectors”) also by a dragging action, and you can always edit the shapes to add text or styling.

Script-based tools:

But there are also some less well-known tools that have been around for a while that are rising in popularity now: the script-based options. With these kinds of tools, you describe the shapes and relationships by scripting them according to the syntax of the tool.

These kinds of tools have the relative advantage that the diagram will be drawn for you on a rendering screen or image. An algorithm will try to find the best place for your shapes on the screen without you having to place them manually.

AI tools:

Then there are the AI tools. Many of those tools are based on the scripting tools. Some of them work as follows:

1. the AI interprets either a descriptive prompt or the code itself

2. Then it translates the prompt into a script using a scriptable diagramming tool

3. The diagram renders according to the AI-generated code.

I’ve found that these AI tools are still not quite up to the task for more complex projects – but they can come handy if you just want a quick solution. One that I have used is codetoflow.io, but there are also (guess what…) ChatGPT plugins you can use.

Parsers

Even before the AI tools came around, there were the parsers. They map steps and relationships into shapes based on well-established syntax rules. Some of those parsers are turning to AI instead, as the AI generators are easier to program and require less maintenance. But sometimes the rule-based parsers can be more precise if the rules they are based on remain without changes.

Some of those tools read on binary code, which is a better proxy to follow the full workflow, something that popular AI tools are not capable of. Some IDEs, like Eclipse, allow you to add plugins to draw a flowchart of your code based on binaries. One example is drgarbagetools which works only for Java in Eclipse.

General-purpose tools:

Apart from those dedicated tools, you can always use others that are not specifically built for diagramming. I have used PowerPoint and Google Slides in the past, and there are other presentation applications that support the ANSI / ISO shapes’ catalogue. You can also use tools like Figma, Miro, or others. There are too many others to list here.

And finally, there is always pen a paper.

Our Example: Using Mermaid.js

For the example in this tutorial, I’ll be using one of the scripting tools called Mermaid. One reason for using a script-based tool is the ease with which you can update the flowchart along the way. And this will come in handy when we reach the generalization / refinement step.

Although other tools do not hinder the generalization/refinement process, the fact that you might find yourself redoing the whole flowchart manually could become quite time consuming. With a script-based tool, you can focus mostly on writing down the right relationships and shapes, while you let the program place the shapes for you.

Although I’m using Mermaid here, I’m not prescribing the use of any particular tool for the examples ahead. You can use the one that suits your needs and with which you feel the most comfortable. None of them are perfect, and they all have their own merits.

But if you want to learn more about Mermaid, I’ve written another tutorial for you that’ll give you a general overview of the tool and how to use it. I will also provide the syntax I am using to create the examples so you can try it yourself.

How to Build a Flowchart – Methodology and Example

When building a flowchart, you can follow these steps:

1. Define the scope of your flowchart

2. Find the start of the workflow

3. Trace the workflow to the end while using high levels of generalization for the steps

4. Select what should be refined and what can be left generalized

5. Iterate: Research. Refine. Test. Research. Refine or Generalize. Test. Research. Refine or Generalize…

6. Enhance

7. Extend (optional)

Step 1: Define the Scope of Your Flowchart

It’s important to be clear about what you want to do with your flowchart. Is it representing a full codebase or just a fragment of a script? Is it an algorithm that you want to study or is it an analysis of some existing code? Do you want a detailed explanation of a workflow or just look at the relationships?

Having a clear goal for your flowchart will help you guide its construction.

For this example, we are going to use an exercise from freeCodeCamp’s curriculum:

const character = "#";
const count = 8;
const rows = [];

for (let i = 0; i < count; i = i + 1) {
  rows.push(character.repeat(i + 1))
}

let result = ""

for (const row of rows) {
  result = result + row + "\n";
}

console.log(result);

Our purpose here is to understand this code, particularly to gain more insights about the for-loops.

Step 2: Find the Start of the Workflow

Once you have an idea of what you want to do with your flowchart, try to figure out the point from where the workflow begins. If it involves analyzing existing code, bear in mind that the start of the workflow might not be at the start of your target code. Just keep in mind that whatever triggers the whole procedure, that is an indication that the “start” is there.

The workflow usually starts with the setting of the initial declarations and values, so we could say that our flowchart could start like this for this example:

flowchart TD
start((start)) --> |variable declaration| varDeclaration{{"*character*(str) 
                                          *count*(num) 
                                          *rows*(list) 
                                          *result*(str)"}}
varDeclaration -.-> C["..."]

Step 3: Trace the Workflow to the End and Use High Levels of Generalization in Each Step

Once you’ve found the starting point, try to systematically trace the workflow steps from start to end. If there are procedures along the way, you can compact them into more generalized steps using no more than two shapes.

The most common shape for depicting a generalized step is the process shape. Candidates to keep generalized are functions, control statement blocks like loops or if-statements, modules, or even libraries. Labels of those steps should consist of general descriptions of the things that are happening or should happen at that step.

For our example, we can represent our workflow and in particular the for-loops at a general level like this:

flowchart TD
start((start)) --> |variable declaration| varDeclaration{{"*character*(str) 
                                          *count*(num) 
                                          *rows*(list) 
                                          *result*(str)"}}
varDeclaration -->|"Use *character* and *count* to fill the *rows* list through a for-loop with strings"| forloop01["for-loop01 with *count* as control: str.repeat(*character*) --> *rows*.push(str)"]
forloop01 --> |"Use the updated *rows* list to create a new *result* string"| forloop02["for-loop02 along *rows* items: 
*row* --> 
*result* = *result* + *row* + '\n'"]
forloop02 --print output to the console--> consolelog["console.log(*result*)"]
consolelog --> stop(((stop)))

Step 4: Determine What Requires Refinement and What to Leave Generalized

Stop for a while and review the schema you’ve created. Once you have a picture of the whole workflow, you’ll want to decide which sections might require more details.

In our case, we’ll refine the parts of the flowchart that deal with the two for-loops. Describing a for-loop is a typical example when learning to create flowcharts, but I also realized that the two for-loops in our exercise are not of the same type. So I thought it would be interesting to see if the flowchart can reveal how they compare.

Step 5: Time to Iterate (Research, Refine or Generalize. Test. Repeat.)

What you’ve prepared up to Step 4 is a general sketch of the workflow. Now it’s time to dig into the areas where more detail is required. During this process, sometimes you’ll find yourself coming back to an abstraction while looking for the clearest way forward with your flowchart.

There are two things that will help you in this process:

1. New Shapes: this is the time when you may want to use some other shapes. Start with the most common ones. Use other shapes as long as you can give them a clear role in your flowchart and they help you reduce a long explanation about what the replaced shape does.

2. Text: Extend the use of text to explain the workflow. It should be more specific to the algorithm itself.

This process ends when you are satisfied with the clarity and level of detail of your flowchart. But there are a best practices that allow you to control the process:

• Try to keep everything to a single page.

• Keep the number of shapes to around 20 per page.

• Avoid line-crossing more than 4 times. Use connectors when that happens. Having to explain 5 or more connections is likely not a good thing.

After any change, test your flowchart. Testing is the most subjective aspect of the methodology. There might not be a way to test the flowchart result against a tangible outcome.

If that makes you uncomfortable, try to think in the following way: the flowchart can be seen as a sort of ordered TODO list or brainstorm notes describing what the code or system should do in order to accomplish a desired task.

A flowchart is similar to this TODO list. But instead of writing all those steps as comments or even pseudo-code, you are using (conventional) symbols.

But barring the advances of AI or any use of flow-based programming, comments are not code, no matter how detailed they are.

So the decision of whether the flowchart is working or not is left to you and your audience. The most important question to resolve here is: is the information provided by the flowchart enough to understand what you need to understand about the process? Is it revealing something new? Is it helping you organize your ideas more clearly?

If you are still not satisfied, then repeat the process. But don’t feel like you have to stick to this process alone. You can always stop this effort and look for another way to explain your procedures if you find that a flowchart won’t work for you.

You could facilitate the refining and the clarity of the output by doing some additional research. Try to find how other people describe the procedure you are about to work on. Is there something about the language that you should keep in mind? Whenever possible, don’t start from scratch.

Also, try to be faithful as much as possible to the actual way in which the procedure should be coded, especially if you are refining. But don’t forget that it’s a representation. Feel free to work on a draft when not enough information is available.

Let’s go back to our example. I did some quick research to find out how others might interpret a for-loop in a flowchart. I found this reference useful to guide my own description:

This approach seems to be fairly standard and I will try to include some of those steps in my flowchart. I also found that according to JavaScript documentation, the kind of for-loop we are about to represent repeats until a specified condition evaluates to false, just like in the flowchart above.

Let’s start by working on the first for-loop only:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start First Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`input: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                            `"/] 
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 -.NO: something happens..-> stop(((stop)))
    forLoop01 --> |YES| inputI[/"`input: *i*`"/]
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]
    updateI --> |evaluate condition| forLoop01

Perfect.

Let’s now focus on the second for-loop. It turns out that it’s syntactically different from the previous one. And in fact, there are different kinds of loops in programming. The one we refined earlier is usually known as the “traditional” one, or better a numeric range type for-loop. The second one is an iterator type for-loop.

An iterator is a functionality that moves incrementally along a group of values or items. That functionality can have subprocesses to initialize the iterator – one to get the current value the iterator is pointing to, as well as a subprocess to go to the next one.

Also, remember that a for-loop stops repeating a workflow branch as soon as the condition evaluates to false.

Let’s try to reflect all this knowledge when refining the second for-loop. I will generalize the first for-loop for the sake of clarity:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based Loop**: entering initial values of *i* and *count*| forLoop01["Range-Based For-Loop"]
    forLoop01 -- enter Iterator-Based For-Loop --> inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]
    something --> stop(((stop)))
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]
    updateR --> forLoop02
    forLoop02 --> |NO: we exhausted all the items| something

Now we have a clear flowchart for each of the for-loops! We had to first understand what the loops were about, and then had to find a way to represent them. We used refinement and generalization to expand / contract the information rendered by the flowchart.

At the end, we just have to accept that these are still approximations — in order to get how those for-loops really work, we would have to go learn more about JavaScript, probably looking through the JavaScript source code, or even closer to the machine by analysing binaries. But I’m personally satisfied with the information I got from the analysis.

Now after making these changes, we can come back and merge both flowcharts (for each of the for-loops) to complete the full representation of the code:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based For-Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`INPUT: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                            `"/] 
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 --> |YES| inputI[/"`GET: *i*`"/]
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]
    updateI --> |evaluate condition| forLoop01
    forLoop01 -->|NO| outputRows[/"`OUTPUT: *rows* list of string items of size *count*`"/]
    outputRows --> |**Start Iterator-Based For-Loop**: entering initial values of *rows* and *result*| inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]
    updateR --> forLoop02
    forLoop02 --> |NO: we exhausted all the items| outputResult[/"`OUTPUT: *result* (str)`"/]
    outputResult --> |"`display *result* on the console`"|displayResult["`console.log(*result*)
            fa:fa-display`"]
    displayResult --> stop(((stop)))

Step 6: Enhance the Flowchart

Sometimes, specially with large flowcharts, the repeated use of similar shapes requires additional enhancement to provide more clarity. Normally you won’t quite know what you need to enhance until you have the full picture of something more final.

One way to do this is by grouping sections of the workflow. For that, you can use styling, like coloring the shapes, to highlight similar or related steps. It can also be helpful to highlight elements in the workflow that are really playing a fundamental role in the analysis.

You can also create groups of sub-procedures by boxing them (that is, placing a box around related elements of the flowchart).

Let’s apply some enhancements to our final flowchart by boxing and coloring:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based For-Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`INPUT: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                     `"/]:::input 
    subgraph RANGE_BASED_LOOP
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 --> |YES| inputI[/"`GET: *i*`"/]:::get
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]:::input
    updateI --> |evaluate condition| forLoop01
    end
    forLoop01 -->|NO| outputRows[/"`OUTPUT: *rows* list of string items of size *count*`"/]:::output
    outputRows --> |**Start Iterator-Based For-Loop**: entering initial values of *rows* and *result*| inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]:::input
    subgraph ITERATOR_BASED_LOOP
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]:::get
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]:::input
    updateR --> forLoop02
    end
    forLoop02 ---> |NO: we exhausted all the items| outputResult[/"`OUTPUT: *result* (str)`"/]:::output
    outputResult --> |"`display *result* on the console`"|displayResult[/"`console.log(*result*)
            fa:fa-display`"/]
    displayResult -->|finish| stop(((stop)))

    style start fill:black, color:#fff
    style displayResult fill: #DFFF73
    style stop fill:grey, color:#fff, stroke: white
    classDef input fill:#F8D192
    classDef get fill:#F8D062
    classDef output fill:#ECF892

Step 7: Extend the Flowchart

This step is optional. If you have done what you can to keep the flowchart as clear as possible – but you are finding that it still needs more refinement – you may be dealing with a complex process.

In this case, it’s time to think about a separate flowchart to continue or extend the one you are working on. There are ways to indicate the connection between pages. You can also show a section of a flowchart as a generalization and show a more refined flowchart on a separate pages using references.

I won’t go into the details of how to do that here, as this article is long enough as it is. And in this case, I think we can keep our flowchart to just one page, so I won’t go further with creating new pages for it.

So we are done!

Conclusion

When making a flowchart, we are not looking to imitate our code. Rather, we’re looking to understand it. This means that the flowchart has to be clear.

And if you use your flowcharts correctly, along with the right tools, they can help you reveal patterns and hidden operations, as well as stay organized, reduce overwhelm, and ultimately make coding feel more manageable. This will ultimately improve your coding skills and your state of mind.

So give flowcharts a try — you might be surprised at how much they can help you out.

So in the spirit of Leap Day, let's practice some coding to understand various aspects of programming. We'll focus on the same program but from different perspectives.

Our example program will explore different ways you can code a program that determines whether a given year is a leap year. On other days, we code. But today, let’s decode what we do and get some extra knowledge out of that process.

Table of Contents

• Program Requirements & Prerequisites
• Logical Approaches to Solving the Problem
• My Naïve Approach
• Reassignments and a Single Return Statement
• Switching to Switch-Case from If-Else
• Logical Deduction & Subsets for Better Structure
• Logical Operators Combining All True Conditions
• Applying Nitro with the Ternary Operator
• Making it a Single Line Arrow Function
• Paradigm Shift: Declarative Programming
• Functions with Side Effects
• More About Functional Programming
• Side-Tracking: Short-Circuiting!
• Encapsulation and Declarative Programming
• Going Above & Beyond with Code Quality
• Validations: Beyond the Basic Specifications
• Testing it Out From the Outside
• End Note

Program Requirements & Prerequisites

Logical Approaches to Solving the Problem

My Naïve Approach

This is based on the pedagogical style of determining a leap year that I learned as a kid who knew how to divide numbers. If a year ( the number representing it) is divisible by 4, it is generally a leap year. But not always. When that year ends with two zeroes (meaning when the number is divisible by 100), it must also be divisible by 400 to be a leap year.

How to determine if a year is a leap year - as described above

As a beginner programmer, my thoughts flowed like you can see in the above flowchart. As a result, I converted that logic into my program like so:

function isLeapYear(year) {
  if (year % 4 == 0) {
      if (year % 100 == 0) {
          if (year % 400 == 0) {
              return true;
          } else {
              return false;
          }
      } else {
          return true;
      }
  } else {
   return false
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

This makes the program easily understandable. But with time, as I have moved farther in my programming journey, this type of code looks ugly because of so many nested conditional checks. It's not bad, but because of the nested levels, my brain has to work extra hard to get the logic from the code snapshot quickly.

Reassignments and a Single Return Statement

To avoid nested loops, many programmers follow the strategy of consecutive if conditions, avoiding the else conditions (like how Kyle Cook of Web Dev Simplified shows in this video with examples). It definitely improves readability.

Also, it lets us use only one return statement at the end while reassigning the returnable value. Let's not discuss it too much more when you can better see the code itself:

function isLeapYear(year) {
  let isLeap = false;
  if (year % 4 == 0) {
      isLeap = true;
  }
  if (year % 100 == 0) {
      isLeap = false;
  }
  if (year % 400 == 0) {
      isLeap = true;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

The above code looks shorter and quicker to interpret. But it does affect the efficiency of the code, as now you have to go through all of the if conditions in all cases.

In contrast, in our previous naïve approach, due to the if-else construct, if a year is not divisible by 4 (like the year 2023), it would just be checked against one if condition. It’s true, of course, that for small programs such as this one, you don’t have to be overly concerned with efficiency.

The pitfall in this approach, though, is that you need to be cautious to apply all the if conditions one after another — using ‘else if’ would create trouble, as that would skip some if condition checks if the previous if condition test passed.

Another important fact is that the order matters. Since you started with the more generic cases of years not being a leap year (that is, let isLeap = false;), you have to go from relatively generic to relatively more specific cases.

So if, out of your three condition checks, the check of divisibility by 4 comes at the end, it would make ‘isLeap’ true even for years that are divisible by 100 but not divisible by 400 (like years 1700, 1800, 1900, and so on).

The same logical error would occur if you interchange the order of divisibility checks involving 100 and 400.

One last point I must mention is that some beginner programmers may think that you can not use multiple return statements and you must return only once in a program (and that you can do reassignments until that point). But experienced programmers can only call that notion a beginners’ myth!

Switching to Switch-Case from If-Else

While the if-else structure is used to choose between two options, you can also use switch-case to choose one from multiple options. You can compare it to nested if-else blocks (as in the first approach) or a series of if blocks (as in the second approach).

The benefit of the switch-case structure is that it is more efficient because it can find the matching success criteria in one go.

Note that there is one quirky thing with switch-case. When using switch-case, once a case is matched, all subsequent cases will also execute unless you are using break statements. So, the following program will not be correct even if it looks very similar to our previous version of the code.

Incorrect code: to show problems with missing break statements

```js example-bad function isLeapYear(year) { let isLeap = false; switch (true) { case year % 4 == 0: isLeap = true; case year % 100 == 0: isLeap = false; case year % 400 == 0: isLeap = true; } return isLeap; }

If we must use a switch-case structure, we need to use break statements. We also need to go from specific cases first to generic cases next. While not all if-else logic can be converted into a switch-case logic, we can successfully convert the previous function like so:

```js
function isLeapYear(year) {
  let isLeap = false;
  switch (true) {
    case year % 400 == 0:
      isLeap = true;
      break;
    case year % 100 == 0:
      isLeap = false;
      break;
    case year % 4 == 0:
      isLeap = true;
      break;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Notice that in the above, we don't have a 'default' case. And this is because we have initialized the isLeap variable with false. Had we just declared the variable without initialization with a value, we could've written a default case which would assign the value false to isLeap.

Also, the above version of switch-case code is slightly longer because we wanted to use one return statement in the end and used assignments until then. But if we refactor it, a shorter and more organized code would be this:

function isLeapYear(year) {
  switch (true) {
    case (year % 400 === 0):
      return true;
    case (year % 100 === 0):
      return false;
    case (year % 4 === 0):
      return true;
    default:
      return false;
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Notice that since execution of a return statement in a function automatically ends the function call, the program does not read lines that follow that statement. So, in this example, we don't have to use the break statements necessarily.

Logical Deduction & Subsets for Better Structure

Switching back from switch-case to if-else logic, let's do some logical deduction. In our previous if-else logic, we went from generic cases to specific cases. What if we go in reverse order? We consider that a given year will be a leap year unless negated.

So, we start with the narrower cases of centenary years — for them, the rule is simple: to be negated, they need to be divisible by 100 but not by 400 (like years such as 1700, 1800, 1900).

In this process, since we've already accepted years like 2000 (or years divisible by 400) to be a leap year, we won’t test them for divisibility by 4 (because a number divisible by 400 would anyway be divisible by 4 as well).

In the next step, as we consider only the non-centenary years, we would simply negate the cases where the year is not divisible by 4 (years like 2023, 1996, and so on).

function isLeapYear(year) {
  let isLeap = true;
  if (year % 100 == 0 && year % 400 != 0) {
      isLeap = false;
  } else if (year % 4 != 0) {
      isLeap = false;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Here you see, we first consider the centenary years and then non-centenary years — so they are mutually exclusive — and that’s why we use ‘else-if’ instead of if in the second conditional check. And in that process, we gain some efficiency over consecutive if blocks.

As this approach is about breaking the possible routes of being a leap year (or for that matter, not being a leap year) into subsets of years, depending upon how we break the possible years into subsets, we can construct the program alternatively as shown below:

function isLeapYear(year) {
  let isLeap = false;
  if (year % 400 == 0) {
      isLeap = true;
  } else if (year % 100 != 0 && year % 4 == 0) {
      isLeap = true;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

So, in brief, our deduction from the leap year rule is that  years divisible by 400 (like 1600, 2000) are leap years, and out of all the other years they must be divisible by 4 but not divisible by 100 to be a leap year.

In taking this approach, we have combined conditions and that’s why we involved logical operators (&&, the logical AND operator). This has helped us reduce the length of the function. Instead of three conditional blocks, we are currently using two blocks — an if block and then an else (where we further check the condition, and thus we call it else-if rather than just else).

But now that we are just using almost a single ‘if-else’ construct and we are also delving into logical operators, let's unleash more power from the logical operators in the following approach.

Logical Operators Combining All True Conditions

This time let's just reorganize the logic from the previous approach (two subsets) to group all positive conditions together and then accept a year as a leap year. If that’s not met, then call it a non-leap year.

function isLeapYear(year) {
    if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
        return true;
    } else {
        return false;
    }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

This one looks good because it increases readability by organizing the positive conditions together. The only cost we incur here is that the condition in the if block is longer.

But with logical operators, it looks visually shorter and not complex (at least to programmers habituated to combining logical operators like this).

Dissecting further, since in the previous approach we said we could break the subsets in two different ways, we can have two corresponding two versions for this approach as well. The second one is the following:

function isLeapYear(year) {
  if ((year % 100 == 0 && year % 400 != 0) || year % 4 != 0) {
      return false;
  } else {
      return true;
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Applying Nitro with the Ternary Operator

As you progress in your programming-learning journey, at some point or other, you must have been elated to discover the possibility of writing ultra-short programs.

While logical operators help us do that, to activate the ‘Nitro’ mode, we must use a Ternary Operator — which basically makes our if-else blocks a single line.

function isLeapYear(year) {
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

By now, as a pro programmer, you must be pitying your rookie self. You think of those times when you used to declare and initialize a variable with a default value first and then reassign it with the value you wanted to return, and finally return the value held by that variable.

It has been a long time since you shunned that practice, and you now return what you need to return, and don’t consume unnecessary memory space for useless variables.

Making it a Single Line Arrow Function

Now that you have been boosted with Nitro, your programming technique is advancing like an arrow, on a mission to tear away the remnants of ES5 and boldly fly into the post-ES6 world. So you welcome arrow functions with open arms.

const isLeapYear = year => (year % 4 === 0 && (year % 100 !== 0 || year % 400 === 0));

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Previously, you skipped variables, and you skipped ‘if-else’ blocks. And now, you can even skip the return statement thanks to the arrow function having a single statement in its body. You also skip the parentheses around your argument as it is a single argument.

While singing the saga of shorter code, a point must be made that the shorter code is not necessarily the better code. It all depends on your users of the code (people who might read it and possibly collaborate/improve upon it).

If you are working with experienced programmers, this level of concision is fine. Just make sure you don’t exceed the line width beyond a certain number of spaces (80 characters recommended) so you don't trouble your coworkers with the need to handle horizontal scrollbars.

But if you are working with team members with varying levels of experience, or you are a teacher working with learners, then you must be conscious of the readability of your code for everyone.

Paradigm Shift: Declarative Programming

Anyway, we have discussed the logic of determining the leap year in the above examples. But let’s now dissect further to find more nuances of programming. And in that process let's move from imperative programming (as we have used so far) towards declarative programming (which is the end goal in this section).

Functions with Side Effects

Functions are said to have side effects when they modify non-local variables. In addition, a function that prints (logs) in the console is also considered a function with some side effects. That is because if a function does not have a side effect, a call to it can be replaced by its return value.

Functional Programming is a paradigm which dictates that our program should be like a pure function without side effects. A pure function means a function which always returns the same output given the same input. So, in its body, it depends on only the input parameter given from outside and no other global variable. Additionally, it should just return the output value without side effects or trying to modify anything outside its scope.

But consider the following variation of the program which does not specifically return any value representing the result. Instead, it logs the result as a statement (string) in the console. This is an example of a side effect.

function isLeapYear(year) {
  if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
      console.log("leap year.");
  } else {
      console.log("not leap year.");
  }
}

// Example usage:
let someValue = isLeapYear(2024); // Output: leap year.
console.log(someValue); // Output: undefined

Evidently, it does not follow the specification, as it needs to return a value of boolean type. A function can, of course, do both — printing and returning, like an alternative form of the above function.

function isLeapYear(year) {
  if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
      console.log("leap year.");
      return true;
  } else {
      console.log("not leap year.");
      return false;
  }
}

// Example usage:
let someValue = isLeapYear(2024); // Output: leap year.
console.log(someValue); // Output: true

But the mere fact that it is doing two things — returning a value and printing in the console —  is the problem. A function should be made to do one thing for proper reusability. The ‘isLeapYear’ function should just determine if a year is a leap year. If we need to print anything about it, let that onus of doing the side effects lie with some other logger function(s).

// pure function

function isLeapYear(year) {
    if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
        return true;
    } else {
        return false;
    }
}

// functions with side effect

function simpleLeapYearLogger(isLeap) {
    if (isLeap) {
        console.log("Yes, a leap year!");
    } else {
        console.log("Sorry, not a leap year.");
    }
}

function advancedLeapYearLogger(year, isLeap) {
    if (isLeap) {
        console.log(`The year ${year} is a leap year!`);
    } else {
        console.log(`The year ${year} is not a leap year!`);
    }
}

// Example usage:
let currYear = 2024;
let check2024 = isLeapYear(currYear); // No Output/Side Effect, just retuned value.
simpleLeapYearLogger(check2024); // Output: Yes, a leap year!
advancedLeapYearLogger(currYear, check2024); // Output: The year 2024 is a leap year!

As you can see above, the function ‘isLeapYear’ is more reusable — with two different use cases in two separate logger functions. Also, had there been any mistake in the logic for the ‘isLeapYear’ function, it would have been easier to fix without touching the logger functions’ code.

Similarly, if you need to display the string logged in the console differently, you could modify the respective logger function without touching the leap year’s logic function. Thus, a function doing just one thing that it was supposed to do increases the reusability and maintainability of that function.

More About Functional Programming

In the above section, you have already ventured into the space of functional programming. And now is the time to delve deeper.

If I search the term ‘Functional Programming’ in Wikipedia, the first line states

“functional programming is a programming paradigm where programs are constructed by applying and composing functions.”

The phrase ‘composing function’ means building complex functions from simple ones. In our example, the leap year function is quite simple already. But to showcase the mechanism of function composition, let's create it out of component functions.

// component function
function divisible(dividend, divisor) {
    return dividend % divisor == 0
}

// composed function
function isLeapYear(year) {
    let isLeap = false;
    divisible(year, 4) && (isLeap = true);
    divisible(year, 100) && (isLeap = false);
    divisible(year, 400) && (isLeap = true);
    return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Side-Tracking: Short-Circuiting!

Above, you are using a function to build another function — a component-based approach that you also follow in the React JavaScript-based front-end library.

But wait, before we go further into React, what is that ‘&&’ doing in those three lines in the 'isLeapYear' function when we are not using any if-else statements there?

Welcome to the short-circuit evaluation of logical operators. In that process, an expression stops being evaluated as soon as its outcome is determined. So if two sides contain a logical AND (&&) in between, if the first side is false, this makes the whole expression false – so it does not read (not execute) the second side.

But if the first side is evaluated to be true, it further reads (executes) the second side for evaluation. And in that process, it does that assignment on the right-hand side of && in our example.

Similarly, the process when logical OR (||) is involved is such that if the left-hand side is evaluated as true, the whole expression is true (it needs one condition evaluated as true for || for the whole expression to be true). Then, the second side is ignored. The second side is read or executed only when the first side is evaluated as false.

You can use this kind of evaluation logic as a replacement for the ‘if’ condition checks. For more examples of how it works in different scenarios, read the section ‘Short-Circuiting of Logical Operators (&& and ||)’ in my blog post where I have discussed some nuances of JavaScript Operators.

Encapsulation and Declarative Programming

Returning to REACT and components, the idea of building composing functions or components is rooted in the need for encapsulation. With encapsulation, you can hide the complex details, like in a capsule, and use it repeatedly without bothering much about its underlying complexity.

Essentially, you just proclaim (declare) what you need rather than straining yourself with the workload and headache of how you can make it happen step-by-step with ‘do-this’ and ‘do-that’ type statements (imperatives).

That, briefly, is declarative programming for you.

Going Above & Beyond with Code Quality

So far, we have covered the logical structures and the programming paradigms, but now, let’s look at the third aspect: code quality.

Validations: Beyond the Basic Specifications

The requirements that we laid out at first just considered valid inputs. What if the function is called with arguments that are not the ideal ones — like a non-number, or even if a number but a non-integer?

To address that, we can build validation logic. To build validation logic, you need to think about all the different ways in which the input value (the argument passed to your function) may not be workable for you.

If one of those non-workable ways does come along, you need to return something that makes more sense — you can not give a verdict like true or false in that case. You may return something more neutral (like undefined or null) to indicate that the function encountered an invalid entry.

function isLeapYear(year) {
  if (typeof year!="number" || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear("TwentyTwentyFour")); // Output: undefined
console.log(isLeapYear(2023.99)); // Output: undefined
console.log(isLeapYear(0)); // Output: undefined
console.log(isLeapYear(-1)); // Output: undefined
console.log(isLeapYear("2024")); // Output: undefined

But if you noticed carefully, in our leap year logic check, we have evaluated just ordinary equality (==) instead of strict equality (===). We can't reap the benefit of that for a string format entry for a year like "2024".

If our intention is to strictly accept a number, the kind of validation we wrote is fine, and it would then be even more proper to use ===.

But if, on the other hand, we want to accept values like "2024", we must enhance our validation logic like so:

function isLeapYear(year) {
  if (isNaN(Number(year)) || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear("TwentyTwentyFour")); // Output: undefined
console.log(isLeapYear(2023.99)); // Output: undefined
console.log(isLeapYear(0)); // Output: undefined
console.log(isLeapYear(-1)); // Output: undefined
console.log(isLeapYear("2024")); // Output: true

Testing it Out From the Outside

In the above two code blocks, we write our code and test it in the same place. But the code that goes into production will not have the opportunity to include such console logs that we have used extensively for demonstrating 'example usage' in the above code blocks.

This is where unit testing comes in. In unit testing, we first export the function for use in other places (files), then import that function in a test file. In that test file is where we run the test, build our cases, and finally run that test file to execute those tests.

I have used the Jest package to do this unit testing, and here is the code from my index file and test script file:

index.js

function isLeapYear(year) {
  if (isNaN(Number(year)) || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

module.exports = isLeapYear;

index.test.js

const isLeapYear = require('./index.js');

describe('Test isLeapYear', () => {
  it('should return true for leap year', () => {
    expect(isLeapYear(2020)).toBe(true);
  });
  it('should return false for non-leap year', () => {
    expect(isLeapYear(2023)).toBe(false);
  });
  it('should return undefined for invalid input', () => {
    expect(isLeapYear('TwentyTwentyFour')).toBe(undefined);
    expect(isLeapYear('2023.99')).toBe(undefined);
    expect(isLeapYear('0')).toBe(undefined);
    expect(isLeapYear('-1')).toBe(undefined);
  });
  it('should return true for a leap year in string format', () => {
    expect(isLeapYear("2024")).toBe(true);
  });
});

I installed Jest using the command npm i jest. Then, I added jest as a value for test in the scripts object inside my package.json file. Then, as I ran npm test, it passed all my test cases, like so:

testing output

If you want to tweak and try this unit testing code, you can use and fork this replit project.

End Note

We've reviewed many programming concepts in the above exercise. And one key takeaway is that a program can be written in multiple ways.

There are typically many correct solutions to a programming problem. So beginner programmers should, therefore, think of the logic part of it (the algorithm) more than the exact execution steps when starting to solve a problem.

And by the way, if you're wondering why we have leap years, then this is for you: the time Earth takes to complete one revolution around the sun is not exactly 365 days (or 365 x 24 hours) but approximately one-quarter of a day extra.

This process may remind you of the modulus operator, represented by the symbol %, which returns the remainder of a division operation. Here, the approximate time (in hours) taken for one revolution of earth is being divided by 24 hours (that is, a day). It gives a remainder of about 6 hours.

const approxTimeHrsRev = 8766;
const hrsPerDay = 24;
let completedDaysEachYear;

let remainderHrsPerYear = 8766 % hrsPerDay;
completedDaysEachYear = (approxTimeHrsRev - remainderHrsPerYear) / hrsPerDay;

console.log(`After ${completedDaysEachYear} complete days, there is still about ${remainderHrsPerYear} hours left out each year.`);
// Output: After 365 complete days, there is still about 6 hours left out each year.

To account for those missed hours, we must adjust our calendars once every four years when those left-out portions add up to make — again approximately — a day.

Finally, because it is not exactly 6 hours, and a tiny bit more than that, we have to adjust every 100 and 400 years further.

After explaining why you definitely should, I'll cover some of the benefits and challenges of being a software developer. I'll also discuss some key strategies for approaching learning to code to help you succeed.

By the end, you should have a more developed mental model of what it takes to learn programming and how you can start or continue your journey.

Table of Contents

• What is programming?

• Should you still learn to code [Yes]?

• Why you should consider coding as a career

• Potential challenges of a programming job

• Why do software engineers get paid so well?

• How to prepare for your coding journey

• Your ego is your enemy

• Take responsibility for your learning

• I am afraid to start programming. What should I do?

• Strategies and tips for learning to code

• Can you learn coding in a single night?

• Avoid tutorial hell

• How to understand complex topics by using the Feynman Technique

• Don't memorize the syntax

• Keep a To-Learn list

• Practical aspects of coding

• How to deal with overwhelming projects

• How to choose projects to build?

• Learn by building things from scratch

• Build something that already exists

• Beyond the basics

• Develop a love of learning

• Look at the bigger picture

• Embrace lifelong learning

• Get the PDF version of the book

Introduction to Programming

What is Programming?

Before we start with the advice, let's learn what computer programming is.

First of all, remember that a computer is not only a laptop or desktop. It's also your phone, tablet, and any other device that is capable of performing logical and arithmetic operations that we program into it.

This includes your car's navigation system, the ATM where you withdraw or deposit money, the systems that allow you to order food digitally, and so on.

Computer programming is the process of designing and building instructions (a "program") that the computer can execute.

As an example, we can take a calculator that performs arithmetic operations such as addition, subtraction, multiplication, and division.

Instead of doing all this with a pencil on paper – but instead, we have a calculator on our phones. And this calculator is a computer program that helps us find the result quickly.

Other programs that you may use every day include Facebook, WhatsApp, Instagram, YouTube, TikTok, and many others.

Writing a program is sort of like cooking a meal. You may have an idea for a delicious meal, but you need to buy the necessary ingredients beforehand.

Once you have what you need, you prepare that food, put it in the oven, and then wait while it cooks. After that, you serve the food at the table and eat it.

Things work similarly with programming: first, you have an idea and the knowledge to turn that idea into a program (or maybe you learn while you're building the program – just like how you can watch someone cooking food on YouTube and learn how to make that recipe).

Then, you start to put the ingredients of the program into place, piece by piece, until the entire program is ready to be served to users.

Unlike cooking, where dishes are consumed, programs remain intact and reusable even after being used.

This unique aspect means that a single program can serve multiple users simultaneously and over time.

There are costs associated with creating and maintaining software, but once developed, a program like a website can be accessed by numerous people at the same time without diminishing in availability or quality.

So to summarize, programming is the process of turning an idea into a computer program that other people can use. And this is something you can learn how to do yourself.

In the ever-evolving landscape of software engineering, many people are wondering about the impact AI will have.

Should you still learn how to code? (Short answer: yes.) Let's delve into this concern, especially for anyone who's skeptical about the future demand for coding skills.

Should You Still Learn to Code? [Answer: Yes]

We use software all the time – to chat with others, stay informed about the latest news, and even for our alarm clocks that help us wake up on time.

Even the browser or the PDF reader that you use to read documents are pieces of software. These words were even typed in a software program.

Programming is something that's ever-evolving, and many things that we're currently doing manually may get automated in the future.

But software is deeply embedded in our daily lives, powering tools and applications across various professions and personal activities.

The more we integrate into the digital world, the more central software becomes. It's reshaping our work, learning, and social interactions, with its importance only set to increase.

The Future of Building Software

Imagine a world where building software was as simple as having a conversation with a highly advanced AI, like a future ChatGPT. You describe your needs, and the AI creates the entire software for you – no coding required.

So you may wonder: why should I learn coding when ChatGPT can code an entire app for me in seconds? Well, here's something I want you to understand: AI is not here to replace us, but to help us become more productive.

Sure, AI can help you save time and energy by performing certain basic, repetitive tasks for you. But grasping the basics of software development remains crucial, especially for the more complex problems that require your creative, experience-based solutions.

You need to be able to harness AI's power while continuing to learn and adapt. This will help make sure that we're steering the course in our rapidly evolving digital landscape.

As you can probably tell, I want to emphasize the irreplaceable role of software engineers and coders, even in an AI-dominated future. Here are a few reasons why:

1. Understanding Over Automation: Coding isn't just about executing tasks – it's about grasping complex logic and structures. Our human ability to analyze and solve intricate problems goes beyond AI's automation.

2. Maintenance and Flexibility: Deep coding knowledge provides insights vital for software maintenance and adaptation. This knowledge is invaluable when AI-generated programs encounter issues.

3. Safety and Reliability: Similar to understanding basic car mechanics for safety, knowing coding basics is essential for addressing software malfunctions.

4. The Creative Element: AI lacks human creativity and innovation, which is crucial for envisioning and realizing novel software solutions.

The rise of AI in coding doesn't signal the end for human coders. Rather, I believe it just signals a collaborative future. AI's automation of mundane tasks gives human coders more space for creativity and innovation in software development.

Learning to code transcends mere programming. It's about understanding how various technologies work, honing problem-solving skills, and nurturing creativity. These skills remain invaluable, even as AI reshapes the landscape.

So I encourage you to embrace coding as it opens doors to a future where human intelligence and AI collaboratively push the boundaries of innovation.

Why You Should Consider Coding as a Career

Maybe when you were a kid (or now as an adult) you liked a computer game so much that you played it all the time.

And maybe you had the idea that someday you could develop a game like it.

I know people who started programming precisely for this reason: to be able to develop different computer games.

So, because of the pleasure you may have experienced, you may have decided to become a programmer yourself.

Over time, your reasons may change – and this certainly doesn't mean that everyone gets into coding only because of game development.

After all, there are many reasons why you might consider programming as an option for your career. Let's discuss some of these reasons now (and indeed there are many more).

You have the opportunity to develop something for fun

I mentioned the case of game development, but you don't have to start programming by building games.

Maybe you are an accountant, or you have a shop and want to register your goods through a program that you develop yourself...and so on.

Here are some practical projects that might inspire someone to learn to code:

• A custom note-taking application tailored to your specific needs.

• A personalized inventory management system for your shop.

• An app for organizing and tracking your daily tasks and goals.

• A scheduler for managing your college or university timetable.

• A problem-solving assistant for tackling challenging tasks.

• A daily weather update tool that sends forecasts to your email.

• A health app that suggests potential illnesses based on symptoms.

• A focus enhancer that limits access to social media during work hours.

There are many other programs that you could develop. In short, you can start programming because you like to solve the problems you face in your daily life.

And once you learn to code and can build these programs, then you can share them with your friends and family (and beyond).

You can solve problems for people all over the world

Here's something that might make you happy: having the opportunity to help someone else (or a lot of people). I am sure that when you have been able to help a family member or a colleague, you've felt happy and satisfied.

Now, imagine how good you'd feel if you had the opportunity to solve a problem that people are facing all over the world.

For example, you may have an idea to start a Facebook group for residents of your neighborhood asking each other for household tools that you may need.

Or maybe you want to propose that everyone pitch in on maintaining the common spaces in your neighborhood.

You could also use this group to bring up problems as well as solutions that you aim to realize.

If you know how to code, you can create your own tool and share it with your neighbors. You can make your platform tailored to the specific needs of your neighborhood.

And if it works in your community, you can then share it with people from other neighborhoods.

You can take things a step further and work on projects that help people working in different fields.

So, for example, in addition to helping residents of your neighborhood, you can help farmers be better informed about the weather conditions by building a weather reporting app.

Or you can come up with a recommendation system that helps them determin how to work the land and what crops to plant when.

Or maybe you want to help a barber who wants to visualize the hair styles of his clients before cutting their hair. Or you could even build programs to help a private medical clinic better manage their patients' records.

As I hope you're beginning to see, the possibilities are pretty much endless.

You can work on interesting challenges

A major advantage of programming is that you can use the knowledge you acquired to solve all different kinds of problems.

Often you may start to read a book, or watch a movie that you may not like, and you have the opportunity to leave that book or that movie unfinished and start another one.

The same thing applies to programming projects. You may not be very motivated to work on a side project, so usually you have the opportunity to switch and deal with another project.

You can do that even at work from time to time where you ask can ask your manager to assign you to a different project.

You can also learn during work hours

Many companies offer programmers space and the opportunity to learn during work hours when there is no work that needs to be done at the moment.

In fact, some companies cover the expenses for training, books, and various courses that qualify and prepare workers.

And at some companies, when you complete a certification, you'll get a reward of some type, whether financial or otherwise.

Skilled, prepared, and trained programmers are valuable resources for a company. In addition to being able to work on more complex projects, they also often have the opportunity to get better clients and offers. The company can also invest in these highly-skilled devs by promoting them.

You can work from home

The good thing about programming is that you can work from home (or anywhere) and be employed remotely. This means you don't have to physically move somewhere to engage in more interesting work or get a better offer.

During the pandemic, many companies offered the opportunity to work from home, and many companies will continue to offer this opportunity even after the pandemic.

This is a great relief for many people, as it saves them from the need to travel every day to the office, pay additional rent, live away from family members, and so on.

You can have a flexible schedule

Different people have different obligations outside of work, including family needs, medical appointments, or various commitments at certain times, which cannot be postponed for later.

So for many, having a flexible schedule, or even getting to leave work at certain times, is necessary. And many developers are able to have this flexiblity in their work schedules.

You can collaborate with and learn from intelligent people

If you're on a team, there will likely be people who have studied many different fields/areas of tech than you have. They'll also likely have rich experiences with various previous projects. This will present to you many opportunities for learning and collaborating with these team members. So take advantage of those opportunities when you can.

You may have team members in Germany, Singapore, or Brazil, or anywhere else in the world. And by working on the same project, you have the opportunity to benefit from their knowledge, their approach to problems, and their creative solutions.

The salary is often very good

Programmers often enjoy higher salaries compared to many other professions.

This isn't just a slight difference – in most countries, if not all, the average salary for programmers significantly exceeds the national average.

This trend reflects the high demand and value placed on programming skills in the global job market.

In addition to the opportunity for good compensation, there is also the opportunity to get raises or other financial incentives/benefits depending on your work.

Also, many tech companies implement bonus schemes for their employees. These bonuses are given for achieving business goals, exceptional performance, or extremely dedicated work.

They can be awarded to individuals or teams, depending on the company's policies.

Thus, based on individual or team achievements, securing big clients, or completing successful projects, employees may receive additional compensation in the form of bonuses.

This can be a significant motivational factor for many in the programming field.

You can often take paid leave

As much as we may be motivated to work and enthusiastic about turning our ideas into code and thus reality, we are human and need rest and relaxation. So make sure to take the time to disconnect from daily work.

In other words, rest is beneficial for everyone, especially for programmers, who may be stressed and engaged all day with work and pressure.

In general, developers get fairly generous paid leave, allowing them to take vacations throughout the year. There are also companies that offer the opportunity for long periods of leave, as long as it does not harm the project and the work of the entire team.

Taking vacations isn't always easy for people of other professions, who often have much less flexibility or less generous paid time off.

Those are just some of the reasons programming may be a good fit career-wise for you.

But to be fair, let's also consider some of the downsides to see if any of them are dealbreakers for you.

Potential Challenges of a Programming Job

Perhaps you did not expect this issue to be addressed in this book which is aimed to inspire you to consider becoming a developer.

But I thought it was important to share potential downsides as well to help you make an informed decision.

Here, I'll discuss only some of the disadvantages that come from a career in programming. You might not experience all these specifically, and this may not reduce the chances of them happening to you. But if you're aware of them, perhaps you can avoid them more easily.

Programming can be stressful

Perhaps you have had the chance to speak with other developers and they told you that coding is stressful. Well, this can be the result of many situations.

For example, if you're fixated on solving a particular problem at work, you may hesitate to get up from your chair and walk around, which helps relieve stress. But you don't want to stop until you solve the problem. This can contribute to your stress.

So what can you do to help relieve stress, or release the emotional burden of an issue? Well first of all, it's good to do physical movement, including getting up from your chair, taking a little walk around the office (or your house, or wherever you're working), going out in the fresh air, and changing your environment for a few moments.

Remember: stress can be harmful both in keeping you from thinking clearly (which would help you more easily find a solution to the problem), and in consuming all your energy. All this can lead to a deterioration of your mental and emotional state.

You need to learn continuously

Learning is the only way to advancement. So if you always feel pressure to learn new things either directly or indirectly, this is a great opportunity you can use to advance your career.

New tech tools, programming languages, and platforms come out continuously. And you may be busy dealing with commitments outside of work that may also take your time and energy.

It doesn't matter how much experience you have so far in programming. The only thing that remains unchanged is the need to learn continuously. Learning new things helps you keep up with the job market, know what's required by your clients, and develop your own products.

But perhaps you don't enjoy the pressure to learn new skills all the time.

You might be someone who, as soon as you get into a job, want to feel comfortable and secure. This is ok, but it may result in having lower ambitions and fewer or less exciting goals.

So if you're someone who doesn't always want to be learning new skills, this could be a negative side of tech and an unsuitable burden. But I hope that you, instead of seeing this as a negative side or disadvantage of programming, will embrace it as a worthy challenge.

You have a lot of responsibility

Your work as a developer may be used by many people. It may have a positive impact on them and make their lives easier.

But with this great power comes great responsibility. You may unintentionally cause negative consequences that may affect many people if you fail to catch an error in a program, for example.

It is not the same as making a mistake when designing a wristwatch, for example, that comes out with some problem like a scratched face or cracked leather band. If you release an application used by tens of thousands (or more!) of people – say, a medical device – that contains a mistake, it may risk people's lives.

This may seem a bit exaggerated, but it is worth remembering that many programs on hospital computers used by doctors and medical staff may have errors or bugs in them. As a result, this mistake could cause a doctor to make an incorrect diagnosis diagnosis and the wrong therapy which can be very harmful, even fatal to the patient.

So it's important to take your responsibilities as a developer seriously and complete your work carefully and thoughtfully.

You may need to work after hours

This is not unique only to programmers, since people who work in other jobs often need to work after work hours. But this can be hard for devs, especially those with additional responsibilities in their lives.

As a developer, you may need to stay late at work for many reasons, such as:

• You have a short deadline for finishing a new task, new feature, or just for fully completing the project for your client.

• Some service that you have programmed has failed which needs an immediate fix so the client's service or tool doesn't go down. And you may need to be at your computer to fix it even though it might be after work hours, during a weekend, or during an official holiday.

• A security issue has arisen in a programming library that you use and you need to resolve it so that your clients and users are not affected by this problem. Mistakes are inevitable, especially in programming, but errors vary, and some can be very harmful, while some may not even be noticed.

Just make sure that you set boundaries and expectations with your team, your clients, and your manager so you don't end up working overtime all the time.

You have to sit for long periods in front of the computer

Developers often sit for long periods in a chair and often don't do enough physical activity. This can cause you to start experiencing back or joint pain, numbness, weight gain, or other potentially harmful health issues.

Or as you concentrate really hard on debugging a problem, you may have times when you even forget to close your eyes while working at your computer. This, of course, is not healthy, as it can damage your eyes.

Also, sitting such a short physical distance from your computer, which is usually less than a meter away, you may fixate your eyes in the same position for a long time, which can be harmful to your eyes as well.

To avoid these things, you can workout at a gym, do light exercises at home by following instructions on YouTube, and by generally moving your body more often like by getting up from your chair, walking around the office, eating healthy foods, stretching, and so on.

Your body mass may increase

Many programmers feel stress during work. As a result, they eat more than they need to reduce stress – and they may not even notice that they are overeating due to stress.

And again, since you may be spending long periods sitting and eating more than you need, you may start gaining some weight and losing muscle.

To avoid unwanted weight gain, try to be conscious of what you eat and how much. You can try to eat less unhealthy fat and reduce your sugar intake. You can also do some physical exercises, and make sure to eat little but often.

These are just some of the challenges programmers can face. But hopefully, now that you're aware of them, you can figure out how to avoid or deal with them.

Why Do Software Engineers Get Paid So Well?

One of the reasons we work is to make money to cover expenses and ensure that we can live a pleasant and dignified life.

Since we were kids, we've had to learn, complete our education, and gain experience so that we can more easily get a good job and make good money.

Since you are reading this, you have probably heard that software engineers are paid pretty well compared to many other professions.

The average salary of programmers – even those without formal education and relatively little work experience – is often much higher than that of people with jobs in other fields.

There are many reasons for this, but here I'll discuss what I consider to be some of the main ones.

Increased need for software engineers

In our world today, almost every company needs software engineers. This is because technology is a big part of our daily lives.

We use technology in our phones, cars, and at work. Companies in many areas like health, education, and fun activities need software engineers to make and look after their computer programs.

Because so many companies need these skills, there are a lot of jobs for software engineers. This makes companies offer big salaries to get the best software engineers to work for them.

Also, being a software engineer is not easy. It takes a lot of learning and practice.

Technology keeps changing, so software engineers have to keep learning new things. Not many people can do this well, so there are not too many software engineers.

This means that because so many companies want software engineers and there are not enough of them, they get paid a lot.

In simple words, software engineers make a lot of money because they are needed a lot and there are not enough of them who can do the job well.

You help turn ideas into reality

When you want to build a house, first you seek the help of an architect who comes to your land, analyzes the environment, and then, after some time, comes up with a detailed plan for every part of the house.

Then, this plan is taken by a building engineer who manages a team of workers and the entire construction process until the construction of the house is completed and the house is ready.

This is highly skilled work that requires a lot of training and expertise. It's the same with being a developer. You get paid relatively a lot because it reflects the high level of skill you have and the amount of effort and work it takes to do your job.

Software engineers are able to turn an idea that a client has into a computer program which then can bring benefits to people all over the world. This is a very valuable skill, and such it is rewarded accordingly.

Your solutions can connect people all over the world

When you think about a major highway, consider how it connects regions and transforms travel and commerce.

For instance, a major road might link two major cities, greatly increasing the flow of tourists and business travel between them.

Building such a highway requires a massive investment and a lot of effort, but once completed, it saves people significant time and opens up new opportunities.

This concept is similar to the creation of computer programs.

When a program is developed, it has the potential to connect millions of people worldwide who aren't in the same country or even on the same continent.

Take social media apps, for example. They're computer programs designed for global use, helping people like you, your family, and friends communicate, meet new people, or stay updated with the latest news.

Or consider Google's search engine, which processes over 3.5 billion queries daily on a variety of topics. It can help people anywhere, as long as they have an internet connection, solve their problems and learn new things.

These programs, much like a well-constructed highway, facilitate connections and interactions, making life more efficient and connected for countless individuals.

Software Engineers work in many areas

A special thing about software engineers is that they can work in many different areas. They are not just stuck in one kind of job.

This is really important and one of the reasons they get paid a lot.

Imagine a software engineer making a program for a doctor's office to keep track of patients.

Then, maybe the next week, they might make a system for a hotel to book rooms, or help a school manage its information.

Software engineers can help lots of different businesses by making computer programs that solve problems and make things easier.

Different companies, like those in health, hotels, or schools, might not know much about technology. But they know it helps them do better.

So, they pay software engineers well to make good technology for them.

This is because software engineers can do a lot to change and improve how different businesses work.

It's more than just writing code; it's about making tools that really help businesses in many ways.

You are constantly improving your skills

Many developers constantly work to develop new tools to facilitate their daily work and make it easier or less time-consuming.

They write programs to do repetitive tasks for them, so they can then spend that saved time implementing logic and more complex solutions things for their projects.

So as a programmer, you'll always be improving your skills and getting faster at providing solutions to problems. You'll adopt the most powerful tools that help you perform your job faster and get more done.

A project that might have taken much longer, you can now finish in less time by using these new tools you have learned. This means that businesses who use your services as a programmer are able to go to market faster with useful products that serve customers better.

In other words, software engineers are paid so well because they have such specialized and valuable skills that allow them to help many people around the world.

How to Prepare for Your Coding Journey

Your Ego is Your Enemy

When you begin thinking about starting your journey into coding, it's easy to feel overwhelmed.

You might envision complex systems and software like those at Google or Amazon and wonder how you could ever understand such complexities.

Often, when we set out to become proficient coders, we find that our biggest obstacle isn't the code itself, but our own egos.

Here, by ego, I mean an unhealthy belief in our own importance: our arrogance and our self-centered ambition.

It's like a stubborn voice inside us that insists on being the best without considering the collaborative, challenging, and iterative nature of learning to code.

Ego can mislead us into thinking we're more knowledgeable than we are, hindering our ability to learn and collaborate effectively.

It stands in the way of truly mastering coding, building productive relationships with fellow learners, and recognizing or creating opportunities for growth.

Ego is a constant threat, not just in professional life but as we embark on learning something new like coding.

It can prevent us from building great software, advancing in our learning goals, and recovering from setbacks.

To guard against ego, we need to be aware of its influence at every stage of our learning journey.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” — Sun Tzu

How to Overcome Ego in the Early Stages of Learning to Code

You might be starting with high enthusiasm, perhaps influenced by the success stories of self-taught coders or the allure of becoming a tech prodigy.

In such cases, ego might convince you that success will come easily, that you'll quickly master programming languages or skip the usual learning curves.

Remember, the most impressive achievements in coding come from dedication and hard work. Consider the builders behind WordPress, Microsoft, and Google, for example.

Their success stories are marked by relentless effort, not just innate talent or luck.

When starting your coding journey, don't fall into the trap of overestimating your abilities. Commit to the process, dedicate time to practice, and embrace the grind of learning.

Collaboration is key, as many groundbreaking projects are the result of team efforts.

Consider how major tech innovators worked together: Google’s founders met at Stanford’s computer science department, Microsoft began with Bill Gates and Paul Allen working together, and WhatsApp was a collaborative creation.

Learning to code is similar – it's about joining a community, sharing knowledge, and growing together.

Ego and Ongoing Learning

Even after landing your first coding job or completing a few projects, don't let ego convince you that you've learned all there is to know.

The tech field is ever-evolving, and continuous learning is vital.

Remember, the journey in coding doesn't have an endpoint. It's a continual process of growth and adaptation.

Your ego might make you resist new challenges, shy away from learning new languages or frameworks, or avoid seeking help when stuck.

Yet, these are the very experiences that enrich your coding journey and lead to true mastery.

History is full of examples where initial failures or setbacks led to great success.

Bill Gates and Paul Allen had a failed venture before Microsoft, and many successful apps and platforms were born out of earlier unsuccessful attempts.

Embracing Humility and Persistence

To thrive in your coding journey, humility and persistence are your greatest allies. Accept that failures and challenges are part of the process. Use them as stepping stones, not roadblocks.

Be open to continuous learning, seek feedback, and remember that collaboration enhances your growth.

As you progress, remember that ego is the enemy of learning. Stay grounded, focus on the process, and cherish the journey of becoming a skilled coder.

Your unique contribution to the world of coding lies not in being the best from the start but in being open to growth and learning from every experience along the way.

“The first principle is that you must not fool yourself — and you are the easiest person to fool.”— Richard Feynman

In learning to code, let your curiosity and passion for the craft be your guide, not your ego.

Keep your focus on the work, the learning process, and the joy of coding.

Identify the whispers of ego early on and counter them with discipline, humility, and a commitment to lifelong learning.

Take Responsibility for Your Learning

Do not blame others for your lack of understanding or struggles when learning to code. Simply accept that you are the common denominator of all the problems and difficulties in your life.

Are you not understanding a particular lesson?

Do not blame the course, the book, or the instructor. Learning is your responsibility.

Every teacher tries their best, and we live in a time when you have plenty of options to choose and learn from.

So there is no excuse. If you work hard, you'll get there.

Have you recently found that a piece of code you wrote isn't functioning as expected in your project?

Even though this may be a rare occasion or something that you may not predict that could happen, you should still take responsibility.

First, admit that you made a mistake. Then, go and figure out how to fix the problem.

Use this as an opportunity to learn and document what went wrong and what you could do better in the future.

Do you feel that you aren't able to keep up the pace with learning new things?

I believe you already know that you are responsible for that as well.

It can be hard and very time consuming, especially if you have kids or other family to look after and also want to have a social life.

Still, your growth is your responsibility.

You have to own that.

You should try to carve out time a few times a week to improve your skills, whether that’s during your day job when there are no tasks to work on and you are free to learn, before leaving for work, in the evenings, or whenever is realistic for you.

You could try to wake up one hour earlier before work and invest that period of time in learning new things, or you could also set aside a few hours on a Sunday morning to do that.

I'm Afraid to Start Programming. What Should I Do?

Starting your journey in programming can be daunting, and it's natural to feel fear or self-doubt. But remember, even the most successful figures in tech and science have faced these challenges.

Consider Sergey Brin, the co-founder of Google. He achieved remarkable success but has spoken about feeling like an impostor, experiencing doubts about his contributions to the tech industry. His story shows that such feelings are normal, even at high levels of achievement.

Sheryl Sandberg, former COO of Facebook and a tech industry leader, also discussed her struggles with impostor syndrome. Despite her significant accomplishments, she's talked about moments of self-doubt and questioning her abilities. This highlights that everyone, regardless of their success, can experience these feelings.

Astrophysicist Neil deGrasse Tyson has been candid about his own experiences with impostor syndrome, reflecting on moments of self-doubt in his science career. His openness helps demystify the fears associated with stepping into new, challenging fields.

Dr. Maya Angelou, an esteemed author and poet, also expressed similar feelings. Despite her numerous accolades, she felt doubts about her worthiness and achievements. Her journey is an inspiring example of overcoming self-doubt to achieve greatness.

Wayne Gretzky's famous quote, "You miss 100% of the shots you don’t take," resonates deeply here. If fear holds you back, you'll never discover your potential in programming.

Starting in programming can be intimidating, and fears of failure are common. However, it's crucial to begin despite these fears. Remember, the tech experts and leaders you look up to started as beginners, just like you. They faced fears, made mistakes, and learned from them.

So, if your goal is to excel in programming or software engineering, embrace the challenge. Start learning and don't let fear or self-doubt deter you.

Everyone's journey starts with a single step, and feeling uncertain is simply a part of the process towards becoming skilled and confident in your abilities.

Strategies and Tips for Learning to Code

Can you Learn Coding in a Single Night?

A software bug in a Therac-25 radiation therapy machine caused the death of five patients after receiving a massive dose of X-rays.

Knight Capital lost half a billion dollars in half an hour when a software bug allowed computers to sell and buy millions of shares with no human oversight.

These and many other stories tell how seemingly unimportant bugs can actually cause disasters.

Software is becoming more and more important – which means that developers have more and more responsibility to be very careful and really good at what they do.

So is it possible to learn programming in just one night?

As funny as it sounds, there was a similar question asked on Quora more than 5 years ago.

Unfortunately, I cannot find that exact question anymore, but it stuck in my memory since then.

Maybe, the person who asked the question was trolling, or had an exam the next day and was hoping to get encouraging answers to pull an all-nighter and study before the exam.

I don’t remember the other answers, but I read one answer there which was really wise and quite funny.

The answer was something along these lines:

Take a laptop and go to the north pole. A night there lasts 6 months. That’s how you can increase your chances of learning programming in one night.

We live in a time where we want everything in a matter of seconds.

We want fast food, fast cars, six-pack abs in 6 days, and so on.

That’s the mindset that we have most of the time, and we expect the same thing in other areas as well.

But true mastery comes from a lot of work and dedication.

Take, for example, Peter Norvig, the director of research at Google, who suggests that you to learn to program over the course of 10 years because rushing isn’t going to be worth it:

“In 24 hours you won’t have time to write several significant programs, and learn from your successes and failures with them. You won’t have time to work with an experienced programmer and understand what it is like to live in a C++ environment. In short, you won’t have time to learn much.

So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.”

If you mention that to people, they may not like it, but that’s the actual reality.

You cannot just jump from printing a few “Hello World” statements in the console to building the next Google a few days later.

I am not denying the fact that you could implement a really nice application in a few hours – but the ability to do that doesn’t come that fast.

Sure, you might have heard of the developer who implemented 10 applications in 10 hours in one sitting. But that’s not the result of one-night of learning. He worked hard and learned a lot before he managed to pull that off.

It takes time to learn something really well.

The more you do something, the more likely you are to get better at it. The more you practice, the more you'll be able to improve your performance – and the cycle repeats.

Now that you've read and hopefully internalized that, do not get too overwhelmed with the long journey ahead of you.

Will Smith describes it really well:

“You don’t set out to build a wall. You don’t say ‘I’m going to build the biggest, baddest, greatest wall that’s ever been built.’ You don’t start there. You say, ‘I’m going to lay this brick as perfectly as a brick can be laid.’ You do that every single day. And soon you have a wall.”

Now, instead of asking yourself whether you can learn programming in 1 night, a better question would be:

What is one small but valuable thing that I could learn tonight?

Avoid Tutorial Hell

Have you ever spent hours watching tutorial videos and then felt like an expert, only to realize you couldn't actually do what the tutorial showed?

This is a common trap, and it's called "Tutorial Hell." It refers to the false sense of learning you may get when you read through a bunch of tutorials without actually trying to build something yourself.

When you watch tutorials without practicing, you might think you're learning, but you're really not getting the full experience.

Just watching something passively is not the same as truly understanding and being able to use that knowledge.

Learn to Code by Coding

Learning to code is something that many people try to do just by watching videos or reading articles.

But if you really want to learn how to code, you have to get your hands dirty with the actual code.

It's not enough to sit back and watch someone else do it. You need to write the code yourself.

This is the only way to turn the theoretical knowledge from videos into practical skills.

Move Beyond Passive Learning

When diving into a specific framework or technology, it's easy to fall into the trap of passively watching or reading about it.

Instead, take an active approach.

Think of a project that you find interesting and would like to create. This could be anything from a simple website to a small app. The key is to choose something that excites you and motivates you to learn.

The project you choose will become your testing ground. It's where you'll apply everything you've learned from watching tutorials.

This hands-on practice is invaluable.

As you work on your project, you'll encounter real problems and challenges.

Solving these will deepen your understanding of the coding concepts and techniques you've learned about. You'll learn so much from googling, researching, trying and failing, and trying again.

It's in facing and overcoming these challenges that true learning happens.

Remember, the path to mastering any skill, especially coding, lies in active participation.

Watching tutorials is a great start, but it's the practice that makes you proficient. Learning by doing.

Your personal project is not just a test, but a journey towards deep understanding and skill development.

So, close the video player, open your code editor, and start building.

Your journey of true learning begins with the first line of code you write.

How to Understand Complex Topics by Using the Feynman Technique

In the world of software engineering, there's a vast difference between simply knowing the name of something and truly understanding how it works.

You might know what a certain machine or a piece of software is called, but do you really grasp how it operates and accomplishes tasks?

This distinction is crucial in a field as complex and ever-evolving as software engineering.

One effective way to bridge this gap between superficial knowledge and deep understanding is through the 'Teach-Back' Technique.

This method, often associated with the famous physicist Richard Feynman, revolves around the idea of teaching what you learn to someone else.

What is the 'Teach-Back' Technique?

Imagine you're explaining a new concept or tool you've learned in software engineering to a friend or a colleague who isn't familiar with it. This could be a programming concept, a coding language, or an advanced topic like blockchain or machine learning.

First, begin with an explanation: start by breaking down the topic into simple terms. Your goal is to make it understandable to someone with little to no background in the subject. This exercise forces you to clarify your thoughts and solidify your understanding.

Next, identify any gaps in your knowledge: as you explain, pay attention to moments where you stumble or feel uncertain. These are indicators of areas where your understanding is still shallow. Return to your study materials, whether they are books, articles, or online resources, and delve deeper into these topics.

Remember that simplicity is key: in your explanation, avoid jargon and complex language. The ability to simplify a concept without losing its essence is a sign of true understanding. This approach not only benefits your learner but also reinforces your grasp of the subject.

Sharing helps you solidify your knowledge: once you're comfortable with your explanation, consider sharing your newfound knowledge more broadly. Writing a blog post, creating notes, or even recording a video can further solidify your understanding and benefit others.

Reaping the benefits: this technique of teaching others not only deepens your knowledge but also enhances your effectiveness as a software engineer. It's a powerful tool for learning and a testament to the saying, "To teach is to learn twice."

Remember, the true test of understanding in software engineering is your ability to convey complex ideas in simple, accessible terms.

The more effectively you can explain a concept, the better you understand it.

Embrace the role of being a teacher, even if your student is just an imaginary one, and watch as your understanding and proficiency grow.

This approach is not just about gaining knowledge – it's about mastering it.

Don't Memorize the Syntax

Say you move to a new city and you don’t know where the nearest grocery store is. You don’t beat yourself up — this is expected. You just use Google Maps to find it.

After you’ve been there several times, it’s highly likely that you won’t need to use Google Maps anymore (unless you want to check traffic or see if there are any accidents on your route – things like that).

So you naturally, over time, learn where things are – but it’s not that you’re intentionally trying to memorize every road, every possible path to a certain destination.

There may be cases when you're only interested in going to a certain place once.

It’s the same with certain methods that you may need to use in a programming language. New software developers may feel bad that they’re not memorizing sufficient syntax — that they still need to refer to the documentation.

They see this as a sign that they’re bad developers.

Here are a couple of common questions you may have when you're starting your journey into programming:

• How will I be able to learn all this syntax?

• How long will it take for me to master it and write code without referring to the documentation?

Then when you’re able to memorize some frequently used syntax, you may think that you’ve become good at programing.

You get the impression that it’s the amount of a language or the number of programming languages and frameworks you are able to memorize that really matters.

To put things in perspective, let’s compare the syntax of finding the length of a string in different programming languages:

• seq.length, JavaScript lists, Java arrays.

• seq.size(), Java sequences, jQuery expressions (deprecated).

• len(seq), Python.

• seq.count(), Django querysets.

• SeqType'Length, Ada arrays.

• length seq, Haskell.

• (count seq), Clojure.

• sizeof(seq)/sizeof(seq[0]), C, statically allocated.

• strlen(seq), C, null-terminated.

As you can see, each language or technology has its own version of finding the length of a string. This should show you that it’s really difficult to memorize the same function in 12 different ways.

It’s very unlikely that a developer who’s used multiple programming languages can memorize all the syntax that they have used in the past. They may even not bother trying to learn it in the first place. So why is this? How does anyone actually write code?

Is Syntax So Important That I Have to Memorize It?

To answer this, let’s see what some senior developers say.​

Here's a comment from a senior dev at Google:

Embedded content

​​And here's one from a developer who works on commercial airline control systems:

Embedded content

​​And JP went on to further comment on that previous tweet:

Embedded content

​​Jon, a lead Android dev at Phunware, says he can't read an input stream without copying and pasting code from Stack Overflow:

Embedded content

​​Another Tim commented on the original Tim's post:​​​

Embedded content

​Lastly, I'll leave you with Umer's comment:

I wrote 255 lines of code that included a working server and a client. I queried google 23 times mostly landing on StackOverflow, Netty 4 website, GitHub, and JavaDocs. If you do the math, that averages out to 1 query every 10 lines of code! I had no idea. — Umer Mansoor

These insights should give you courage — you don’t have to be ashamed that you can’t remember every detail of the syntax.

This is something that many junior developers may be concerned about. The truth is, you really do not have to memorize everything as you go.

Not even tech recruiters care about that. Here’s the response that an engineering director at Google gave regarding this:​

Embedded content

​

Here’s another quote from a comment on Hacker News:

I not only use Google frequently, I use it to search for things I myself have written in the past.

I can’t count the number of times I’ve Googled for a programming question where the answer is found on a Stack Overflow page I’ve written. If it’s a particularly old answer that I’ve completely forgotten, I’ve even thought to myself, “Wow this genius sounds just like me!” as well as “This idiot has no clue what he’s talking about!” .

A couple of years ago, I read a post on a Facebook group from a senior developer mentioning that when recruiters ask him whether he has experience with a particular technology for which he hasn’t, he responds, “That’s just another tool.”

He means that he may not have had the chance to work with it in the past but he has the confidence that he can learn it.

You might not need to spend months before you're able to work with a new tool. You may only need a few hours to read its documentation and then learn more as needed along the journey without the need to memorize everything.

You do not expect to have all green lights on when you start your journey to your destination. You pass through the current green light and stop at a red light. You wait until the green light is on before proceeding.

Nowadays, we get new languages and frameworks, or considerable changes to existing ones, so that trying to memorize the syntax is both difficult and not that important. As one commentator on a blog post brilliantly put it:

“Great engineers know how to formulate good queries. Yet interviewers expect walking dictionaries.”

So, to sum it all up: get really good at googling and learning as you go :)

Keep a To-Learn List

You might have heard of to-do lists for keeping track of daily chores or tasks.

But as a software engineer, where learning is as important as doing, a "to-learn" list becomes your roadmap to growth and discovery.

Think of a "to-learn" list as your personal guide in the world of technology.

Just as a to-do list reminds you to buy groceries or pay bills, a to-learn list keeps track of all the exciting things in technology you want to explore.

This could be a new programming language that's taking the world by storm, a revolutionary tool that can change the way you code, or the latest trends in fields like artificial intelligence.

Your to-learn list is more than just a collection of cool things – it's a set of goals.

It's like having a bucket list for your professional development, full of adventures waiting to be embarked upon.

Whether it's mastering a new coding language, diving into insightful books, or enrolling in online courses, this list is your ticket to a world of endless learning.

A to-learn list keeps your curiosity alive. It's like having a treasure map where X marks the spot for new knowledge.

Each item on the list is a stepping stone to understanding the deeper workings of technology, beyond just using it.

This list also acts as a motivator. Imagine each new skill you learn as a level-up in a game, making you more capable and skilled in your job.

It's a reminder that your journey in software engineering is filled with exciting milestones waiting to be achieved.

Remember, there's always more to learn, and that's a good thing.

It keeps you humble and open-minded, acknowledging that the tech world is vast and ever-evolving, and no one knows it all.

This perspective is vital for continuous growth.

As you check off items on your to-learn list, you'll find yourself becoming a problem-solving wizard.

Each new skill or piece of knowledge adds to your ability to tackle complex challenges, making you an invaluable asset to your team.

The more you learn, the more valuable you become as a software engineer. This means being able to handle tasks more efficiently and creatively, boosting your productivity and making you a star performer in your field.

Your "to-learn" list is a powerful tool in your journey as a software engineer.

It's a living document that grows and changes with you, reflecting your aspirations and curiosity.

By maintaining and updating this list, you ensure that your journey in software engineering is always moving forward, filled with continuous learning and personal growth.

So, embrace your "to-learn" list, and let it guide you to new heights in your career, keeping you curious, motivated, and ever-evolving in the dynamic world of technology.

Practical Aspects of Coding

How to Deal with Overwhelming Projects

Big software projects, like those of Google, Amazon, or WhatsApp, often seem like modern marvels.

They can be awe-inspiring, reflecting complex engineering and innovative ideas.

If you ever consider the teams behind these giants, it's natural to feel a mix of awe and intimidation. The scale and impact of such projects can seem overwhelming.

Remember, the builders of these platforms likely faced similar feelings at the outset. But they didn't allow apprehension to hinder their progress.

Instead, they channeled it into productive action, laying brick by brick the foundation of what would become technological milestones.

As a software engineer, you might not be tasked with building the next global tech phenomenon right away, but every project, no matter its size, can feel daunting at the start.

Here's a roadmap to help you tackle even the most intimidating software engineering projects.

Vision: Seeing the End from the Start

One of the most critical steps in managing a large project is to have a clear vision. This means having a well-defined picture of the end goal. The clearer this vision, the easier it will be to navigate towards it.

Try to articulate this vision in simple terms, maybe through a diagram or a straightforward description.

Your goal should be to make this vision so understandable that anyone, regardless of their technical background, can grasp it.

For instance, if you're developing a complex web application, outline its core functionalities. Envision the user experience, the interface, and the key features that will define your application.

Breaking It Down: The Art of Reverse Engineering

With your end goal vividly pictured, the next step is reverse engineering this vision into actionable steps.

This process involves deconstructing your final goal into smaller, manageable tasks. These tasks should be quantifiable, allowing you to plan and schedule them effectively.

In plotting your course, set clear milestones. These are significant checkpoints that signal progress towards your ultimate objective.

Take a web application as an example: begin by charting out the various stages of development. This could include initial design, front-end development, back-end setup, integration of functionalities, testing phases, and final deployment. Then you can tackle each one, one at a time.

Starting Point: The First Small Step

Every monumental project begins with a single, often small, step.

Do not fall into the trap of believing you can conquer the entire project in one go. Large-scale projects demand time, effort, and persistence.

Start with a manageable task or component of the project. Completing this initial task will provide a sense of accomplishment and momentum.

Progress, however incremental, is a powerful motivator. It propels you forward, fueling your drive to tackle the subsequent phases of your project.

If you find yourself hesitating to start, it might be because the task at hand seems too daunting. In such cases, break down the task further into smaller, more approachable segments.

Reflective Progress: The Importance of Review

Regularly step back and review your progress.

This practice is essential for ensuring that you're on the right path toward your goal.

It’s easy to get caught up in the minutiae and lose sight of the broader objective. A periodic review helps you realign your efforts with your initial vision.

This review process is not merely a check-in. It's a strategic evaluation of your direction and methods. It might lead to course corrections, refinements of strategies, or even a reassessment of your goals.

The Path Through

It’s common in software engineering to encounter phases of doubt and to feel stuck in a cycle of inaction.

Waiting for the perfect moment or for challenges to ease on their own is a futile approach. Instead, the key to conquering large projects lies in embracing responsibility and actively engaging with the tasks at hand.

No matter the size of the project, its completion is always achievable through careful planning, dedication, and unwavering focus.

Remember, in the realm of software engineering, the only way out is the way through.

Each step, no matter how small, is a move towards the realization of your project. Embrace each phase of the journey with commitment and resolve, and watch as your ambitious projects turn into accomplished realities.

How to Choose Projects to Build

As you start learning and trying to apply your skills, you'll likely have a lot of project ideas that you're eager to start building.

Maybe you've listed them in a project management tool or jotted them down in your notebook. You have various app concepts, software solutions, or coding experiments you're excited about. But there's a common challenge: deciding which project to tackle first.

This indecision can lead to procrastination. You might find yourself opting for activities that are more immediately gratifying, avoiding the commitment to a single project.

"Perhaps there's something more crucial I should be working on?" you wonder. "Should I start this app or that automation script? Maybe I should brainstorm more ideas and something will click."

Let's pause for a moment and consider an old fable that might shed some light on this predicament.

Learning from Buridan's Donkey

There's a story about a donkey that was exactly in the middle of some hay and water. It couldn't decide whether to eat or drink first, so it didn't do either and got really hungry and thirsty.

The donkey didn't think about just picking one thing first and then doing the other thing next.

As software engineers, we often face a similar dilemma with our projects. We have numerous ideas and concepts, but none of them will come to fruition without action.

It's essential to recognize that we can't work on every project simultaneously. Just as we can't be in two places at once, we can't simultaneously code different applications. And this physical limitation shouldn't hinder our progress towards our goals.

Just start with one project

Is it the perfect choice? Maybe, maybe not. But that's not what's critical at this moment.

The project you choose to work on probably isn't a life-or-death decision. Pick one and begin. You can always return to your other ideas later.

Start by outlining the features of the app or software. Code the first function or interface. Celebrate this progress, however small. Then, continue developing piece by piece.

Repeat this process for your other projects.

Don't let a plethora of choices impede your progress. Over-analysis leads to paralysis, stifling your movement towards completing your projects.

Stop overthinking. Start coding.

Let the world benefit from your work, one completed project at a time.

How to overcome procrastination

This is a common challenge for software engineers: "I know I need to start coding, but I just can't seem to begin."

"The blank IDE screen is intimidating. I can't get my fingers to start typing."

Consider how Ernest Hemingway, a renowned writer, dealt with writer's block:

“Sometimes when I was starting a new story and could not get it going, I would sit in front of the fire and squeeze the peel of the little oranges into the edge of the flame and watch the sputter of blue that they made.

I would stand and look out over the roofs of Paris and think, ‘Do not worry. You have always written before and you will write now. All you have to do is write one true sentence. Write the truest sentence that you know.’

So finally I would write one true sentence, and then go on from there.”

Adapt this approach to your coding. Start with a simple feature or function.

If that's all you accomplish for the day, so be it. Consistent small steps lead to significant progress.

Even a modest amount of coding each day maintains consistency. And often, once you start on a small task, you'll find yourself naturally progressing to more substantial parts of the project.

Inspiration from History

Consider Isaac Newton, who, during the bubonic plague lockdown in 1666, retreated to his family home from the University of Cambridge.

Without modern tools or online classes, Newton used this time to delve into complex mathematical problems, eventually laying the groundwork for calculus.

His focus and dedication led to groundbreaking discoveries.

In software engineering, it's easy to get caught up in finding the perfect tool or environment.

But remember, the real work comes from dedication and effort, not from having the latest technology or software.

“Real professionals don’t hide behind their tools — real professionals use what’s around them. It’s the amateurs who try to nerd out about their tools — it’s all a distraction from really doing the work.” — Derek Sivers

Let's move beyond excuses. Let's get back to coding.

Learn by Building Things from Scratch

Every time you start a new project, think of it as adding a brick to your knowledge fortress.

You'll encounter the essential elements of software – like algorithms, data structures, and design patterns. These are the ABCs of software, and grasping them deeply turns you into a more skilled and versatile engineer.

When you build from scratch, you're the architect and the builder. You get to decide every detail, customizing your project to fit your interests and needs.

It's like cooking a meal where you choose every ingredient to suit your taste, making the entire process deeply personal and satisfying.

Starting from zero means you'll walk through every stage of creating software – from the first sketch of your idea to making it work and showing it to the world.

This complete journey is like reading a book from cover to cover, giving you a full picture of how software comes to life.

Building from the ground up often means exploring the depths of the technologies you're using. Imagine diving into the ocean to discover what's underneath – that's what you do with each technology, understanding its secrets and subtleties.

As you build, you'll face various puzzles and challenges. Each problem you solve sharpens your mind, not just in coding but in finding smart, elegant solutions to tricky situations.

There's a special kind of pride and confidence that comes from seeing a project evolve from a simple idea to a working program.

It's like climbing a mountain – with every step, you feel stronger and more capable.

The hurdles you overcome while crafting software from scratch are similar to those you'll face in the professional world.

Be it fixing an unexpected error, adding a complex feature, or managing your time – these experiences are like rehearsals for the real-world stage of software engineering.

Embarking on a project from scratch is a cornerstone of your journey as a software engineer. It's an exercise in patience, persistence, and creativity.

Remember, it's not just about the software you build. It's about the skills you hone, the knowledge you acquire, and the confidence you develop.

Each project is a step towards becoming not just a coder, but a true artisan in the realm of technology. So, begin with an empty file and a spark of an idea, and let the magic of creation unfold.

Build Something that Already Exists

In the thrilling journey of software development, starting a new project often feels like opening a treasure chest filled with endless possibilities.

While it's tempting to dive into creating something unique and complex, the path of learning often calls for a simpler, more familiar approach.

Now, we'll explore the idea that not every project must be groundbreaking. Sometimes, the best learning comes from simplicity and familiarity.

Imagine starting with a blank canvas. Instead of painting a complex masterpiece right away, you first practice with simple strokes and familiar patterns. This is the essence of learning in software development.

By keeping projects simple and manageable, you avoid the trap of overwhelming complexity, allowing you to focus on the fundamentals of coding and problem-solving.

Think of existing open-source projects as a library filled with books you can learn from. These projects, created by others and shared on platforms like GitHub, are like guides offering valuable lessons.

They're a starting point, showing you how things are built and encouraging you to explore further.

Picture yourself as an apprentice painter, learning by replicating the works of masters. Similarly, in software development, cloning an existing project is a hands-on way to learn coding and problem-solving.

After recreating the project, compare your work with the original. This comparison acts as a mirror, reflecting your strengths and areas for improvement.

Think about an app or a website you use daily. What if you tried to build a version of it yourself? This approach makes learning fun and relevant.

Working on something you're familiar with keeps you engaged and helps you understand the project's intricacies more deeply.

In your learning journey, focus on projects that challenge and enhance your skills, rather than trying to invent something entirely new. It's like practicing scales in music – they may not be glamorous, but they're essential for growth.

Prioritize learning and skill development over the pursuit of a groundbreaking idea. As you embark on new software projects, remember that your primary goal is to grow as a developer. It's not just about building something novel – it's about building your capabilities and confidence.

By replicating existing projects and focusing on the learning process, you turn each project into a valuable step in your journey.

This approach not only enriches your understanding but also lays a strong foundation for your future as a skilled software engineer.

So, grab your tools and start building – not just software, but a path to mastery in the art of development.

Beyond the Basics

Develop a Love Learning

Software development is one of the most in-demand professions of our time.

There are constantly new job openings, which attract both youngsters and already employed people from a wide range of professions.

They know that you can get a really good salary working as a software engineer, and so they start their careers with great ambitions.

Even if you get a job in software development, if you really want to become great, it helps to love learning and programming.

It is one of the few professions in which you constantly have to learn something new. It’s not just the existing concepts you need to know. You have to adapt to the constant influx of new technologies.

You have to adapt to the changes in the market and learn whatever new things are currently considered as valuable. In short, you will have to consistently learn a lot.

In order to keep your brain constantly engaged in learning, you will have to be curious and stay humble.

Often, programmers get employed on the basis of their existing knowledge and start to think they don’t need to learn new things anymore. But you will only be able to excel as a software engineer if you are curious and love learning, as the need to learn never ceases.

In November 1915, after writing only two pages of what he referred to as “one of the most beautiful works of my life,” Einstein sent his 11-year-old son Hans Albert a letter.

He praised his son for his learning efforts, saying, “That is the way to learn the most…When you are doing something with such enjoyment that you don’t notice the time passes.”

“Curiosity has its own reason for existing,” Einstein explains. “One cannot help but be in awe when one contemplates the mysteries of eternity, of life, of the marvelous structure of reality.”

Become curious about how a framework works and is structured. When you learn something thoroughly, you gain a clear picture of its mechanisms and functionalities.

For example, don't simply accept that scikit-learn is a great framework for machine learning — learn how it works, behind the curtains. And consider the possibility of contributing to and improving it, as it is open source.

Also, try not to be overly concerned with money. Of course, we all need money to pay our bills and buy food for ourselves and our family. These are basic needs, and we need to meet them – so money is critical. But try to cultivate a passion for learning and developing for the sake of it. This will make the financial compensation all the more rewarding.

Try to develop a love of programming and feel grateful that you have the opportunity to positively impact the lives of millions of people with the lines of code that you write.

Einstein believed that “love is a better teacher than a sense of duty.”

What we can learn from this as software engineers is the importance of not just working for a good salary but working because we love learning and our work in general. If we can develop an intrinsic curiosity and drive that keeps us engaged after work or during the weekends when our boss is not watching, all the better.

Look at the Bigger Picture

In the fast-paced and exciting world of software engineering, it's crucial to understand that being a software engineer is about much more than just writing code.

Imagine you're not just a builder, but also an architect and a visionary. Your role is like being a key player in a big team, where your ideas and work help the team win.

Understand your impact

When you're a software engineer, you might spend a lot of time working on specific coding tasks – like solving a puzzle piece by piece.

But, it's important to remember that you're actually helping to complete a much larger puzzle.

Let's say your company is like a big ship, and you're not just fixing parts of the ship – you're helping it reach its destination.

Imagine you're making an app for a local bakery. Instead of just focusing on making the buttons work, you should also think about how your app will help the bakery get more customers and make their life easier.

Seeing the whole, not just the parts

As you grow in your career, you'll start to see not just the lines of code you write, but the whole project, like looking at a whole forest instead of just one tree.

This means you'll start to understand how your work affects everything else and can make decisions that help the entire business.

Think of a puzzle game on your phone. If you only focus on one small part, you might miss a better solution that solves more puzzles at once.

From coding to contributing

When you start focusing on the most important tasks, you become more than just someone who writes code. You become someone who solves big problems.

This is like moving from being a player in a game to being the one who helps plan the strategy of the game.

Imagine your company is like a garden. At first, you might be planting individual flowers (writing code). But later, you start to plan where to plant trees and how to make the garden more beautiful (strategic thinking).

More than a coder

By aligning your work with what the business really needs, you become a key player on your team. Your work starts to have a big impact, and you become someone everyone relies on.

It's like being a star player on a sports team who not only scores goals but also helps the team win championships.

If you're working on a website, don't just make it look good. Think about how it functions, how it can attract more visitors, and how it can help the business grow.

Being a software engineer is an amazing journey. It's not just about writing code, but about using your skills to help the business and its customers.

When you start to see your role in this bigger way, you grow not just as a programmer, but as a key member of your team.

This approach will help you develop both personally and professionally in the exciting world of software engineering.

Remember, you're not just building software – you're building success stories.

Embrace Lifelong Learning in Software Engineering

Think of the field of software engineering not as a one-time race but as an ongoing marathon with new and exciting paths to explore at every turn.

Your formal education, whether you got a college degree or participated in a bootcamp or taught yourself to code – it's just the starting line.

What lies ahead is a thrilling adventure of continuous learning and growth.

Picture yourself as a detective in the world of technology. Each new challenge is a mystery waiting to be solved.

At first, these puzzles may seem daunting, but as you learn more, you'll find joy in piecing together the solutions. This journey enhances your confidence and turns complex problems into exciting quests.

In the fast-paced tech landscape, what's hot today might be forgotten tomorrow. So while it's important to stay up-to-date and aware of the latest trends, don't forget to work on the fundamentals and learn the mainstay technologies.

So while you'll want to learn new programming languages and frameworks, and get comfortable with the latest software, be practical about what you focus on.

As you learn and grow, your value as a software engineer will skyrocket.

This isn't just about earning a bigger paycheck – it's about getting your hands on more exciting and challenging projects.

Just like a sought-after artist, your up-to-date skills and knowledge can help make you a hot commodity in the tech world.

Imagine each new skill you learn as a key. The more keys you have, the more doors you can open. This could lead to better job offers, working on groundbreaking projects, or even guiding a team.

Your knowledge and experience are like a map, guiding you to a rewarding and dynamic career.

Good Luck!

Thank you for reading this handbook! I hope you now feel better equipped to break into the world of tech, grow your skills, and work towards your first – or next – developer job.

Get the PDF version of the book

You can read this book as a PDF by downloading it here.

If you're a developer looking to improve your coding skills, building projects is a great way to do that. But coming up with project ideas that actually make you eager to start can be tough.

That's why I wrote this article: to help you learn how to come up with fun and interesting projects you can build.

The Process

I come up with my project ideas through the content that I consume and the problems that I experience.

For example, you can keep a notebook handy and jot down:

1. Problems you come across in your day to day work or life
2. Desires or interests you've had on the back burner

Don't limit yourself in this phase – anything you come across is fair game. I'll give you some of my examples.

Problems:

• Forgetting to reach out to my long distance friends
• People calling me about buying my property
• Forgetting to text people when I get home safely
• Sites that constantly ask if I want to accept or reject cookies

Desires:

• Conversation partner in a language I'm learning
• Finding foreclosed houses
• Finding pop ups in my city quickly and easily

Then, after I have a list of problems and desires, I start looking into whether or not I can make a coding project out of it. I'll demonstrate by walking through my latest project from concept to finish.

Language Partner Project

I've always been interested in becoming fluent in another language, with dreams of holding deep conversations with native speakers. I've tried for several years to turn my rudimentary Spanish knowledge into fluency, reading all sorts of books and watching videos to see different techniques and recommended tools.

Then I read Ultralearning by Scott Young. It's an interesting book, but I mostly bring it up because it reminded me of the most important thing: while I'm going back and forth over how to best study vocabulary and grammar, I'm not practicing the one thing that would most greatly improve my speaking ability – speaking.

Speaking is the quickest way to improve my conversational skills, but it's also the most painfully awkward. I don't love the idea of stumbling over my words with strangers for weeks on end, even if that person was a tutor experienced in deciphering beginner Spanish. So I began to think: what if I could program a language partner?

And so my project was born. From that initial concept, I verified that what I wanted to do was possible. My background is in web development, so that meant checking what the web was capable of (using https://whatwebcando.today, which I found on a great Pluralsight course about Progressive Web Apps) then tackling it as best I can.

When I run into tools or concepts that I don't know, I go to the documentation or YouTube – whichever can explain it to me in a way I actually understand (and don't forget ChatGPT here too. Asking it to explain a concept to you like you're five comes in really handy.).

I try to do at least one Getting Started tutorial from whatever resource I chose to make sure I actually understand the concept. Then I go right back to my project. I try to document what I learn as I learn it.

For an extra challenge, I sometimes like to find apps that are similar to the idea that I had and try to think of ways that I can differentiate my app to push myself even more. If I can't think of anything, that's fine – the project is still worth doing. But I feel it's good preparation to think about the market when creating a product anyways.

All of this to say, a great coding project is often found in the gap between wanting something and not being able to find anything already out there to suit your specific needs. I also find this particularly helpful because the ideas that arise this way are custom tailored to my interests.

While I do think that learning about cloud services or software engineering best practices is important, that in and of itself would bore me to tears and I don't stick with projects when they're boring. It's more important to me that the project revolve around interests that I already have so that I stay engaged and creative.

Caveat

The number one issue I see with having a process like this is that it can feel like you're butchering a golden idea. For instance, if I'm only just beginning to grasp how to use mic audio from the web browser, my language partner project might not be as sleek as I'd dreamed, and that can make the project seem like it's not worthwhile.

Or worse yet, it can trick me into thinking it's better if I put it off until I'm ready.
That's why I love the diagram below from Austin Kleon's Steal Like an Artist.

The Life of a Project from Steal Like an Artist by Austin Kleon

It's both a reminder of the big picture and a call to action. No, your first time tackling the project probably won't be your best. But it'll be worth it.

More importantly, any truly great idea is iterative. The first iteration is never what's sold on the shelf. The sooner you get through this rough draft, the sooner you can get to the second, the third, so on and so forth until you have your finished product.

Wrapping Up

Thank you for taking the time to read this article! If you found it helpful, please consider leaving me a star on GitHub or consider endorsing me for relevant skills on LinkedIn.

And if you'd like a tutorial on the language learning partner that I'm working on, or a more in depth walkthrough of anything I've mentioned here, please let me know!

You may have heard how students can use ChatGPT to cheat on assignments. But we should also talk about what a fantastic study tool it can be.

In this article we'll discuss how you can use ChatGPT to help you study and learn new skills.

You'll see how to instruct ChatGPT to give you a nicely formatted list of information that you should memorize. You'll then see how to input it into a Python program that will output an Anki package. Finally, you'll load the package into Anki to help you remember the concepts through memory triggers.

I'll show you how to create Anki cards programmatically using Python and the Genanki library. We will create an Anki deck for learning the Linux filesystem directories and their descriptions. The deck will contain basic and reverse type cards for each directory.

What is Anki?

Anki is a powerful open-source flashcard application that helps users memorize information more efficiently using spaced repetition. It is available on multiple platforms, including Windows, macOS, Linux, iOS, and Android.

Anki allows users to create their own decks of flashcards containing text, images, audio, and even LaTeX equations.

Learning how to properly use Anki is a skill in itself. Here is a good video to get you started. In this program we will use the concepts of Anki models, cards, notes, decks and packages to create our card set. But first, let's learn a bit more about how Anki works.

Anki Models

An Anki model, also known as a note type, defines the structure and layout of a set of cards. Each model consists of a set of fields, which store the information to be learned, and a set of card templates, which determine how that information is displayed on the cards.

Models allow users to create different types of cards and layouts for various learning needs, such as basic cards, reverse cards, and cloze deletion cards.

Anki Cards

An Anki card is a digital flashcard containing information to be learned. Each card has a front side, which usually contains a question or a prompt, and a back side, which contains the answer or additional information related to the front side.

Anki cards can contain text, images, audio, and even LaTeX equations. Cards are generated from models and their associated fields, which determine the content and layout of the cards.

Anki Notes

An Anki note is a single piece of information that is used to generate one or more flashcards or Anki cards.

Each note is based on a specific model (also known as a note type), which defines the structure, layout, and fields for that note. Fields store the actual content of the note, such as questions, answers, or prompts, while the model determines how that content is displayed on the generated cards.

Anki Decks

An Anki deck is a collection of cards on a specific topic or subject. Decks are used to organize cards into meaningful groups, making it easier for users to focus on a particular area of study.

Anki allows users to create and customize their own decks, which can be shared with others, imported, or exported. Users can study one deck at a time or multiple decks simultaneously, depending on their learning goals and preferences.

Anki Packages

An Anki package is a single file containing one or more decks, along with their associated cards, models, media files, and other related data. Anki packages have the file extension ".apkg" and can be easily shared, imported, or exported between users and devices.

Anki packages are a convenient way to distribute decks and related content, as they bundle all necessary information in a single file. When importing an Anki package, the decks, cards, and models it contains are added to the user's existing collection.

How to Use ChatGPT as a Study Aid

You can think of ChatGPT like a humanoid Google. It won't do the work for you and it certainly won't do the thinking for you. But if you know how to phrase your questions, it can give you some pretty good answers, and in the format you would like them to be. This makes inserting these answers in a program that much easier.

In this example, I'm going to ask a question regarding the Linux filesystem. I expect the answer to be a list of the directories accessible from the root folder, with an explanation of why they are there. If it doesn't give you the answer you want, remember to be more specific.

This is a partial screenshot – the answer goes all the way to 14, the /var directory used to store fluid data files that are supposed to change during a system use session, and the last one in alphabetical order.

So far, so good. But if we want to insert this information into a program, we need to have it formatted. This is an area where Chat GPT shines.

If you receive, say, a paragraph as an answer, you can just ask the robot to rephrase it as an ordered list. Then you can ask it to send each item as an array of tuples, for instance. Here's an example based on the last answer:

Remember to always review the answers before uploading them to Anki, as you'll hammer the returned information into your brain. You don't want to sabotage your learning during your studies.

This is enough for now, let's get to coding.

How to Install Genanki

To get started, you'll need to install the genanki library, which is a Python library for creating Anki decks and cards programmatically. You can install it using pip:

pip install genanki

How to Create Anki Cards and Decks

Now that we have the genanki library installed, let's create a Python script that generates the Anki cards and deck for Linux filesystem directories.

Preparations

Here we'll import the library and paste in the ChatGPT answer. It will be used as a parameter to the functions provided by genanki.

import genanki

# List of Linux directories and their descriptions
linux_dirs = [
    ('/', 'Root directory, starting point of the filesystem hierarchy.'),
    ('/bin', 'Contains essential system command executables.'),
    ('/sbin', 'Contains essential system administration command executables.'),
    ('/boot', 'Contains files needed to start the boot process.'),
    ('/etc', "Contains system-wide configuration files and scripts."),
    ('/dev', 'Contains device files representing hardware devices.'),
    ('/home', 'Contains personal directories for each user.'),
    ('/lib', 'Contains shared libraries and kernel modules.'),
    ('/opt', 'Optional directory for storing third-party software.'),
    ('/proc', 'Virtual filesystem providing an interface to kernel internal data structures.'),
    ('/sys', 'Virtual filesystem providing an interface to kernel internal data structures for devices, drivers, and other components.'),
    ('/tmp', 'Temporary directory for storing files deleted after a system reboot.'),
    ('/usr', 'Contains user-related files, shared libraries, header files, documentation, and non-essential software binaries.'),
    ('/var', 'Contains variable data files, such as logs, databases, and mail spools.'),
]

Here we have to generate a model ID for the cards we are creating, which has to be unique. You will also have to give a name to your model, create fields to be populated by content, and then declare a template for your note using these fields.

Remember that a note is basically a form for cards associated with that note. We will have two cards for each note, since the directory name is a memory trigger for the directory description and vice-versa.

# Define Anki note model
model_id = 1607392319
model = genanki.Model(
    model_id,
    'Linux filesystem folders',
    fields=[
        {'name': 'Directory'},
        {'name': 'Description'},
    ],
    templates=[
        {
            'name': 'Card 1',
            'qfmt': '{{Directory}}',
            'afmt': '{{Description}}',
        },
        {
            'name': 'Card 2',
            'qfmt': '{{Description}}',
            'afmt': '{{Directory}}',
        },
    ])

We'll finally create the deck and give it an ID (which, you guessed it, must be unique) and also give it a name. We will then iterate through our list of tuples and create a note for each tuple, declaring the note's model and inputting our content as fields ('Directory' and 'Description' respectively).

We'll finally write a package containing our single deck. If you have an Anki installation, just double click on the generated file and it should open in the program, ready for studying.

# Generate Anki cards and add them to a deck
deck_id = 2059400110
deck = genanki.Deck(deck_id, 'Linux Filesystem')

for dir_name, description in linux_dirs:
    note = genanki.Note(model=model, fields=[dir_name, description])
    deck.add_note(note)

# Save the deck to an Anki package (*.apkg) file
genanki.Package(deck).write_to_file('linux_filesystem.apkg')

Full Script

import genanki

# List of Linux directories and their descriptions
linux_dirs = [
    ('/', 'Root directory, starting point of the filesystem hierarchy.'),
    ('/bin', 'Contains essential system command executables.'),
    ('/sbin', 'Contains essential system administration command executables.'),
    ('/boot', 'Contains files needed to start the boot process.'),
    ('/etc', "Contains system-wide configuration files and scripts."),
    ('/dev', 'Contains device files representing hardware devices.'),
    ('/home', 'Contains personal directories for each user.'),
    ('/lib', 'Contains shared libraries and kernel modules.'),
    ('/opt', 'Optional directory for storing third-party software.'),
    ('/proc', 'Virtual filesystem providing an interface to kernel internal data structures.'),
    ('/sys', 'Virtual filesystem providing an interface to kernel internal data structures for devices, drivers, and other components.'),
    ('/tmp', 'Temporary directory for storing files deleted after a system reboot.'),
    ('/usr', 'Contains user-related files, shared libraries, header files, documentation, and non-essential software binaries.'),
    ('/var', 'Contains variable data files, such as logs, databases, and mail spools.'),
]

# Define Anki note model
model_id = 1607392319
model = genanki.Model(
    model_id,
    'Simple Model',
    fields=[
        {'name': 'Directory'},
        {'name': 'Description'},
    ],
    templates=[
        {
            'name': 'Card 1',
            'qfmt': '{{Directory}}',
            'afmt': '{{Description}}',
        },
        {
            'name': 'Card 2',
            'qfmt': '{{Description}}',
            'afmt': '{{Directory}}',
        },
    ])

# Generate Anki cards and add them to a deck
deck_id = 2059400110
deck = genanki.Deck(deck_id, 'Linux Filesystem')

for dir_name, description in linux_dirs:
    note = genanki.Note(model=model, fields=[dir_name, description])
    deck.add_note(note)

# Save the deck to an Anki package (*.apkg) file
genanki.Package(deck).write_to_file('linux_filesystem.apkg')

Limitations of this Method

This script is pretty good, and I use it very often – but let's not pretend it is perfect. You will have to generate the deck every time you want to add stuff programatically.

You can also get the Deck ID and generate more cards to a new package with the same ID and add them, but this can lead to errors if you are not careful.

Also, the input method is currently an array of tuples. You will have to edit the script every time to update the array with a new deck.

You could also copy and paste it to a text file and read the input from there. And you could also randomly generate a model ID so you can just paste the card contents to your text file and have the package generate from a single script run. This is somewhat subjective so I left it out on purpose.

Conclusion

Anki has many types of cards, the main ones being the basic (memory trigger + answer) and cloze (one or more memory triggers embedded in an outline). This example uses the basic and reversed card, because both the 'question' and 'answer' can be a memory trigger for each other. If you want a simple, basic card you should consult the example at Genanki's README.

I hope this script serves as at least a starting point for your own applications of programmable Anki. It is probably my main study method nowadays, and it got a whole lot more powerful after ChatGPT. Have fun with your coding.

Over the last couple years, I've learned that being a consultant means you have to be able to learn new things quickly.

At first, this was really scary to me. Now, as someone who has had to learn several new tech stacks over the last year, it’s still a little scary to me. But I’ve also learned several strategies about how to learn things effectively. And that's what we'll cover here.

Learn the Framework's Supporting Language

Frameworks are written to speed up development in specific languages. Many times, engineers who are learning a new tech stack on a fast paced project will learn the framework before they really learn or understand the language that it’s built for. It makes sense, though, because if you can learn the framework and a little bit of syntax you can usually start operating in the codebase faster.

When you have deadlines approaching and you need to get stuff out the door quickly, the tendency is to learn exactly what you need to deliver. “What exactly you need to deliver” is probably open to interpretation and existential debates, but in general, it seems that when engineers figure out the framework they can write enough code to get the thing working.

You will quickly hit a ceiling with this approach, though. I realized this when learning Ruby on Rails. I “learned” Rails before I really learned Ruby.

Ruby is pretty different from other languages I had operated in before, but because I could find the patterns in the framework I was able to operate in Ruby on Rails ok for a while. Until I couldn't.

When it came to really understanding Rails so I could get more creative in how I used the framework to fit non-basic needs, I realized that if I didn't know Ruby then I didn't know Rails. Without understanding Ruby, I couldn’t follow the source code to really understand how Rails was built.

In order to learn Ruby, I got a book and started reading. Things started clicking that hadn’t before, and I quickly moved from just being able to “operate” in Rails to actually understanding the parts of Rails I was in.

I could read and follow the source code because I could read the language it was written in. This meant I could solve less standard problems in clean and effective ways.

Read the Docs

Recent framework and library documentation seems to generally be pretty well-written. There’s great descriptions of the things that you can do and then code examples of how to do it. Why would you not want to read that?

Well, it may be because we all have 40 hours in our week that get filled with meetings, code, bugs, failing tests, random machine restarts, deadlines, weird system behavior, and so on.

It also could be because when we read documentation it doesn’t seem to stick as much as we might hope. We don’t read it and then feel like we can teach it. And after one pass we usually don’t feel like we know everything to write the code we need to deliver by next week.

But reading the documentation will let you know the things that you can do with the framework. You won’t absorb it all and come out an expert, but you can go back to the code you are supposed to write and have some idea of how you might accomplish your task.

You will likely get stuck again (even though you just read about that thing) and you will go back to the docs again. Then you will read them again, but this time focused on a particular section and you will read them more slowly. You’ll think through each sentence this time and let it sink in.

Then you’ll go back to your code and know everything! Just kidding. You might still be stuck, but you will try a few things, and then maybe read that one section one more time. And then it will click. It will work. The documentation was right, you CAN do that thing it promised :) And next time you have to do that thing it will seem easy.

If you don't read the docs, you'll develop the tendency to hack at the thing until it works. You will model your patterns not off the patterns that the framework has built and established but rather the patterns that you know from previous experience in other things you think are similar.

Instead of using the framework to your advantage, you are making more work for yourself (and likely a bigger mess) than if you had never used it at all.

Don’t Pretend You Get It

If you happen to be lucky enough to get to work with an expert in the framework, don’t ever pretend that you understand things you don’t. This expert probably doesn't have an infinite amount of time to answer your questions, but don’t let yourself settle for “I think it makes sense” if it doesn't.

With a limited amount of their time, I recommend you take notes on the things that they say and listen as carefully as possible. Re-explain back to them the things that they explain to you and try not to get too shaken up when you ask “Is that right?” and they respond “no”. It’s better to know that you don’t know right then, rather than wasting time thinking the thing works only to have it not work when you need it the most.

If you don’t have time to re-explain ideas or concepts back, take their recommendations and capture the key words from the things they proposed. Then you should read at greater length about those topics and ideas. Finally, take what you read, the problem that you had, and the things they said and see if you can succinctly summarize the problem and the solution and why you landed on that solution.

If you feel comfortable, and your explanation is indeed succinct, send that explanation in a message to them asking them to confirm your understanding. I’ve yet to find a person who doesn’t receive that well enough to at least respond “yes you got it” or “no not quite”.

If you aren’t lucky enough to have the expert, have the same resistance to “just sort of getting it” as you read about the framework or look through the source code. You won’t be able to ask someone “Is that right?” but you can still check your understanding.

Find the Debugger and the REPL

If you can figure out how to run the application and set a breakpoint, you have just set yourself up to be able to learn so much more so much faster!

Breakpoints let you stop the flow of execution in what you think is the flow of the application. If you want to validate that a function is getting hit, and that its input is equal to a certain value on a certain iteration, setting a breakpoint in the function can tell you if you things are flowing the way you expect. Breakpoints let you run the code one line at a time and inspect the outputs so that you can understand each step.

Print statements aren’t as good, but can suffice if you need them. Breakpoints will change your life in the best way and it’s really important you figure out how to get a hold of them.

REPL’s are also your friend. REPL stands for Read-Eval-Print Loop. These are small environments set up to run commands in the language or framework that you are working in.

I used this a lot when I was learning list comprehensions in Python. I could run a simple example to assess my understanding that looked something like this:

> my_list = [1, 3, 5]
> doubled_values = [ num*2 for num in my_list ]
> print(doubled_values)
> [2, 6, 10]

If what you are trying to test requires a lot of data setup a unit test would be better. But if you think you understand how something works but want to check your understanding, it's a great idea to fire up the REPL and build a small example.

Think about what you expect to happen when you run certain commands and then run them to see if what you expected was what ended up happening. If the result was totally unexpected then you essentially just asked “Is that right?” and the computer told you “no”.

Learn How to Test It

This one feels really hard when you are learning a new framework/language because the test framework is yet again different and new. But if you can write good tests for the thing you are trying to deliver, then you can fumble through the implementation and feel confident that you are still getting what you need.

Tests are especially helpful when operating a new tech stack because you will not write your code the best way the first time (this is probably always true but definitely true in new frameworks). You will want to give yourself space to rework things and refactor as you go.

Solid tests will allow you that flexibility. They will give you more space to try things, break things, and fix things while you get yourself more comfortable in the code.

And Repeat

I’ve wished a million and two times that “I knew it all by now”. Because every single step above will likely make you feel uncomfortable. You may go through all of the above steps and learn how to do one thing in the framework really well. The next time you have to do it you won’t even think about it. You’ll just do it.

And then you will need to do the next thing. And then you will have learned enough things that you get by for a while feeling pretty good. Until you hit the next thing you have to learn and you need to feel uncomfortable again. And it will happen again and again and again for a really long time (or maybe forever? I haven’t reached the end yet).

But each time it seems to feel a little easier and a little quicker to get to the information you need. It used to take you several days to get one small thing working and now it takes you half a day. But you were so busy learning and delivering that you forgot that it used to take you 4 days to do what you can now do in 4 hours.

So the last, and perhaps most important, thing in learning new tech stacks (and learning new anything) is to remember where you started. It’s easy for the sea of things to learn to feel infinite. It’ll feel like you’re never making progress unless you look backwards. You’ll remember how far you’ve come and you’ll feel like you can keep moving forward doing more.

Slowly you will realize that you can enter unknown situations and feel confident that you can build not only a solution but the best solution. And this feeling is worth the hours you poured over the docs and banged your head against the wall on things that wouldn’t work. You can build amazing things and that’s so awesome!

As you get closer to that version of you that can build anything, remember to thank the co-workers or friends who have taught you and cheered you on as you learned. You wouldn’t be building these things without them.

And as you continue, you’ll start teaching others. And when they ask you “Is that right?” you will kindly respond “no” and re-explain it in all its complexities just one more time. 🙂

Starting out on a new career path or picking up a new skill is an exciting and ambitious endeavour. But maintaining consistency can be a challenge. It's easy to get lost in the excitement of setting goals and creating strategies, but staying on track when no one is watching can be a daunting task.

That's why I have put together this article to help you stay consistent in your tech pursuits. Whether you're striving to become a web developer, a Python expert, or a graphic designer, these actionable tips will help you stay motivated and focused on achieving your goals.

So, let's dive in and explore how you can remain consistent in your tech journey.

1. Sharpen Your Skills by Helping Others

One of the most fulfilling ways to improve your skills is by helping others who are on the same journey as you.

Not only does it give you a sense of satisfaction and fulfillment, but it also helps you consolidate your own knowledge and become a better problem solver. You can mentor someone who is just starting out or share your expertise with others who have similar goals.

For instance, if you are learning web development, you can help a friend or colleague who is struggling with HTML or CSS. Or, if you are studying Python programming, you can volunteer to tutor a high school student who is just beginning to learn the language.

Sharing your knowledge and expertise can also help you build a network of peers and mentors who can support you throughout your career. By helping others, you can not only improve your skills, but also create a sense of community and belonging in the tech industry.

2. Talk About Your Work

Sharing your experiences and talking about what you do is another great way to stay motivated and enjoy the learning process. When you talk about your work, you not only sharpen your communication skills but also get valuable feedback and insights from others.

One way to do this is through writing. Whether it's starting a blog or writing about your experiences in a journal, putting your thoughts and ideas into words can help you reflect on your progress and solidify your knowledge. Plus, the act of researching and organising your thoughts can help you learn even more.

Another way to talk about your work is by sharing your accomplishments with friends who are supportive and encouraging. When you complete a cool project or reach a milestone, don't be afraid to share it with those who will motivate and inspire you to keep going.

For example, if you're working on a web development project, you can share your progress and ask for feedback from your peers, or post your work on a community forum. This not only helps you stay accountable but also gives you an opportunity to learn from others and build valuable connections in the industry. By talking about what you do, you can enjoy the journey and remain consistent in your tech pursuits.

Talking about what you do helps you stay accountable, learn from others, and build valuable connections in your field.

3. Build Real Projects

Learning by practise is one of the most effective ways to improve your skills and stay consistent in your tech pursuits. Building real projects as you learn can help you solidify your knowledge and apply what you've learned in a practical way.

To get started, try recreating tutorial examples or coding challenges. For example, if you're learning how to use the useReducer hook in React, you can start by re-creating the example you see in the documentation or in an online tutorial. This will not only help you understand the concept better, but also challenge your problem-solving skills and keep the lessons fresh in your mind.

Another way to enjoy your learning process is by building real projects that either showcase your skills for your portfolio or benefit other users. This can be anything from creating a simple website or app to contributing to an open-source project. The key is to focus on building things as you learn, rather than just passively consuming information.

For instance, if you're interested in web development, you can start by building a simple personal website or a blog using HTML, CSS, and JavaScript. As you progress, you can add more features and functionalities to make it more advanced. By building real projects, you not only get hands-on experience but also gain valuable portfolio pieces that can help you stand out to potential employers.

4. Network and Make New Friends

Networking and making new friends are crucial parts of growth in any field, including tech. But it's important to be intentional about the kind of connections you make. Instead of just making friends with anyone, try to connect with experts and mentors who can help you grow and learn.

One way to do this is to be active on social media. Follow them on social media platforms like Twitter and LinkedIn, and engage with their content by commenting and sharing your thoughts. Attend online events like webinars, conferences, and Twitter spaces where they're speaking or participating.

By being active in their social circles, you'll have more opportunities to interact with them and learn from their experiences.

When you network with experts and mentors, you have the opportunity to remain motivated and inspired in your learning journey. They can offer valuable advice and feedback, introduce you to new tools and resources, and even provide job opportunities. By building lasting relationships with like-minded individuals, you can enjoy the process of learning and stay consistent in your tech pursuits.

5. Set Realistic Goals

Setting realistic goals is essential for anyone starting out in any field. It's easy to get excited about the possibilities of what you can achieve, but it's important to set goals that are challenging yet achievable.

When setting goals, make sure they are specific, measurable, attainable, relevant, and time-bound. This means that your goals should be clear, have defined metrics for success, and be realistic given your current abilities and resources. Additionally, your goals should be relevant to your overall career objectives and have a specific timeline for completion.

For example, if your goal is to become a proficient Python programmer, a realistic goal might be to complete an online course on Python within the next three months rather than aiming to become an expert in a week.

As you achieve your goals, set new ones that continue to challenge you but remain within your abilities.

Setting realistic goals can help you remain consistent in your tech journey by providing a roadmap for your learning and progress. When you achieve your goals, you gain a sense of accomplishment and motivation to keep going. But be prepared to adjust your goals if you encounter unexpected challenges or if your priorities change.

6. Learn One Thing at a Time

Learning one thing at a time can be a powerful way to remain consistent in tech. It can be tempting to try to learn everything at once, especially when you are excited about a new career or skill. But this can quickly become overwhelming and may cause you to lose motivation.

To avoid this, it is important to set realistic goals and focus on one thing at a time. This means breaking down larger concepts into smaller, more manageable pieces.

For example, if you are learning a new programming language, start with the basics, such as syntax and data types, before moving on to more advanced topics like algorithms and data structures.

Learning one thing at a time not only helps you avoid feeling overwhelmed, but it also allows you to fully understand and master each concept before moving on to the next. This can help build your confidence and motivation as you see yourself making progress.

7. Listen to Podcasts

Yes, it's true – listening to podcasts can be a great way to enjoy the learning process and remain consistent with your goals. You can find podcasts that are specific to your interests and learn from experts in your field. This is an excellent way to stay motivated, especially during times when you may feel stuck or uninspired.

Podcasts also allow you to hear about the experiences of others, which can help you avoid common mistakes and gain insights into how to achieve success in your field. You can listen to podcasts while you work, exercise, or commute, which makes it a convenient way to learn while you go about your daily activities.

The world of tech has a plethora of informative and engaging podcasts to choose from. One such podcast is the "No Degree Podcast," which is aimed at individuals who do not have a college degree but are looking to explore opportunities in the tech industry. This podcast provides career guidance, advice, and insights from successful people who do not hold a college degree.

Other popular tech podcasts include "CodeNewbie," which focuses on inspiring people who are just starting out in the world of programming. "Software Engineering Daily" is another informative podcast that covers a wide range of topics related to software engineering. And the list goes on and on.

Thank you for reading!

Did you find this article helpful? Follow me on Twitter at @ttebify for more tech discussions and resources. Let's connect and stay motivated!

To make sense of CSS pseudo-classes, we need to understand state. In this context, the word state means a situation or condition that something is in at a particular point in time.

Take the state of a stoplight, for example. At any point in time it has one of three states:

• Red state: Stop
• Yellow state: Accelerate ... oh no! ... it's caution
• And green state: Go

When we talk about the "state of the stoplight", we're referring to one of these three possibilities.

How is state related to pseudo-classes? Let's look at an example.

Figure 1. Default link styles

On the web page in Figure 1, notice that the links to GitHub and LinkedIn are currently blue and underlined. Mouse down on a link and you see that it turns red as shown in Figure 2.

Figure 2. Default link active style

Click on the link, and it turns purple as you can see in Figure 3.

Figure 3. Default link visited style

We add links to an HTML page using anchor elements, denoted with an "a".

<a href="http://www.github.com">GitHub</a>
<a href="#">LinkedIn</a>

As you saw in the figures, by default the anchor element has multiple states: blue when it's not yet clicked, red when it's active, and purple when it has been clicked.

If we simply style an anchor element, using a CSS element selector as shown below, the link won't have any of that additional coloring for the different states.

a {
  color: darkslategray;
}

How do we style these anchor states? You guessed it! With pseudo-classes. Let's examine what pseudo-classes are and walk through two examples. You can view the associated video here:

What Is a Pseudo-class?

A CSS pseudo-class is a fancy name for a keyword added to a CSS selector that identifies the HTML element's state. We can then style the element when it is in that particular state.

To add a pseudo-class to a selector, add a colon and the pseudo-class name:

a:active {
  color:orange;
}

The a:active adds the active pseudo-class to the anchor element selector. We can then style the anchor link to look a certain way when it's in its active state.

Let's look at two examples using pseudo-classes.

How to Style Anchor States

An anchor element has four states:

• link: when the link has not yet been clicked.
• visited: when the link has been clicked (clicking a link "visits" that linked page, hence the name "visited").
• hover: When the mouse is hovered over the link.
• active: for the moment the mouse is clicked down on the link

We style these states using pseudo-classes. In the below example, we specify the "a" (or anchor) element selector, a colon, and the name of the anchor state.

a:link {
  color: slategray;
}
a:visited {
  color: darkslategray;
}
a:hover {
  color: yellow;
}
a:active {
  color:orange;
}

It's recommended that you declare these pseudo-classes in the stylesheet in this order because of the CSS precedence rules. Find more information about CSS precedence rules here. In short, styles declared later override those declared earlier. For the anchor element, we want the active state to take precedence, which is why it's last.

Use these states as needed when you style your anchors.

To see these states in action and try your own custom styles, check out this project.

Now let's look at another type of HTML element, the input element checkbox.

How to Style a Checkbox Checked State

Here we have a checkbox for "Add me to your mailing list". It's currently in an "unchecked" state.

Figure 4. Default checkbox

Here is the same checkbox in the "checked" state with default styling. We want to style the "checked" state to add our own custom look.

Figure 5. Default checkbox checked style

Let's say we want to change the background color, maybe the blue clashes with our design. And we want to change the border by removing the existing border and adding our own outline color. Like this:

HTML

<input type="checkbox" id="mailing-list">
<label for="mailing-list">Add me to your mailing list</label>

CSS

#mailing-list:checked {
  border: none;
  accent-color: white;
  outline: 2px solid  orange;
}

Here we use a CSS id selector and a pseudo-class to style a checkbox's checked state. We remove the border, set the background color (called accent-color), and provide our own orange outline.

The resulting checked state looks like this:

Figure 6. Custom checkbox checked style

Use this technique to give your webpages a custom look.

To see these states in action and try your own custom styles, check out this project.

Wrapping Up

A pseudo-class is a keyword added to a selector that styles an element's state. We saw how to add pseudo-classes for anchor element states and for the checked state of a checkbox.

Many other HTML elements also have states, and we can style those states using pseudo-classes. For a list of these pseudo-classes, see the Mozilla Developer Network (MDN) Web Docs.

For more information on styling with CSS, check out my course: "Gentle Introduction to CSS for Beginners" and subscribe to my YouTube channel.

Green light ... go! Now let's go out there and style our element states.

Functions are a fundamental building block of programming. They help us organize our code into manageable and reusable pieces.

Let's explore the basics of functions by way of a burger joint.

A burger joint may seem like an odd place to learn about code organization...but let's see where this goes. And you can view the associated video here.

Are you hungry for some knowledge? Or maybe a burger?

Tackling any large set of tasks requires some amount of organization. Say we work at a burger restaurant. We could define a simplified view of the process as shown below:

1. Take a customer's order
2. If the customer ordered fries, make fries:
   • Dump fries into the fryer
   • Set a timer
   • Etc.
3. If the customer ordered a burger, make the burger:
   • Select the appropriate type of patty (veggie, chicken, fish, beef)
   • Fry the burger
   • Toast the bun
   • Etc.
4. Put the items in a box
5. Repeat at step 1

A worker takes a customer's order. If the customer ordered fries, they make fries. Notice the "sub-list" describing how to make the fries. And if the customer ordered a burger, they make the burger. And there's another "sub-list" describing how to make the burger.

To keep our main list of instructions straightforward and easier to follow, we can move these sub-lists to separate sets of instructions.

Figure 1. Defining functions

The left side of Figure 1 shows the list of steps for making fries, and the list for making a burger. We reference those instructions in the main flow, as shown on the right side of Figure 1.

The result is that each separate list of instructions is clearly defined. And the main flow on the right is easier to see without all of the sub-lists.

In programming, we call each of these self-contained sets of instructions a function.

Let's stop at this point and think about this. What are some benefits of breaking out some of the instructions into functions? Thoughts?

Separating our code into functions has several advantages:

• When building or maintaining the function, we can focus just on that function: what information it needs, what steps it performs, and what result it provides.
• We can simplify the main set of instructions, making it easier to read and maintain over time.
• It helps us separate work for a team, assigning each independent function to a member of the team. Jesse can be making fries, Chris making the burgers, and Sandhya follows the main flow, taking orders.
• And we can more easily reuse the function in multiple places in the application.

Did you think of other benefits?

What Is a Function?

In programming:

• A function is a self-contained set of instructions to accomplish a chunk of a larger task.
• A function separates responsibilities for a specific part of a task, making the main task easier to work with and read.
• Functions add structure to our programs, and make them easier to read and modify over time.

Here is a tip: Code is often read much more often than it's written, so make your code readable.

Anatomy of a Function

When writing code, functions look something like this:

Make Fries

function makeFries(fries) {
  ... instructions go here ...
  return cookedFries
}

Make a Burger

function makeBurger(patty, bun, condiments) {
  ... instructions go here ...
  return cookedBurger
}

Note that the details of the functions may look a bit different depending on the programming language you use.

A function often takes in some information, performs the set of instructions using that information, and gives back (or "returns") a result. At the burger joint we can say: "Hey Chris, here is a patty, bun, and condiments, go make the burger, and bring it back to me when it's done."

Functions are often named with the task they perform following a verbObject style naming convention: makeFries and makeBurger.

The name is followed by a list of the information that the function needs. In this example, this information is enclosed in parenthesis and separated with commas. For our makeFries, we need the fries. And for the burger, we need a patty, bun, and condiments.

The function body contains the set of instructions required for this function.

In many cases, a function performs its set of steps and returns a result. So lastly, we return that result. The result is often indicated with a return statement. In this example, when the fries are made or the burger is done, we pass them back to the main flow and they are boxed for the customer.

How to Create a Function

Let's look at another example from a simple virtual pet adoption website as shown in Figure 2.

Figure 2. Virtual pet adoption website

The user enters the type and number of pets, and clicks Adopt. The application then displays a message and a greeting from each of the virtually adopted pets.

When writing the code for this website, we want to simplify the main set of instructions by separating out the feature that prepares the pet greeting. We define a function for those instructions like this:

function prepareGreeting(typeOfPet, numberOfPets) { 
  var greeting = '';
  for (let i = 0; i < numberOfPets; i++) {
    if (typeOfPet === 'cat') { 
      greeting += 'meow' + '<br/>';
    }
    if (typeOfPet === 'dog') { 
      greeting += 'woof' + '<br/>';
    }
  }
  return greeting;
}

This function is named "prepareGreeting" following our verbObject convention. It's best practice to give every function a meaningful name.

For a function to perform its set of instructions, it often needs some information. In this case, it needs the type of pet and the number of pets. When creating a function, we identify that needed information using parameters.

A parameter is a placeholder for the information the function needs. We give each placeholder a descriptive name, such as typeOfPet and numberOfPets. We add the parameters after the function name, often within parentheses and separated with commas.

The function name with its set of parameters is called a function signature. The function signature uniquely identifies the function.

The function body is where we write the code to perform the set of instructions. In this example, it's where we prepare the greeting.

In programming languages that use curly braces, the function body is defined between the first and last curly brace. In some languages, the function body is defined simply by its indentation.

In this function body, we prepare the pet's greeting. First, we initialize a greeting variable to an empty string. This ensures that we have a string (or text) variable we can use for the greeting text.

Then we loop for each pet. We use a counter represented by "i", repeat the loop while our counter is less than the total number of pets, and increment "i" at the end of each loop. Notice that in most programming languages, counting is zero-based, meaning it counts the iterations of the loop starting at 0: 0, 1, 2 for three pets.

Within the loop, if the passed-in pet type is a cat, we add a "meow" for each pet to the greeting variable. If the passed in pet type is a dog, we append "woof" for each pet. We then return that resulting greeting to the main set of instructions.

How to Call a Function

Code in a function won't do anything until we call that function from some other code, such as our main set of instructions. The exact syntax for calling a function depends on the programming language you use. But it will look something like this:

greetingForDisplay = prepareGreeting("cat", 3)

We use the name of the function to identify which function we want to call. Then pass a value in for each parameter placeholder. In this example, we pass in a string (or text) using quotation marks and a number.

The result of the function's instructions are returned to the code that called it. In this example, the value is assigned to the greetingForDisplay variable. The main code could then display the contents of this variable to the user.

When working with functions, be sure to keep these two terms clear:

• Parameter: The placeholder in the function signature where we define what kind of information the function needs.
• Argument: The value(s) passed in when calling the function, giving the function the information it needs to perform its instructions

Wrapping Up

We use a function to define a self-contained set of instructions for a chunk of a larger task. Using functions helps break up long code into manageable pieces. Just like building blocks, we combine functions to create simple to complex applications and websites.

For more information on general programming concepts, check out my course: "Gentle Introduction to Programming for Beginners". And for information on web development, GitHub, Angular, and C#, subscribe to my YouTube channel.

Now, let's go order that burger!

As someone who doesn’t have a computer science degree and was looking to learn the fundamentals of the field, I was in the same boat. That's why I decided to enrol on the course and document my experience in this article.

I'll provide an overview and review of CS50 to help you decide if it's the right course for you.

What is CS50?

CS50 is a ten week online and on-campus course which serves as an introduction to computer science. It's taught at Harvard and Yale University.

The course leader is Professor David J. Malan. He’s supported by the CS50 team, which consists of Senior Preceptors and an entire production team. The course runs from 1 January to 31 December.

Why choose CS50?

There are several reasons why CS50 might be a good choice for you. Here are a few:

• It's a highly respected course offered by Harvard University. This means that you'll be learning from experienced instructors and getting access to a top-quality course.

• It covers a wide range of topics, including computer science fundamentals, algorithms, data structures, and programming languages such as C, Python, and SQL. This means that you'll have a well-rounded introduction to the field.

• It's self-paced, which means that you can work through the course at your own pace and fit it into your schedule. You can watch the lectures on various platforms, including EdX and freeCodeCamp's YouTube channel. For me this was important as I didn’t have a lot of spare time.

• It's free! You’ll have access to the lectures and course materials.

What is the Format of the Course?

There are ten weeks worth of lectures, labs, and problem sets, which must be completed. At the end of the course, there’s a final project.

Is this a course for beginners?

Yes. In fact, around two thirds of students who enroll in CS50 have never taken a computer science course before. So if you're new to the field and looking to learn the basics, you'll be in good company.

That being said, don't expect the course to be easy. While the lectures are designed to be accessible and engaging, the problem sets and labs can be challenging. On average, students should expect to spend around 12 hours per week on the course.

Do I get a certificate at the end of the course?

You can choose to receive a free CS50 certificate or pay for a verified certificate from edX.

What if you don’t finish the course by 31 December?

You can roll over any submissions into the following year. I did this and the process was straightforward. The course content is pretty much the same with some updates to the course materials.

CS50 Walkthrough, Week by Week

Week 0: Learn Scratch

In the first week of the course, you'll be introduced to the world of computer science and learn about how numbers, text, and images are represented in binary.

You'll also learn about algorithms and pseudo code, and get a hands-on introduction to Scratch, a graphical programming language.

For your first problem set, you'll create a Scratch project. This week is a fun way to ease you into the course and get a taste of programming.

If you’re interested, this is my Scratch project, which was inspired by my son who’s fascinated by space.

Week 1: Learn C

In the second week of the course, you'll dive into C, a low-level programming language.

You'll learn programming fundamentals such as functions, conditionals, boolean expressions, loops, and variables.

For the problem set, you'll create a program that outputs a pyramid of hashes like at the end of a level in a Super Mario game.

Week 2: Introduction to Arrays

You'll continue learning about programming in C and delve into topics such as how your program compiles, debugging, arrays, characters, strings, and command-line arguments.

For the lab, you'll write a Caesar's cipher program, and for the problem set, you'll work on a scrabble-type challenge. If you’ve completed the JavaScript Algorithm and Data Structures certificate on freeCodeCamp, this should be familiar as this is one of the coding challenges.

Week 3: Introduction to Algorithms

In week three, you'll learn about different types of search (linear and binary) and different types of sort (selection and bubble), as well as recursion.

You'll also learn about big O notation, which can be challenging but is an important concept in computer science. Thankfully, the course provides additional short videos on more difficult concepts, which provide a more detailed explanation with examples.

Week 4: Computer Memory

Week four focuses on memory, including topics such as pointers, addresses, memory allocation and freeing memory, detecting memory leaks, and explaining how a stack overflow occurs.

The lab and problem set involve manipulating audio and image files. Below is an example of a filter I created in C.

Week 5: Data Structures

In the final week of programming in C, you'll learn about how pointers can be used to store the addresses in memory for linked lists.

The lab consolidates your knowledge of pointers, and the problem set involves creating a spell checking program. This was a particularly tricky exercise and it’s worth taking your time to understand the starter files provided before delving in.

Week 6: Learn Python Basics

Week six marks the transition from C to Python, a popular programming language that is easier to learn and use than C. You'll work on problem sets that involve translating previous programs written in C to Python.

Week 7: SQL and Relational Databases

In week seven, you'll learn about relational databases and SQL (Structured Query Language), using SQLite to execute queries on the command line and in Python.

The problem set is a fun one, as you’ll have to solve a mystery of who stole the CS50 duck through a series of SQL queries!

Week 8: HTML, CSS, and JavaScript

Week eight covers the basics of the internet and the web, including HTML, CSS, and JavaScript on the client side.

For the problem set you’ll create a home page about yourself.

Week 9: Flask

In week nine, you'll learn about Flask, a Python framework that is used to build web applications. You'll cover topics such as forms, layouts and templating using Jinja, POST and GET requests, and how to email from a Flask application. You'll also walk through the process of building a full-stack application.

For the problem set, you'll put your skills to the test by implementing a full-stack finance application that brings together everything you've learned throughout the course. This is a challenging but rewarding project that will give you a taste of what it's like to build a real-world web application.

Week 10: Wrap up lecture

No exercises this week. There’s a guest lecturer and a wrap up from Prof Malan.

The final project

The last part of the course is the final project. The brief is to:

“build something of interest to you, that you solve an actual problem, that you impact your community, or that you change the world.”

This is deliberately vague, so you have the freedom to choose any programming language and project you like. You'll also have to record a three minute video demoing your app.

I built a baby tracking app. On the backend I developed a REST API with Python and Flask. For my database I used SQLite. On the client side, I used React.js.

This is a substantial piece of work. From conception, to designing my application through to developing the app, I probably spent over 30 hours on this.

Your final project would make a great addition to your personal portfolio so have fun with it! Below are some screenshots of my application.

What Are the Benefits of Taking CS50?

• The lectures are high quality, in terms of content and production. Professor Malan is animated, enthusiastic, and is very passionate about teaching computer science and programming. The visual examples on the stage and on the interactive screens are helpful for understanding difficult concepts.

• The problem sets are well-structured and provide detailed walkthrough videos, specifications, and starter code with comments to help guide you through the tasks. You can also test your code to see if it meets all the requirements before submitting.

• Setting up your integrated development environment (IDE) is straightforward, thanks to a modified version of GitHub Codespaces, which allows you to code in the browser.

• The CS50 library is a helpful resource with great documentation. The library provides functions such as get_string, which prompts a user for a string in the command line interface (CLI). These functions act like training wheels during the early weeks of the course, helping you to focus on familiarising yourself with the programming language.

• For some of the problem sets, there are two options: one for when you're "feeling less comfortable" and one for when you're "feeling more comfortable." This allows you to choose the level of difficulty that is right for you.

• The course is structured in a way that builds on your knowledge from previous lectures and problem sets. You'll start with C, a low-level language, and then move on to how to implement the same things in Python and JavaScript later in the course.

• There is a large and active online CS50 community on various platforms such as Facebook, Twitter, Discord, and LinkedIn, where you can connect with other students and get help with problem sets and labs.

• The course is free and accessible to anyone with a computer and an internet connection.

What are the drawbacks of CS50?

The course is challenging. It can have a steep learning curve. I found I had to do additional reading around subjects I was not familiar/comfortable with.

Most people don't finish the course, but even if you don't complete it, you can still benefit from what you learn. In the words of Prof Malan:

“What ultimately matters in this course is not so much where you end up relative to your classmates but where you end up relative to yourself when you begin.”

Summary

CS50 is a comprehensive and highly respected course that provides a strong foundation in computer science.

As a self-taught frontend developer with no computer science degree, I found that the course was an excellent way to fill in knowledge gaps and strengthen my understanding of the fundamentals of the field.

The lectures are engaging and well-produced, and the problem sets are challenging but provide a valuable opportunity to apply what you've learned.

The course covers a wide range of topics, making it an excellent introduction to computer science. Overall, it is a standout course and one of the best online learning experiences I've had.

I hope you’ve found this article useful and it’s helped you with making the decision on whether to take CS50.

I'm excited to announce the launch of Learn to Code RPG v1.5, a year after the launch of Learn to Code RPG v1. (Fun fact: we're calling it v1.5 instead of v2 because we have grand plans for v2, which we plan to release in early 2023.)

What is Learn to Code RPG?

Learn to Code RPG is an interactive visual novel game where you will teach yourself to code, make friends in the tech industry, and pursue your dream of working as a developer. 🎯

The game features:

• Hours of gameplay 🎮

• Original art and music 🎨

• 1,000+ Computer Science quiz questions 📚

• 50+ achievements you can unlock 🏆

• 6 different endings 👀

• 10+ characters you can make friends with, and an adorable cat 🐱

• Minigames 👾

• A renown system, a money system, and fun items you can buy for your cat and to customize your room 🏠

Learn to Code RPG v1.5 Game Trailer

You can also watch the game trailer below and share the YouTube video with your friends:

You can download the game and play it for free. It's available for PC, Mac, and Linux on itch.io. And on Android from the Google Play Store.

If you'd like to learn more about the game itself and the development process, read on.

We'll walk you through the story, characters, graphics, and code. I'm sure you'll enjoy it. And it may even inspire you to code your own video game.

How LearnToCodeRPG Went From v1 to v1.5

The Team

When Lynn created v1, she was working solo on the game, juggling writing, coding, and some asset creation.

With this release, to give Lynn more time to focus on coding, KayLa took care of the writing. Nielda helped brainstorm features and create art assets.

Want to see a teamwork showcase? Here's one for the item shop. After purchasing furniture from the shop, the player will see the furniture in their room.

• Lynn programmed the shop, the items, and the room customization

• KayLa and Nielda came up with ideas for the items

• KayLa wrote fun flavor text for the items

• Nielda created all the assets – the room and the items – by tracing over 3D assets and applying textures over them

The Learn to Code RPG Main Story

In v1 (or what we call the Prologue), the story started as our protagonist, Lydia, decided to get a job in the tech industry. She needed to learn to code, make friends in the industry, find mentors, tackle technical interviews, and eventually arrive at her goal – a shiny new developer job.

Building from the Prologue story, in v1.5 (or what we call Arc I) Lydia starts working as a full-stack developer. She now needs to interact with her new colleagues on a day-to-day basis and react to events that arise.

She will be faced with all the things a real-world software engineer faces – changes in project requirements, communicating with project managers, learning from senior developers, and so on.

Does this look like a familiar scene from working in tech to you?

Outside of work, Lydia can also go hang out at Hacker Space with friends she made back when she was first learning to code.

At Hacker Space, Lydia might run into old acquaintances who are also looking for a job. She can decide whether or not to give them a referral.

She can also give back to the community by mentoring high school students with their projects.

There is never a shortage of fun things to do at Hacker Space. 😄

The Characters

To give the characters more depth, we brainstormed using the character card format shown below. Here's the character card for Lydia:

Lydia meets many new colleagues in this arc and our character list has been greatly expanded.

When designing the characters, sometimes our artist Noa will experiment with hair color and style variations until we land on a design that we are happy with:

Mala's different designs. Which is your favorite?

Here's also a sneak peek into one of the many characters and their many expressions:

Darius's many faces

Of course, everyone's favorite, Mint the kitty, is still the key emotional support for this story arc. 🐱

The Graphics

Now moving on to other graphics besides character sprite art. Just like in v1, we again created background images by applying a watercolor-like filter to real-world images.

Since a lot of story takes place at the company Lydia is working at, we also tried to find stock images that are coherent in color scheme, like the ones below:

Background images for the company Lydia's working at

The Code

Just like in v1, I used the game engine that I'm most familiar with, the Ren'Py Visual Novel Engine.

During this year of development, a really exciting piece of news for the Ren'Py community is that Ren'Py 8 now supports Python 3. This is exciting to me.

Compared to Python 2.7 (which we used in Ren'Py 7.4 when we developed Learn to Code RPG v1), Python 3 brings in a lot of new features that positively impact our development.

This also means that I had to spend a little time to migrate from Python 2.7 to Python 3 in our project. (It was a small Git commit, trust me 🤓).

Now some exciting stats – Ren'Py's built-in linter is perfect for gathering stats for comparisons between v1 and v1.5:

# v1
Ren'Py 7.4.8.1895 lint report, generated at: Fri Dec 17 22:11:43 2021
Statistics:
The game contains 1,335 dialogue blocks, containing 15,390 words and 85,105 characters, for an average of 11.5 words and 64 characters per block.
The game contains 40 menus, 20 images, and 49 screens.

# v1.5
Ren'Py 8.0.3.22090809 lint report, generated at: Tue Dec 20 19:22:05 2022
Statistics:
The game contains 3,339 dialogue blocks, containing 41,214 words and 220,501
characters, for an average of 12.3 words and 66 characters per block.
The game contains 68 menus, 19 images, and 51 screens.

From the stats we can see that we've nearly tripled the story content. Woohoo! 🤩

Next Steps for LearnToCodeRPG: From v1.5 to v2

Hooray! After a whole year of development, we've taken v1 to new heights and are now presenting you with Learn to Code RPG v1.5.

What's more exciting: we are only just getting started. Just as Quincy always likes to say, the sky is the limit. ✈️

Here are some things you can look forward to in v2, or even sooner, between v1.5 and v2:

• 🌎 Localization: All the text in v1 has been fully translated into Portuguese, and we have an active community working on translating the game into other world languages. You can help too, by starting here.

• 🎭 More story and characters (shhh... we have 10+ characters planned and some drawn already)

• 📚 Expanded bank of quiz questions and spaced repetition to help you learn more efficiently.

• 💻 Auto-update from inside the game so that you can stay up-to-date with the latest bug fixes, features, and storylines.

• ... and more on our holiday wishlists! 🎁

Last but not least, we hope you enjoy playing this game as much as we enjoyed developing it! 🥳

Links

You can find the game on itch.io here:

And here's the GitHub repo with all the code:

If you haven't read about how v1 of the game took shape, here's an article for you:

And here's the official press kit for the game:

If you are interested in building a Visual Novel Game yourself, check out this article of mine:

We hope you enjoy learning what it's like to work in tech by playing the Learn to Code RPG. 🧑‍💻

Coding is one of the most valuable skills to learn today. You can not only build any idea you have and see it come to life, but you can also improve your future.

Knowing how to code increases your chances of getting a higher-paying job.

According to the U.S. Bureau of labor statistics, software engineers earned a median annual salary of $109,020 in 2021.

In addition, the computer programming and software engineering industry is growing fast, and coding jobs are in high demand.

According to the U.S. Bureau of labor statistics, the anticipated change for 2021-2031 is a 25% growth, which is much faster than average.

All the data above sound great, but with hundreds of programming languages available today, choosing the best one to learn can leave you confused, intimidated, or even overwhelmed.

The truth is, there is no one correct answer to the question 'What is the best programming language to learn?'.

The language you choose to learn will depend on many things, such as what you want to build, what projects you want to work on, your individual career goals, the desired path you want to take, or even how much you want to challenge yourself.

In this article, I first explain what programming languages are and go over the differences between programming, scripting, and markup languages.

I also list some of the most popular languages that beginners choose to learn according to the Stack Overflow Developer Survey for 2022.

Here is what we will cover:

1. What are programming languages?
   1. Programming languages vs scripting languages vs markup languages - what's the difference?
2. The most popular programming languages to learn
   1. HTML and CSS
   2. JavaScript
   3. Python
   4. SQL
   5. C++
   6. Java

Let's dive in.

What Are Programming Languages?

Coding involves telling a computer what to do how to do it. You do this by providing it with a sequence of instructions using a language both humans and machines understand.

The machine interprets the instructions and carries them out to achieve a specific result.

Computers do not understand human languages. They only speak binary – a language consisting of 0s and 1s.

In binary, 0 represents off, and 1 represents on.

It makes perfect since that binary is the primary language of all machines since electronic devices have thousands of transistors (or tiny switches) inside them. And the switches turn on or off depending on the flow of electricity.

But coding in binary is time-consuming and very error-prone. So, humans invented computer programming languages that are readable, easier to learn and understand, and much more human-friendly.

Computer programming languages fall into one of two groups: low-level and high-level.

Low-level programming languages have little or no abstraction from the machine's instruction set. Essentially, their instructions are close to the machine's processor's instructions.

Binary code (or machine code) and assembly language are considered low-level programming languages.

High-level programming languages are more human-friendly.

They are similar to human languages and look a lot like English. They offer a shorter, more precise, and less verbose way to create instructions that the computer can understand.

Programming Languages VS Scripting Languages VS Markup Languages - What's the Difference?

At this point, it is worth mentioning that every language fits into a specific category.

There are three categories of languages:

• Programming languages
• Scripting languages
• Markup languages

Programming languages are used for writing logical sets of instructions for computers to execute and solve a problem.

Programming languages are written in a human-readable form but get converted to machine code (binary).

And this conversion happens with the help of a compiler, which fully translates at once all the instructions written in a high-level programming language into something the computer's CPU can easily understand.

Once the instructions are in a machine-readable form, the computer executes them, and they can run on the machine.

Scripting languages go hand in hand with programming languages – you can think of them as a subset or subcategory of programming languages.

The main difference between programming and scripting languages is how each gets compiled.

Scripting languages get intrerpreted rather than compiled.

Scripting languages use an interpreter which translates each instruction, executes it, and then moves on to the next instruction and continues to do the same line by line instead of all at once as a compiler does.

Markup languages are presentational languages and not programming or scripting languages. They are entirely different since they don't involve logical processing.

Markup languages are languages used for defining, describing, and structuring data on a web page. They also lay out and style data on a page.

The Most Popular Programming Languages to Learn

In the following sections, I list some of the most popular languages that beginners choose to learn. I also list their use cases and some resources for you to get started learning them.

HTML and CSS

HTML and CSS are not technically programming languages, but according to the Stack Overflow developer survey for 2022, they rank first as the most popular languages for people learning to code.

HTML and CSS are markup languages, and you use them to create static web pages.

They are two languages you need to learn if you are interested in becoming a frontend developer. You can also learn them alongside JavaScript to add interactivity to the static pages you create.

HTML (which stands for HyperText Markup Language) defines the structure and content of a web page. So, the paragraphs, headings, lists, forms, and links you see on a page, along with their hierarchies, are all HTML code.

And thanks to the latest version of HTML, HTML5, you can embed images, videos, and audio in web pages eliminating the need to use extra plugins like you had to in the past.

CSS (short for Cascading Style Sheets) styles HTML elements. It is responsible for presenting content in a visually appealing way.

CSS code enables all the different colors and fonts. The sizing of elements and how those elements get displayed on the page. The page layout and how items get arranged next to one another.

To learn HTML and CSS, check out the following resources:

• Learn HTML – Beginner's Course
• Learn CSS in this free 6-hour video course
• Learn HTML and CSS with this free 11 hour course
• Learn HTML and CSS in Spanish – Course for Beginners
• Responsive Web Design Certification

JavaScript

According to the Stack Overflow developer survey for 2022, JavaScript has ranked first as the most commonly used programming language for ten consecutive years. And it is the second most popular language for people learning to code.

JavaScript (not to be confused with Java) is a scripting language that lets you add interactivity and dynamic behaviors to otherwise static web pages.

Some interactive features JavaScript can add are:

• A map with a user’s current location
• A message shown to a user once they land on the page
• A change on the page based on user input
• An animation when a user clicks a button
• A smooth scroll effect when there is a button to scroll back up to the top of the page.
• Mouseover effects

One of JavaScript's strengths as a language is that you don't need to compile your code to see the results of your work.

Javascript is built in and runs in browsers, meaning you don't need to install it on your local machine and go through a complicated and error-prone installation process.

JavaScript is used primarily for client-side programming and server-side scripting.

Specifically, JavaScript is used for frontend web development and even backend web development with the help of Node.js, a JavaScript runtime environment for running JavaScript on a server and not just the browser.

Knowing JavaScript is a must if you want to work as a frontend developer, and it is a popular language of choice for backend and full stack web development roles.

To learn more about the differences between frontend and backend web development, give this article a read. And to learn what the job of a full stack web developer entails, give this article a read.

Besides creating complex web applications, JavaScript is also used for creating browser games.

To learn JavaScript, check out the following resources:

• Full JavaScript Course for Beginners
• Learn JavaScript in Spanish – Full Course for Beginners
• Learn JavaScript by Building 7 Games - Full Course
• JavaScript Tutorial: Build Flappy Bird and Doodle Jump
• JavaScript Algorithms and Data Structures certification

Python

Python is a general-purpose server-side scripting language. And according to the Stack Overflow Developer Survey for 2022, it is the third most popular language for people learning to code.

Python is a great language for beginners thanks to its readable, intuitive, concise, and beginner-friendly syntax.

It is a popular language when working with large amounts of data, so it's often used for machine learning, data science, data analysis, and data processing.

It is also the language of choice for web scraping. Web scraping is an automated technique that extracts, collects, and processes large amounts of raw data from the web.

You can also use Python for backend web development to create web applications with the help of frameworks such as Django and Flask.

In addition, Python is a popular language for test automation.

Instead of writing all the tests for your programs manually, you can rely on automation tools, Python libraries, and Python scripts to get the job done.

To get started learning Python, check out the following recourses:

• Python For Beginners Courses Ranked from Best to Worst – freeCodeCamp Edition
• How to Code 20 Beginner Python Projects
• Learn Python by Building 12 Projects in This 3-Hour Course
• Backend Web Development with Python - Full Course

SQL

SQL is short for Structured Query Language.

You will likely hear it pronounced one of two ways – "S. Q. L." (ess-kew-ell) or "sequel" (like a sequel to a movie).

Either way, SQL is a language used for working with databases and any job that involves storing, managing, accessing, and analyzing data. It is one of the languages of choice for data scientists, data analysts, statisticians, and marketers.

Specifically, with SQL, you can access, query, manipulate and interact with data stored in relational databases.

A database is an electronic storage localization for data. In databases, you can easily retrieve and search through your data.

And a relational database stores data in a structured and tabular format. That is, it stores information in tables (which you can think of as storage containers for the data) organized in columns and rows. All data items stored have pre-defined relationships with each other.

With SQL, you can write database queries to perform any CRUD (Create, Read, Update, Delete) operations on the data.

It is worth mentioning that SQL is not technically a programming language - you cannot build web applications or software tools using it. It is a query language and a tool used for managing relational databases and performing operations on the data stored in them.

And although it ranks fifth as the most popular language for people learning to code according to the Stack Overflow Developer Survey for 2022, it ranks third as the most popular language for professional developers.

So, it is a good idea to learn SQL as you may need to use it in a professional setting.

To learn SQL, check out the following resources:

• Learn SQL – Free Relational Database Courses for Beginners
• SQL Commands Cheat Sheet – How to Learn SQL in 10 Minutes
• Learn SQL with These 5 Easy Recipes
• SQL and Databases - A Full Course for Beginners
• Relational Database Certification

C++

In the early 1980s, Bjarne Stroustrup created a language influenced by the C programming language. It could get close to the machine hardware and do demanding low-level computational tasks, but it also provided a higher level of abstraction without losing the low-level efficiency of C.

So, the language 'C with classes' was created, and in 1984 'C with classes' was renamed C++.

C++ is a superset of C and provides additional capabilities to the C language.

C++ allows the programmer close access to and manipulation of the machine while providing efficiency and high performance for large-scale systems. At the same time, it is higher level with enough abstraction away from the machine.

C++ is both a procedural and an object oriented programming language. OOP divides a program into objects.

Everything gets organized and divided into smaller groups of related parts or objects, which are an instance of a class, following a bottom-up approach.

This programming style creates more readable and usable code that is easier to maintain while providing better data security.

C++ is a popular language for:

• creating game engines
• creating computer graphics
• creating applications
• creating VR applications
• creating web browsers such as Google Chrome, Mozilla Firefox, Safari
• creating web browser extensions - the Google Search Engine is built in C++

According to the Stack Overflow Developer Survey for 2022, it ranks sixth as the most popular programming language for people learning to code. And it is a great language if you want to get a software engineering job and develop programs and applications.

To learn C++, check out the following resources:

• How to Learn the C++ Programming Language
• Learn C++ Programming for Beginners – Free 31-Hour Course
• Learn Object Oriented Programming (OOP) in C++ | Full Video Course

Java

Java is an object-oriented, general-purpose programming language whose syntax is based on the C and C++ programming languages.

One of the language's advantages is its portability. Portability in computing means that programs get written once on one machine and can be transferred and run smoothly on another.

The Java Virtual Machine lets Java run on any device and operating system.

Java is used for:

• Building mobile applications for the Android Operating System
• Backend web development
• Game development
• Creating embedded systems
• Building desktop applications
• Building enterprise-level software tools for the banking industry
• Building artificial intelligence and Internet of Things (or IoT) devices

Keep in mind that Java is not the same as JavaScript – they are in no way related to each other despite having the word 'Java' in their names.

JavaScript is an interpreted scripting language that runs in the browser and doesn't need to be compiled.

Java uses a combination of a compiler and an interpreter and runs on machines - not in browsers.

According to the Stack Overflow Developer Survey for 2022, Java ranked 4th as the most popular language for people learning to code.

Java coding skills can help you get a job as a software engineer, a web developer, and an android developer.

To start learning Java, check out the following resources:

• Learn Java – Free Java Courses for Beginners
• The Java Handbook – Learn Java Programming for Beginners
• Learn Java Programming (version 17)
• How to Build a Sudoku Game Java Desktop Application – A Free 2-hour Course

Conclusion

Hopefully, this guide was helpful and gave you some insight into some of the best languages to learn as a beginner programmer.

Thank you for reading, and happy coding!

Hi everyone, I'm Jalmari Ikävalko, a software developer in my early 30s. In this article, I’ll share my whole journey from my first contact with code to becoming the professional developer I am today.

I'll start from my childhood when I first got interested in programming.

My Introduction to Programming

I was around 12 years old – give or take a year – when an unexpected summer storm was keeping us stuck indoors in the otherwise sunny Costa del Sol of southern Spain. It was the only time I was properly abroad as a kid, as the financial situation of my family wouldn’t typically allow a vacation beyond the confines of our home country.

My cousins and I were in our grandfather’s tiny apartment – as his operated-on lungs did not agree with the Finnish winter – and there he had a computer. The computer had no internet access, but at the time Microsoft Word happened to include a Visual Basic editor and compiler.

Then it was that my cousin, older by a year or two, showed me some basics of programming, in Visual Basic.

A screenshot of Microsoft Visual Basic editor

As far back as I can remember, I’ve been interested in computers and enjoyed spending my time on them.

At my mom’s place, where I lived most of the time, we didn’t have all that many video games, and the computers tended to be a few generations behind the current crest of the wave. Still, I could spend a lot of time just exploring what the computer was able to do. Trying out DOS commands, going through random files I found, and so forth.

So when I realized that anyone could program these machines and create new applications on them, I was of course immediately intrigued.

How I Started Learning to Code as a Kid

My journey started off pretty bumpy. At the time, I had no idea where a little kid with poor English skills could find usable resources for learning to code. I bugged my dad, who had done some websites and had some general understanding of programming as a phenomenon, and he showed me some HTML, CSS, and JavaScript.

JavaScript, at the time, was relatively new and hadn’t yet properly established itself as the de-facto language of the web. In fact, most websites avoided relying on it.

I went through the books in our small local library, but most of them were completely unintelligible to me (the librarians there were awesome, though. They’d suggest books to me while I hung there after school and there was a computer available with good Internet access).

I got my mom to buy me a book on C++ and I trudged through it, mostly not understanding what I was reading.

Challenges of Dyslexia and ADHD

In those first years of learning to program, I didn’t really focus on learning very consistently and wasn’t really able to finish any projects – not even the tiniest of projects.

I would often feel very frustrated when I was trying to make something work and just couldn’t understand why it didn’t work like I imagined it should.

At the same time, school was not going very well. I was diagnosed with dyslexia in the first years of elementary school and was in remedial education for English. I also struggled with motivation – and bullying – and ended up only barely getting through without having to repeat a grade.

When I was around 15, I discovered IRC (a text-based chat system) and a Finnish programming community with its own website and an IRC channel. At the time we finally had gotten a broadband internet connection, which let me spend most of my days online. Having people to talk to and having resources in my native language accelerated my learning process.

I also got interested in demoscene – a scene of computer artists revolving around what is known as demos. These are programs that programmatically generate video and audio at runtime, without the video and audio being pre-recorded and stored inside the program. I got interested in creating visual effects programmatically.

Still, I was struggling with understanding graphics programming and how more advanced visual effects were created. I was stuck creating some pretty simple ones, like a basic tree fractal.

A simple tree fractal

Meanwhile, I had some peers, not necessarily any older than I was, who were doing complex 3D effects, full-duration demos, fully playable games, and more.

I often felt pretty dumb in comparison, as I wasn’t nearly as quick a learner as they were, and I struggled with making sense of complex code.

In retrospect, it’s not too surprising – my dyslexia and the ADHD I was later diagnosed with definitely affected, and continue to affect, my ability to discern symbols from each other. They also make it difficult to make sense of long lines of text, whether the text is in a human or a programming language.

Even still I get mentally exhausted from reading text with sentences that are too long. The first ten or so pages of Dostoevsky’s Crime and Punishment, to me, felt like reading a full book on advanced algebraic geometry.

Still, I pushed on, motivated by the thought that one day I would be able to create visual effects, games, physic simulations, and so on.

My First Job

I did some small demos and some physics demonstrations, nothing very special, and overall they were pretty crude, but somehow they still managed to land me a trainee job in a small local company working on a 3D engine for phones.

This was in 2008 or so when I was 18. At the time I didn’t even own a smartphone. The first iPhone had just come out a year earlier and I’ve always been a bit behind with the latest tech.

I was pretty sure that a 3D engine for a phone made no sense – who would want to be looking at 3D content from that tiny screen? And I was, of course, completely right! Well, okay, I wasn’t, but worse though – and somewhat to my horror – I was completely out of my depth.

I had managed to fake some sort of an impression of skill in the interview, but in truth, I had no idea about how to properly program shaders or improve and optimize a rendering engine.

I wasn’t able to do the job and my contract wasn’t continued – I felt embarrassed enough to never have included that short stint in my future job applications.

Getting Involved in Open Source

Around that time, I also made some small contributions to a couple of open source games and 3D engines. It wasn't anything very special, or mathy, or bleeding edge – just adding minor features like copy-pasting constant values to a list from some specification or adding a feature for picking up multiple items at the same time instead of just one item. Stuff like that.

I was still learning quite slowly and wasn’t able to finish complex tasks on my own. This was frustrating, since I'd been aware of programming for around six years and had more actively practiced it for two years. The people involved were very helpful though, and I did learn a lot of small things from everyone helping me.

My University Experience

The year I turned 19 I applied to university. I did not have the formal prerequisites for enrolling in a Finnish university, as I hadn’t completed the Finnish matriculation exams (roughly comparable to SAT in the USA and the A-levels in the UK).

Still, I wrote them a letter asking for special permission to participate in the exams for computer science. I was granted permission and scored high enough in the exams to enroll.

Unfortunately, I still wasn’t a very good student. On one hand, I was a bit too proud and felt the beginner courses were somehow too menial for me. On the other hand, if a course got hard, I quickly lost the motivation to study.

After a few years of finishing only a few courses and without having learned much of anything, I got kicked out.

I was around 21, out of school, jobless, and back to living at my mom’s place. I still kept to programming as a hobby. Writing minor features for open source software, trying out a few short gigs (and failing them all). Then I noticed someone on one of my IRC channels looking for help with their startup. I volunteered and ended up getting hired.

Working at a Startup

I remotely knew the person, as they were partially involved in the same communities as I, though we hadn’t directly talked before I joined his company.

It was a bit of an unusual setup. We shared an apartment, which was kind of unofficially part of the pay, and my salary was something like half of what the company I now work in would pay for trainees and juniors in their first job.

I would generally not recommend these sorts of contracts to people, but in my case, it didn’t work out too badly. I was finally able to be somewhat useful, could live on my own, and was making at least a little bit of money – not that any of it was ever left at the end of the month.

I still wasn’t very good at finishing tasks on my own and the quality of my code was rather bad. But with that pay level, my friend’s startup didn’t truly have all that many options. Mostly, I was doing minor feature improvements, fixing bugs, and adding some new functionality to the software.

A year or two later I met my then-future wife. We moved together, I changed cities, and left that startup behind.

Junior Game Developer

I then applied to another startup, with a slightly better salary, and with more than 2-3 people working for them. My assignment for the technical interview was to add a mirror effect to a 3D scene with a skater on ice.

Typically, you do reflections by placing a virtual camera on where the reflection is and then render the scene from the perspective of that camera. I had never done that, though, and ended up using another hack that I had done previously.

I simply rendered the scene again, just flipped on the X-axis. It’s an imperfect technique but was commonly used in older games and works well enough for flat surfaces that are underneath the camera by a sufficient distance.

The job was a bit all over the place, in regard to the skills needed. The fact that I had contributed – even if insignificantly – to a large bunch of diverse projects finally paid dividends.

Over the same day, I might be coding shaders for graphics effects. I might be fixing up a web backend, configuring installers, or maintaining servers (having run Linux through much of my teens was worth it! Though it had never made me as popular in school as I was told it would).

From Junior Dev to CTO

When I started, I was a junior game developer by title. Over time we got more and more projects, the work got more challenging, and then one day our CTO left. With no one else to replace him, I became the replacement.

At roughly the same time, good ol’ Adobe Flash was dying and its support was ending, and our products happened to be mostly in Flash. So I ended up leading a major rewrite of our main products from Flash to the Unity game engine.

At the same time, we expanded our repertoire of web products, and I led the development for those, too – sometimes more successfully, sometimes less. I still wonder how exactly I managed to keep up with it all and not crumble under the stress, but I suppose that when you give someone responsibility, they just might rise to the occasion.

A noise meter & crowd camera product of a startup I worked for (from Uplause promotional materials)

I ended up working at that company for six years. But at some point, I started to feel that my chances for professional development were exhausted. We had trainees and juniors coming by, staying half a year to a year, and a lot of the time I was the only experienced full-time developer.

I also didn’t feel very invested in the projects anymore. They were fun enough to do, but I didn’t own any of the company and my salary wasn’t at the level where it would have been elsewhere.

At the time, I wasn’t very well aware of the wider Finnish IT scene. I mostly knew about our biggest game companies – which weren’t and still aren’t that many – but I didn’t really know what the big consulting or product companies were.

So, I ended up applying for a new job by simply googling for job openings and finding a company with a stated mission and values that seemed like a good fit for me.

I didn’t know it at the time, but that company had actually won a bunch of awards for being one of the best places to work at. And it was, in a sense, somewhat prestigious to work at.

I arrived at the interview woefully underprepared, but the cultural fit was good and my technical skills were deemed decent enough to proceed through the interview rounds and I ended up getting hired.

From Startups to Software Consulting

So, around three years ago, I moved away from the startup world to become a software consultant.

When I joined my current company, I was quite self-assured in my skills and considered myself to have grown into a very good and clever programmer. I wasn’t completely wrong, but it did turn out that I went from being the large fish in a small pond to being, at best, an average fish in a much larger pond.

My old enemies, concentration and focus (or the lack of them) were again orchestrating quite the discord to deal with. I doubt I’ll ever be fully free from having to regularly repeat the struggle of finding motivation and keeping my discipline up.

There were also parts of my technical skillset that I had badly overlooked. In the first year and a half, I ended up significantly improving my functional coding skills and my ability to write easily testable code.

I also needed to modernize a lot of my knowledge. Getting used to newer continuous integration tools, cloud services testing tools, and libraries, was quite the process. (At the small barely-getting-by type startups, we typically used virtual private servers since they were cheaper and cloud services weren’t yet quite as mature as they are right now.)

Practical work is one of the best ways to improve, though, and improve I did – and at a pretty decent pace, in my opinion.

Today, our company isn’t much for titles and we sometimes use purposefully inflated titles just for the cheap laughs. But if I have to give a title to a client, I’m typically a senior software consultant. It’s a descriptive enough title.

And after an arduously long journey to become a developer who can kickstart projects, lead feature development, participate in all stages of software development, and whose help and feedback others can rely on, I think I’ve finally matured enough to check all the boxes for what’s expected from a senior developer.

I’m still constantly learning new things. Lately, I’ve started to feel like I would like to try out working on data engineering, data analysis, and machine learning tasks.

Since I mostly ended up skipping school, I’ve been taking statistics courses at the open university of Helsinki to better understand the terminology and methodologies that data analysts are using.

On the other side, I’ve also started to study for key cloud certificates, like data administrator and data engineer certificates, to further up my credentials in client offerings.

And, funnily enough, after finally having had some success in studying through difficult courses, I’ve also started to feel that maybe a Bachelor's Degree wouldn’t be impossible for me either. Though I am not sure if after all this time I still want it in Computer Science!

"Luck is What Happens When Preparation Meets Opportunity"

So that was my journey, from the first time I saw code to what I am doing today. It was at times a frustrating and bumpy road, and I know many people have had an easier time learning to program than I had. Still, I consider myself pretty lucky overall.

One ex-coworker used to have a quote by the Roman philosopher Seneca as their signature, “Luck is what happens when preparation meets opportunity”. But there’s a lot more to it than just that. Your childhood environment affects your preparation and the opportunities you get are down to statistical chance.

I consider myself lucky for having had so many opportunities despite also failing them due to lacking preparation.

And I consider myself lucky for having had supportive parents and a smart, programming-aware cousin to show me stuff.

Today I am lucky for having some pretty amazing, extremely skilled co-workers and a work environment where neurodivergence is accepted.

Yet, there is a bit of truth to the quote. If preparation is what you get as a product of hard work, I did put in the work even when the work was mostly hitting my head against the wall.

The truth is that if you have a disadvantage like dyslexia or ADHD, things can take a lot longer for you to learn than for someone else. But that doesn’t mean it’s impossible to learn. The end result just might be all the sweeter, too. The skills you end up with will be hard-earned, a testament to your ability to overcome difficulties.

Today, it is absolutely awesome how much better resources fresh learners have available to them. When I was younger, the quality of free resources – when they were available at all – was often dubious at best, and many tutorials didn’t teach things well, if even correctly at all.

We have the likes of the University of Helsinki’s MOOC.fi available for everyone, for free. And we of course have freeCodeCamp. There are many learning communities spread over Reddit, Discord, and so on.

Make good use of these services and, one day, after having made it, perhaps look back and see how you could contribute to them in turn.

One last piece of advice I’d like to give to people new to programming: Programming is at its best when it’s fun. If you’re bored with your current courses and don’t feel like you’re enjoying your time, try out something different.

Generate sine waves and combine them into chords. Create some fractals programmatically. Try making the most annoying website possible, with flashing lights and sound effects when clicking buttons.

Make programming fun. You’ll also learn surprisingly much while doing it.

In addition to the freeCodeCamp editorial team, I'd like to credit Liisa Toivonen for helping out with proofreading and some suggestions.

Thanks for reading!

Each summer, MIT hosts a program called WTP, or Women's Technology Program.

In the program's own words, its goal is:

"to spark interest in the future study of engineering and computer science among high school rising seniors".

The program fosters a collaborative, women-focused community for those who have not had opportunities to explore engineering and technology.

This year, I had the privilege of being the Computer Science Instructor for the EECS (Electrical Engineering and Computer Science) track of WTP. This meant I would be teaching 20 high school girls how to code – none of whom had any prior exposure to programming.

In two short weeks, I, along with four brilliant tutors from MIT, would teach them the foundations of programming in Python: data types, variables, conditionals, loops, functions, classes, and even inheritance. The last week of the program would be reserved for working on a programming project of their choice, putting their new skills to the test.

As the instructor, I spent over a month preparing the materials for the class. During the course (no pun intended) of the class, I spent three hours a day running lectures and one hour a day running office hours for the students. Here's what I learned along the way:

1) Anyone Can Learn to Code

Yes, anyone.

On day 1, I handed everyone a Python cheat sheet. They looked at it with horror and intimidation (I will admit, the formatting was a little scary). But by day 8, we discussed the cheat sheet and the general consensus was that they understood almost everything!

The girls I taught came from all over the country, all with varying backgrounds and access to resources. By the end of the class, all the students felt like they understood the basics and simply needed more repetition.

Perhaps some students with more access to math and science resources grasped concepts faster, but those without the same background were still able to understand those topics eventually. It did take extra work.

These students often sought extra help with assignments, or voluntarily spent their time reviewing additional problems. Nonetheless, at the end of the day, they were able to complete the same tasks and projects as their accelerated peers.

2) Community Matters

When you learn with other people, it makes all the difference. A supportive, inviting community can help you answer questions, explain a concept from a different perspective, and remind you that the road ahead is tough, but you are all in this together.

Often, my students formed their own problem-solving groups to discuss approaches tackling different assignments. In fact, this collaboration is encouraged by MIT policies.

In these groups, when you discuss different solutions and weigh the pros and the cons of each solution, you are exposing yourself to new ideas and new concepts.

Ultimately, these will build problem-solving skills. At the core of programming, is problem-solving.

WTP created a unique community of supportive women, led by women in STEM. I noticed that the key to building a supportive and welcoming community is patience, understanding, and open dialogue–ensuring that nobody feels alienated, ridiculed, or belittled.

3) Coding Takes Practice

At the beginning of the course, I asked my students if anyone knew or was learning another language. Ten hands went up. Then, I asked my students if they could write a book in that language. No hands were in the air.

Learning a programming language is much like learning any other language. While it is critical to understand grammar, vocabulary, and syntax, these become intuitive with practice.

But programming a script is much like writing a book (or maybe an essay). The idea and structure are as important as the language itself.

Words alone do not write a book. Ideas write the book, and language simply expresses those ideas. Similarly, conditionals and loops alone do not make up a script. Logic writes the backbone, and conditionals/loops tell the computer how to execute it.

How do I keep track of used letters in hangman? How do I find the index of the smallest number in a list? How should I represent this polynomial?

For a beginner programmer, these are daunting questions. For someone who has experience, these come with intuition. The only difference between the beginner and the expert is the time spent on practicing the skill.

4) Teaching is Rewarding

I could have spent my summer relaxing on the California coast. Instead, I chose to teach. I have no regrets.

Teaching is difficult. There is a saying along the lines of: if you can't teach it, you don't know it. Teaching forces you to fully understand a concept so that you can explain it in multiple ways to others. It is exhausting to repeat yourself over and over, hoping that maybe the concept finally clicks.

However, when a student has that AHA! moment when something finally makes sense, it is the best feeling in the world. To know that you have passed on your knowledge to someone who desired to learn it means you have given a priceless gift.

I have been extremely privileged to go through an education system that values learning and to be able to attend one of the most renowned colleges in America. I attribute much of this to the teachers I had growing up. This is proof that teachers can have a huge impact.

At the end of the course, some of the students were excited to show their friends what they learned and to help then learn to code as well.

The act of teaching is exponential.

In Reflection

Initially, I was hesitant to be the instructor. It meant three weeks of my summer after graduation occupied by teaching. Twenty high school girls' introduction to programming through me, their thoughts about STEM influenced by how I taught my course. I was nervous.

However, reflecting upon the summer, I am extremely grateful to have had this once-in-a-lifetime opportunity to interact with and teach these students. I helped them learn not just how to program in Python, but also how to think like a computer scientist. It inspired me to continue teaching, especially in interactive environments where I could ask real-time questions.

At the very end of the program, the students created a monthbook and wrote cute notes to one another and the staff. Upon reading the messages addressed to me, I felt honored to be part of their introduction to computer science. They were just as inspirational to me as I was to them.

It's almost been two years since I got into coding and a year since I became a full-time dev.

I started writing this article merely as a self-reflection exercise. But I thought maybe someone who's in a similar position as I am or is just starting to code right now might find some of my experiences useful or interesting.

I plan on talking about a lot of things here. I'll go over everything from my background and how I switched careers at almost thirty to how I learned to code and chose my tech stack.

I'll also discuss what I plan on learning in the future and why, along with some general advice and my overall feelings and thoughts about this first year of professional work.

The way I'm going to structure this is that first I'm going to tell you the story of how I became a developer. Then I'm going to list the main thoughts and concepts that have helped me get to where I am now.

This article is going to be a bit different from what I usually write, in the sense that it won't be too technical and it might get too self-referential at some points. But the idea is to take you through my experience and thought process so you can get an idea of how things could be if you walked the same path.

Although always remember my opinions and experiences don't necessarily extend to everyone else. And I don't claim that my choices and preferences are necessarily the best. So you know... if you read through it all, just take whatever is useful to you and ignore the rest. :)

Enough cháchara, let's go!

Table of Contents

• My background

• How I learned to code

• My first job as a developer

• Present tense and future

• Tips and thoughts

  • Learn how to learn

  • Try to find a path

  • Do you need a college degree to work in technology?

  • What kind of developer do you want to become?

  • How to pick a tech stack

  • Don't jump around too much

  • Don't be too comfortable or get ahead of yourself

  • How to know when you're job ready

  • Sometimes not coding is the best way to learn about code

  • Diversify your learning sources

  • Keep in mind that nobody knows everything

  • There're good and bad things too

• Wrapping up

My Background

I'm a 29 year old guy from Buenos Aires, Argentina.

I grew up here, and once I finished high school I had no idea what to do with my life. I knew I had to go to college because that's what everybody else was doing. And according to "general knowledge", that was what was going to give me the best chances at life. So I started investigating around different career paths...

I was a shy and introverted adolescent in high school, so in this new chapter of my life I decided to change that and get more in contact with people and society in general.

I was attracted to social sciences studies such as philosophy, psychology and history. But It worried me that these professions weren't very in demand in the labor market. So I ended up choosing a major in human resources, as I thought it was a good match between social sciences and business.

I made this decision completely by myself, as I was part of the first generation of college students in my family. I didn't really know anyone who could guide me in this situation. I just made the best guess I could with the information I had.

Fast-forward a couple of years and I was starting to heavily regret my choice. I wasn't interested at all in what I was studying. The rigid structure and bureaucracy of college bored me to death and I had the feeling that I was wasting all my youth hearing people I didn't respect giving me meaningless lectures.

I started analyzing again what other career paths could I take, but nothing seemed to convince me enough. I even consulted with a group of vocational orientation professionals who charged me a ton of money for telling me that I was going to be a great HR manager in the future and that I should "just keep going".

This together with the fact that I had already put two years into this college thing convinced me to "just keep going".

Fast-forward another couple of years and I still felt the same way, but at least I was close to graduation and I was also working. So I was still bored to death but at least I was making money out of it.

I finally graduated and exited college with the feeling of having learned almost nothing, just happy that I was finally going to have more free time.

Regarding work, I started climbing the corporate ladder. Switching jobs every once in a while, making a tiny bit more money, and working for big and well known companies.

At this point I somehow got convinced that I liked this life, and even though I never enjoyed my job or being in the office environment, this was part of the deal.

In 2017 I was working for a very big industrial company and was offered the chance to move almost a thousand miles away from Buenos Aires, in exchange for a salary raise and the promise of future professional growth. I thought about it and accepted, as at the moment it seemed like too much of a great opportunity to pass by.

The work environment in this new position was terrible. I had to deal with crappy tasks, crappy leaders, and crappy people in general. I was learning nothing and the promises of future professional growth ended up being BS.

Things kept going the same direction for a few years, and when the pandemic arrived I was working harder than ever, often putting in nights and weekends, but somehow my leaders weren't happy with my effort.

I was feeling stuck and bitter. I left my family back in Buenos Aires in order to grow my career, and even though I was working as hard as I could, I wasn't collecting any profits and I was disliking my job more than ever.

At this point I finally opened my eyes and realized I couldn't be there anymore. I didn't know what to do next but I definitely knew I had to get out of there.

Then I saw an ad somewhere about a programming course and started investigating coding. I was always interested in technology, and at the moment it just felt right to occupy my mind with something new.

I didn't think about it as a way to get a new job, but as a hobby, a way to get my brain to think about something else.

How I Learned to Code

So after seeing this add and getting interested in coding, I did what most people do when looking for information: I Googled things, opened a ton of browser tabs, and watched a million YouTube videos.

I remember at the time I often couldn't understand a single thing about those videos. So many strange terms where used and people related each of those terms to other topics I had no idea about.

I didn't really know how computers worked, much less how the internet worked. I didn't know what a programming language was, why there were so many of them, what was the difference between front and back-end, what a function was, what a variable was, what on earth was SQL ... So many concepts and all of them completely new.

I just didn't know where to start. Learning to code felt like staring at the wall of Game of thrones.

I was feeling like the recruiter here...

Here's where I got back to freeCodeCamp (I had done a bit of a basic HTML and CSS course a few years ago) and also downloaded an app called Mimo (which helps you learn to code in a Duolingo kind of way).

These structured courses helped me organize my learning and grasp the basics of things before moving onto more complex topics. I dedicated a few hours every day to these two resources, and after a few months I was able to build a very very simple HTML and CSS page.

After that I felt I needed to interact with other people who were in the same learning path I was. I wanted to share knowledge with others, hear from other people's experiences, and check if what I was doing and learning made sense compared to what everyone else was doing.

The way I got to this was by signing up for a few online bootcamp courses. I liked that classes were live with a professor and a bunch of other students. This meant that I had the chance to ask questions, hear other people's questions too, and compare myself to others.

Four months went by and at that point I was completely into coding. I'd become comfortable with HTML and CSS, and also learned basic programming concepts with JavaScript. I was dedicating absolutely all my free time to this and even though slowly, I felt like I was making progress each day.

By this time luckily I was able to switch jobs (still within the human resources field) and get back to Buenos Aires. I was working in a much nicer environment and I was happy with my job and the team I had. But I still kept coding and learning about it every day. I just liked it a lot and felt I could be good at it some day.

A few more months went by, I completed more bootcamp courses, and got comfortable with React as well. I was able to build some more interesting and "complex" projects on my own and with the passing of time I got more and more curious about how could it feel to do this for a living.

I could somehow picture myself as a developer, and after doubting a lot I decided to give it a try and started applying for jobs.

I got rejected A LOT and struggled BIG TIME with the few interviews I was able to get (you can read more about that in the article I wrote about tech interview tips).

Some of those interviews were like a reality check for me in the sense that they made me realize there was still an immense amount of things I knew nothing about and I'd need to keep improving if I was ever to have the chance of working as a dev.

These experiences kind of hurt my self esteem and made me doubt if I could do this. I gave up coding for a few weeks for the first time in almost a year, but eventually got back to it. I just liked it a lot and felt like I had to prove the people who rejected me wrong.

By this time I started to expand the resources I was using to learn. Live classes weren't that interesting for me anymore since I felt I didn't need constant feedback from others like I did when I was starting.

Now that I had a wide array of knowledge, terms, and concepts at least superficially present in my mind, I could easily take advantage of asynchronous resources like videos, articles, and documentation.

And more importantly, I knew what path I needed to go through in order to learn what I needed to learn to get to the jobs I wanted.

So I reduced the number of live classes I was taking, and started getting more into videos, articles, and documentation of good trusted sources I found.

Also, I started writing about each of the things I was learning, which made a huge difference for me as it helped me internalize knowledge, go into detail on each of the topics I learned, and gain confidence in a way I hadn't experienced before.

In parallel I was still going through different interview processes and feeling better and more confident in these situations. And in one of these processes I ended up getting hired. 🙃

After a year of learning, burning my brain, and dedicating absolutely all my free time to code, I finally reached my goal.

I remember I felt as happy as I'd ever felt when I got the news. It felt like ending a marathon. I'd never before put so much consistent effort into something, and the feeling of going from knowing nothing about technology to being able to call myself a "programmer" was amazing.

It was really a great moment, but to tell the truth, I was also scared to the bone... When I looked into the mirror I didn't see a programmer. I saw a guy who still didn't know much. And now I was going to switch careers and put my financial (and emotional) stability at risk. Crap... 😳

My First Job as a Developer

Luckily, all the fears I had going into my first developer job were unfounded. I landed on an amazing company, and got to work on an amazing team with an amazing leader.

There were TONS of new things to learn, and at moments I couldn't understand a single thing. But my team made it clear to me that this was what it was supposed to feel like and that I should be patient and stick to the process of learning.

I did, and I took it step by step. With the help of my leader and teammates I was able to become pretty much proficient in a matter of months.

My team had a great culture and our leader encouraged us to share knowledge all the time. If someone found a bug, created a new feature, or wrote some documentation, that had to be shared with the rest of the group.

The same went for when someone made a mistake. Mistakes were not treated as opportunities to blame someone, but as chances for everyone to learn.

We had weekly meetings in which we shared this kind of information with each other. Through this continuous exchange I made a huge "click" in my mind. I understood no one knows everything.

Before I got this job, one of my biggest fears was that I wasn't prepared enough. There were many things I knew nothing about and I felt I "was supposed" to know them. But after getting to know developers with 5, 8, or more years of experience, I understood even with that amount of study and preparation, they still don't know everything. And that's ok, because no one can.

The size of the technological world humans have created and the constant evolution of it just makes it impossible for a single person to understand and know every single detail.

What I think is truly important is to deeply understand the given set of tools you work with in your environment, and to have a superficial understanding of the general system you work within.

But even then, you'll still never understand everything. Learning new things all the time and figuring things out is a core part of the job. In fact, what most companies pay engineers for is to figure things out. You just face problems you don't know how to solve at first, and slowly figure them out until you arrive to a solution.

This single idea was very powerful to me, and allowed me to get over the impostor syndrome I felt.

Overall I was feeling awesome at my new job. I was working remotely all the time (which I love and allows me to spend more time with my family and pets). I was working with people I felt related to in the sense that everyone was interested in sharing knowledge and constantly learning. And I felt my job was stimulating and interesting.

I was using my brain everyday, having to think in order to solve stuff, and that made me feel alive and useful instead of the zombie-like feelings I had in past jobs.

The feeling I had (and still have) is that my job and my hobby are the same thing. I'm not longer living for the weekend (great song by the way). I enjoy my job and I still dedicate most of my free time to learning and doing code-related things because I like it.

Present Tense and Future

After 9 months at my first job as a developer, I got the chance to switch jobs again. It was hard to leave such a great team and leader, but in my current position I'm able to work with cool technologies on a big and interesting project. Also, changing companies and projects has allowed me to understand a little bit better the process of software development and how different companies manage it.

It's also very interesting to get to know other fellow developers and learn from them. I feel there're things to learn from every single person working in this industry, so getting to know and work with new people every once in a while is something I'd like to keep practicing.

Besides focusing on my job, I also got back into college to study computer engineering. I made this decision because I felt most of the courses and classes I took focused heavily on learning to use tools (such as React or Node for example), but I lacked the basic knowledge those things were built upon.

I wanted to have deep knowledge about computer science topics too, and even though there're many ways in which you can get this knowledge, college made sense for me.

I find it funny that I'm having a completely different experience now compared to my first time at university. I'm attending classes with curiosity and learning at least a few useful things every time. Being truly interested in what you're learning and understanding the purpose of the information really makes a huge difference.

And besides those two things, I'm also working as a part-time assistant teacher in a coding bootcamp and trying to periodically write articles.

Sharing knowledge with others is something I really like and appreciate about the coding world, and without a doubt is one of the things that has allowed me to learn the most. Lots of people have benefited from this practice and I'm not an exception.

Regarding the future, I want to train myself as a well rounded software engineer. And by this I mean I'm aiming to gain knowledge about the whole ecosystem of things that lays around the creation of web-based software: front-end and back-end development, testing, infrastructure, cloud technologies, CI/CD, systems design and so on.

I feel that having at least a superficial knowledge of the core concepts in each of these fields is important and valuable, even though if end up specializing in a certain field later on. So this is what I'm directing my attention towards at the moment... and the rest is just to keep going.

Reflecting on the steps I took in the last few years, from the position I'm in now, I kind of appreciate how the experiences I had led me to where I am now.

Working in the social sciences environment for several years allowed me to gain the social skills I lacked when I was an adolescent. Also, working in toxic environments forged my character and gave me the ability to appreciate good teams and leaders.

It's likely that if I had never gone through those unpleasant experiences I would've never gotten into coding.

Life is really weird... I don't like to pretend I know how it works. I don't think anyone does. But in these past years I learned for myself that I can do whatever I set my mind to if I put enough time and effort into it.

I also learned that I should never settle for a situation I'm not comfortable in. What I like to do for a living is learning, thinking, and using my brain to solve problems.

Tips and Thoughts

So now that we're done with the telenovela, I'm going to present you with the main concepts and thoughts that have helped me get to where I am now.

Again, keep in mind this is not direct advice. Some of these things might not apply to you, but the idea is to share them so you can analyze and make decisions for yourself.

Learn How to Learn

If you'd like to become a developer, become comfortable learning things constantly. As I mentioned, I think this is a core part of the job for most of us.

Get used to the struggle of not understanding things at first, asking questions, doing research, making little or no progress at all, giving it another try, googling, watching videos, reading articles... and slowly but surely getting to what you want.

If you struggle and at times feel you're just not capable of understanding anything, that's ok! We all feel that way. The important thing is to be consistent, don't give up, be curious and keep going. You'll eventually wrap your head around things – just don't expect it to be easy or quick.

I think the best way to learn how to learn is just to keep trying. It's like a muscle: if you push it it will get stronger.

The cool thing is that things get easier as you advance. The more concepts and ideas you understand, the more connection points you'll have for the next topic you get into, which will accelerate your learning curve and help you move faster.

Try to Find a Path

The best thing about learning how to code is that there's so much information out there. The worst thing about it is also that there's so much information out there.

At the beginning everything sounds foreign and hard, so I think getting some kind of structure is of great help.

There're many sources for you to choose from. Free and with a cost, live or asynchronous, to learn alone or in a group... It's up to you and what you find works for you.

I'd say it's a good idea to start with something free to test if you like it. Then try different sources and work with the one or two you're more comfortable with.

Also, during the first steps, I feel like having the companionship of a tutor or a community is key to continue your learning path.

So much info can be overwhelming and it can be hard to know what to do next. A community and people to ask questions from can help diminish this level of uncertainty at the beginning.

Live classes solved this problem for me, but there are tons of ways to get in touch with people who are learning to code, so find one that suits yourself.

Also, after a while and once you have a clear understanding of your environment and what do you want to do, live classes can start to get less efficient and asynchronous learning becomes the best thing to do.

So getting to know useful and trustworthy sources of knowledge is key. And I don't have a recipe for this – for me it was just a matter of countless hours of exploring blogs, YouTube channels, and websites. And of course still all the time I'm finding great resources...

And about that, here I've put together some of the coolest resources I've found recently. Maybe it could be a good starting point for somebody. I'd also like to receive recommendations if you have any. 😉

Do You Need a College Degree to Work in Technology?

Absolutely not. I was able to get a good developer job without a related college degree.

Also, if you're just looking to switch jobs and get into tech, I'd recommend going to a bootcamp or completing some free online courses. It will probably be much quicker and cheaper for you than learning through college.

What I do think is that if you can afford going to college (both money and time wise), a degree won't hurt at all. And through college you can learn a series of general foundational concepts not often available in a bootcamp or programming courses (though this information is also available in other media and for free as well).

In my country, college education is relatively cheap and there are quality free options as well. So college was a reasonable choice for me. But this may vary from country to country and from person to person.

What Kind of Developer Do You Want to Become?

Once you start to comprehend the technology world, you'll see that the software engineer profession has many different paths and nuances. To name a few:

• Front end developers: Build the visual side of websites

• Mobile developers: Build mobile apps

• Back end developers: Work with all the software that is not directly exposed to the end user, like databases, authentication, and so on.

• Testing / QA: These people write programs to test that the software developed works as expected.

And many other paths like infrastructure, data analytics, robotics, and so on.

At first you won't be able to tell the difference between the one and the other, and that's ok. A good idea is to do a little research to understand all the possibilities that exist within the software engineering world, and see what you like most.

Also keep in mind there're different environments you can work in. From huge worldwide corporations to tiny startups, to freelance work, to starting your own company... Anything is possible.

Different fields and different environments make different experiences, and some might be better suited for what you like and what you're interested in. And also they'll require you to learn different things to get to work in those places.

How to Pick a Tech Stack

This is closely related to the kind of job and the environment you'd like to get. Though all knowledge is useful, some technologies are more related to one field and one type of environment in particular. So choosing carefully what to learn will help you use your time more efficiently and get to your goal quicker.

If I had to give a general path that applies to most people, I'd say get to know basic HTML, CSS and core programming concepts with JavaScript (variables, functions, loops, conditionals, data structures, and so on).

There're are lots of online resources where you can get this knowledge, and having these concepts under your belt will help you to some degree no matter what path you choose later.

I also feel that it's the easiest way to get into software since you start from a visual perspective that will allow you to build at least a very simple website in a few weeks.

Once you're there, I'd recommend that you analyze the different possible career paths and decide what you like the most or find the most interesting.

Watch videos, read articles, talk to people... Get a feeling of what each kind of job is about and what technologies are used in each of them. Then based on that, keep learning.

I find it's also important to choose based on what's available for you. For me, the bootcamp I was learning in had React and Node courses available, so that kind of laid the path for me. Maybe if they had Angular and Python courses I would've learned those technologies instead.

I don't really think it makes that much of a difference as long as the technologies serve your purposes. In the long run, technologies are only tools. And you can use many different tools to arrive to the same results.

Also keep in mind no choice is definitive. I mean, if you get into something and find that you don't like it, you can always get back and learn something else. It's useful to have some kind of plan and learning path, but it's not something rigid that can't be changed ever again.

Just to give you a superficial idea, the path I followed (and I'm still following) looks like this:

• HTML

• CSS

• Git and GitHub

• Basic terminal usage

• JavaScript

• React

• Node, Express, MongoDB and PostgreSQL

• Algorithms and data structures

• Testing: Jest, react testing library and Cypress

• TypeScript

• Intermediate terminal usage and scripting (Bash)

• React Native

• Firebase / AWS

• GraphQL

• Python

• Docker

Don't Jump Around Too Much

The idea of having a learning path is to provide structure and meaning to knowledge you'll acquire, so you can get to your goals quicker.

As I mentioned before, there's a huge amount of information out there and that's awesome if you know what you're looking for. But if you're not certain about what you need to learn, you might get lost between all the different possibilities and end up knowing just a tiny bit of a lot of things – and that's not really useful.

At least at the beginning, I'd recommend that you dedicate at least a few weeks to each new tool or concept you're learning. Make sure the knowledge sinks in and build a project or two with the tool you're learning, and then hop on to the next thing.

If possible, with each new thing you learn, try to add it to the same project or build a new one with all the tools you know up to that point.

For example, if you learned React before and now you're learning about back-end with Node, a good idea would be to build a front-end for that back-end too. Practice and repetition will make you better.

I also wouldn't recommend learning more than one thing at the same time. For example, let's say you're building your first React project and you're using TypeScript for the first time as well. That could be problematic, because when you get an error you might not be able to distinguish if it's a React or a TypeScript thing. You could also confuse concepts that belong to one technology with the other.

Don't Be Too Comfortable or Get Ahead of Yourself

Following the previous thought, I think it's important to push yourself and try to learn new things all the time. But it's also important to know where you are and control your rhythm. By this I mean, know when you need to move to the next thing and know when you need to stick to what you're learning at the moment.

This is a hard thing to know, and there's no way to be absolutely sure. I'd say you don't need to become an absolute expert, but at least build two decent projects with each technology you learn.

Make sure you understand the basic concepts behind it, understand the most common errors and problems you can face using it, compare your code to other people's code, and so on. If you feel you understand and can relate to most concepts regarding to that particular technology, then you're probably ready to learn something else.

Regarding what to learn next, that depends on your learning path and the things you've learned previously. I'd say a good sign is when you're able to connect some of the previous knowledge you have to the new things you're learning.

For example, if you learned HTML and now you're getting into CSS, you'll be able to understand how CSS helps you configure how HTML elements look and behave. If you learned JavaScript before, you'll be able to understand how TypeScript helps you control types and so on.

On the other hand, if you're trying to learn React without having a clue about JavaScript, you're very likely to mix concepts and confuse what technology is responsible for each thing (for example, I've seen many people think map, filter and reduce functions are a React thing, while they're all ES6 JavaScript features).

Consuming the right amount of information is important. Too little and you won't make progress, too much and you'll get confused and not make progress either.

How to Know When You're Job Ready

Short answer is you'll never know. You'll need to try yourself and (probably) fail to see what you still need to get better at.

There's not an exact recipe to get a job. Companies require different skills and have different levels of demand for their candidates.

I'd say a good place to start would be to go through job postings and see what kind of knowledge is required for the types of jobs you like. Once you're more or less comfortable with most of the things they require, I'd say start applying.

Waiting too long to apply for jobs can also hurt you. Even though doing badly at an interview sucks (I know, trust me...), it will really help you realize what knowledge you lack, and in that way accelerate your learning process.

You can read through this interviewing guide I wrote to help you prepare as much as you're able.

Sometimes Not Coding is the Best Way to Learn About Code

I feel that when you start out, building things is the best way to learn about programming. It gives you practical knowledge and the feeling of progress (which is key to get over the frustration any learning process involves).

But once you get comfortable with the practical side of things, I think it's also important to get a theoretical foundation. Learning how tools work, how the internet works, how computers work, the history of computer science, algorithms and data structures, and so on. I don't mean becoming an expert, but at least superficial knowledge of these topics is useful.

Regarding how to get this, you can go with videos, articles, books, courses... Again, there're countless resources to pick from.

But something I found really useful is to actually create content. Writing stuff, sharing knowledge, helping others – it all makes you think about code and programming from a different angle and have a deeper understanding of topics.

This is one of the main reasons why I like writing articles. And what I find the most interesting about it is that when I get back to actually coding, I feel that I'm a better programmer than I was before. I guess sometimes not coding is the best way to get good at it.

Diversify Your Learning Sources

I think a good way to wrap your head around complex topics is hearing different "voices" explain the same thing. Different people will use different analogies, vocabulary and approaches to explain. And eventually you'll find one that works for you.

Same goes to different formats like videos, articles, courses, and so on. Each time you're learning a new thing, try to combine different learning sources together so you can get a good general idea of it.

Keep in Mind that Nobody Knows Everything

Looking from the outside, it may seem that people working in the industry know so much more than you. But they don't know everything.

Senior developers normally have deep knowledge in some particular stack, but they don't know everything about everything, so much less should you if you're just starting out your learning path.

For me, being curious, eager to learn, and consistent in your learning efforts is the most important.

There're Good and Bad Things Too

For me, technology is the best possible environment to work in right now. Jobs are interesting and well paid, and the job market demand for developers is high (and it will probably keep growing in the future).

It's also one of the few sectors in which you can have a good job without a college degree.

I love it, and getting into technology has made a very positive change in my life. But I also think It's important to reflect about some of the negative things around it. For example:

Working remotely has challenges

Working remotely is great in many senses. For me, it has given me much more control over my time. It has allowed me to save tons of commuting hours and invest those hours into studying, spending more time with my pets and family, or just sleeping more. On the other hand, I recognize it has also separated me a lot from people and society in general which sometimes leads me to feelings of isolation, monotony, and social anxiety.

Working in tech can be stressful

Working in a project-based environment (which is the most common thing in technology) is awesome. You get to do different things every once in a while, facing different challenges, learning new things and getting the feeling of progress and accomplishment. But on the other hand, the pressure of dealing with deadlines and needing to solve technical problems so things can get done can be hard to deal with, especially at the beginning and on occasions where you don't have help from others.

While most people are nice...some really aren't

Though most people I've met in tech are nice, curious, and really eager to learn and share knowledge, there're also some egotistic, arrogant, and selfish people too. There're good and bad people in all paths of life.

Technology has a huge impact on our lives

To a bigger or lesser degree, by working in technology we're designing and making decisions that shape an important part of the world's reality and people's lives.

Think about it – technology is everyday becoming more and more intrinsically connected to everything we do as humans. From deciding what or where to eat, to traveling, to meeting new people and building relationships, to buying things, studying, managing money, looking for jobs or something so basic and central like getting to know the world around us. Googling has become the most primary action for most of us when we want to get information about anything.

Technology is absolutely everywhere around us. And as developers, this is great for us because it gives us a huge platform to impact people's lives in a positive way.

But that platform can also impact people's lives in a negative way too. As humans we've become so dependable on technology that decisions made by tech companies and engineers can have the same or more impact on society than those made by politicians.

We're all more addicted to our cellphones than we'd like to admit. Social networks have been used by companies to have a very detailed understanding of our expectations, preferences, fears and emotions. And from that knowledge, get us to buy things we don't need to impress people we don't like (yeah), or even worse, manipulate people's political opinions.

Technology is a very powerful tool, and that tool can be used both for good and for bad. The purpose and impact of it is up to us to decide, both as users and as developers.

Wrapping up

Well, I've talked about a lot of things here. I hope some of these concepts helped you picture how it may be to work in the technology industry yourself. Or at least cause you just to think and reflect about a thing or two.

If you read through all of this, I'd love to hear about your feedback or your own story in tech. You can hit me up on LinkedIn or Twitter if you'd like. 😉

Here's a little goodbye song for you (I'm making this a thing now 🤷‍♂️). See you in the next one.✌️