The version control system used, peer review process, code review process, design review process, how you do CI, automated testing, and manual testing – all vary greatly depending on where you work.

How a company plans, writes, builds, reviews, deploys, and releases software is optimized for their particular use-case, all with their own strengths and drawbacks in mind.

I started reading about how different big tech companies run their Software Development Lifecycles (SDLC) and heard the term Trunk-Based Development a few times. This is a practice Google follows and I was curious about how it's different than the way most other companies develop software.

Two Different Ways to Do Branching

Release Branching

There are two common approaches to enable multiple developers to work on one codebase.

The first we'll refer to as the release branching** method. I've also seen it called feature branching**. But both of these same approaches follow the same general pattern.

Usually via Git, developers all clone the codebase (so they all have identical copies on their machines). Then they make a new feature/release branch based on main, and merge as the work is completed. The emphasis here is that they only merge once, at the end, when all the work is complete – and they merge the whole branch into main.

Here's an overview for how developers use the Release Branch** method:

Release Branching development workflow visualised.

The white dots represent commits, and the bottom solid black line is main. This is a very simple example, as release branches often end up with far more commits than I've shown in the diagram (sometimes hundreds).

Developers branch off main, make their changes, and then when it's complete/has passed code QA, it gets merged back into main. That's release branching.

Trunk Based Development (TBD)

Trunk-Based Development (TBD) is the second approach. Here, each developer splits the work they will do into small batches and merge into main (which is often referred to as the trunk) multiple times.

In small teams, they normally don't create a branch and merge the branch into the trunk. They commit directly into the trunk without branches.

In a larger team (with checks and approvals necessary for MR's), they use short-lived branches. One release branch with 100 commits in TBD would be 10 merge requests with 10 commits each.

In TBD, their code changes generally don't stay around for more than a few hours. They constantly get merged and integrated with the code everyone else is writing.

Jez Humble is a Site Reliability Engineer at Google, and author of Continuous Delivery, who says "branching is not the problem, merging is the problem" – which is exactly what TBD tries to solve.

It aims to avoid painful merges that so often occur when it is time to merge long-lived branches that have diverged histories from the trunk, or even merge multiple branches together into one from different teams/developers before merging with the trunk.

Does TBD Work at Scale?

In a Google talk, Rachel Potvin, who's an Engineering Manager at Google, described one codebase that has (as of Jan 2015):

• 1 billion files
• 2 billion lines of code
• 86 terabytes of content
• 45,000 commits per workday
• 15 million lines changed in 250,000 files per week

They used TBD in this codebase and it served their use cases very well. As Google is made up of many talented (most importantly, experienced) engineers, they rarely break their builds.

Google also has a very thorough, strict code QA process (read about it here) which, when using TBD, allows for fast, efficient software delivery.

TBD also works well for Agile methodologies where you have to ship software frequently to get feedback from your consumers/customers. You can continually integrate and get a good snapshot of your current state.

Let's briefly discuss some TBD strengths.

Strengths of TBD

• Feedback (whether from code QA, or peer review) comes quickly, as you merge daily. This can stop you from doing the wrong thing for 3 weeks, and then getting feedback that your work isn't correct at the very end, causing you to miss deadlines.
• There's a mental benefit to TBD, where developers feel like the trunk is our code, rather than everyone having their own feature branches and thinking this branch is my code. This can foster a more collaborative culture, increasing communication.
• It results in early integration with all the other in-flight projects/tickets and helps you promote code re-use. It's much harder to "use code" that isn't merged into main and you don't know when will be complete. It also stops merge hell when your 9 month old release branch needs to be merged back into the trunk.
• Large projects with lots of work involved are forced to be broken down into smaller deliverables. This is much better for estimating timelines and also for breaking up your code into modular pieces.
• When lots of developers work in isolation on release branches, it can be harder to spot junior developers struggling in their own branch. But if they're expected to be committing their work daily, you can monitor their daily output and assist them when necessary.
• TBD really cleanly ties in with continuous integration. With lots of small, incremental commits to an eventual finished project, you get an always tested, always integrated codebase with (minimal) horrible merges.

Weaknesses of TBD

• One of the challenges of this approach is that you have an increased chance of breaking the trunk, and stopping lots of people from working. You have to make sure your commits run unit tests along with a good code review process so you don't lose time reverting commits all day.
• Your commit history into main will likely be more verbose and it can be harder to see if something is wrong. If you are called at 3 AM and asked to fix a bug on your prod site with some dodgy commits that went on during business hours, would you prefer a day with 1 commit or 200 commits?
• If you don't have a fast build process, you will spend a long time waiting for things to build while your team constantly commits.
• Often times with TBD you are incrementally adding new code to do something new, but you also need the "old" paths you're replacing to still work. Because of this you need to rely on feature toggles (normally from a database) to turn things on and off. This can add an extra level of complexity with debugging.
• A final challenge can be that, when you have constant commits, you are constantly in a state of churn. You need to make sure your team regularly pulls from the trunk and doesn't end up tripping over one another while merging things.

How to Release Software with Trunk-Based Development

Teams using TBD will typically have a different release process than a team using feature branches.

Generally, if you use release branches, you release main whenever you have something that gets merged in (tickets, completed projects, and so on). Or some teams release main on a schedule, like once every week.

Here's an overview of how TBD teams do their releases:

Overview of TBD process

In TBD, branching is used for releases to allow everyone to keep committing into main.

They provide a "snapshot" of your codebase at a stable state, ready for deployment and release.

The only reason the TBD diagram above may need extra details is when something goes wrong with the release of prj-123. Then we commit the result into the trunk and cherry pick the commits into our release branch to get it in a workable state as soon as possible.

Some places, if they are releasing regularly, don't even branch and can just release the trunk whenever it's required. It depends on your company oftentimes.

Conclusion

There is a whole site based on the theory and practice of TBD. Feel free to read more here.

I hope this has explained what Trunk Based Development is and why it's used. It certainly helps alleviate some of the issues around merging long-lived branches containing major rewrites.

I share my writing on Twitter if you enjoyed this article and want to see more.

A few months later in an interview, the interviewer asked me if I knew what "shift left" meant.

Unless there's a secret software-dance someone didn't tell me about, I'm now here to tell you what shift left means.

What Does it Mean to Shift Left in Software?

To shift left is a technical term meaning to try and identify problems as early as you can in your software project lifecycle.

The 'left' means the beginning of the project, and it's a phrase that just means "let's try and catch as many of our issues, blockers, and problems as early as we can."

The Software Development Lifecycle

Let's say you're starting a new job as a software engineer at a bank.

Your software development lifecycle may look something like this:

Example Software Development Lifecycle

1. First, requirements are provided by your Product Managers.
2. Then the analysis to complete this work is completed by your Business Analysts.
3. Designs get created for the way the UI needs to look.
4. The devs do their own planning now.
5. Then the devs begin the work!
6. Piece by piece the feature gets built and the testers can test.
7. The project goes through the environments on its way to production. It passes dev. It passes test. It reaches pre-production, and is released to production.
8. The project enters a maintenance period. You check for any issues in your logs, you fix any bugs that arise.

A few examples of shifting our work left in this cycle, would be the following:

• Checking the requirements by the technical team to make sure everything asked for can be completed, in the timeframe expected.
• The architects get involved early in the planning stage and try to make tech documents and spot any edge cases or problems the developers might face.
• Maybe the designers make a basic prototype from the designs, to illustrate exactly what is expected.
• When the devs plan, they are given enough time to do a thorough review. It's not a short 15 minute meeting. They are expected to produce class diagrams, code architectural improvements, accurate estimates, they plan for their unit test suite, and they ensure relevant documentation gets updated.
• Testers do manual testing, as well as automated testing. They use the software like a real user would!

When do we commonly find issues?

Let's think about the times we could commonly catch a bug in a project. Try and think when you would prefer to catch an issue.

• At the end of the project, when all the code has been written, and it's already been released to production for 2 weeks
• As you release it into the pre-production environment
• By the tester on the testing environment
• As the devs are in the middle of coding
• As the devs are doing their planning
• When the designs are being created
• When the architects are making their architectural diagrams
• As the product managers are specifying requirements

The place in this timeline that you can most easily respond to the issue, lose minimal time, and quickly rectify it is right at the start. And you can help your team get there by shifting your work left.

There Are Many Ways to Catch Errors

Shift left is a phrase, but it's based on a whole methodology that helps us try and catch issues early for fast iteration cycles to deliver software.

So what are some more steps we could try that would help us shift our work left?

Beyond just planning things better, what else can we do?

• You can lint your codebase and catch typos, common errors, and bad design.
• You can introduce type checking into parts of your codebase you think would benefit from it.
• You can increase your unit test coverage.
• You can increase your integration test coverage.
• You can introduce code QA's in your team.
• You can introduce logging and metric alarms for deploys.

Just remember, the later in the flow of your project you go, the more difficult it can be to recover from an error. Catch problems as far left as you can! 😉

Because if your team doesn't find the bug, you can always bet a user will.

Conclusion

I hope this has been useful, and has explained what "shift left" means. Try to incorporate this way of thinking into your development lifecycle and see what happens.

I tweet my articles here if you would like to read more.

They don't embrace and understand abstractions in their code, or in their learning.

But what are abstractions? And why are they important?

Let's dive in!

What is an Abstraction?

In coding, developers often use abstractions to simplify a system. Abstractions are a way of hiding complicated details from the end user, and trying to simplify whatever task you're trying to do.

But abstractions can be used in more than just code, so let's start with an example.

Coffee machine abstractions

Imagine if you were creating a machine to make coffee for your users. There could be two approaches:

How to Create it With Abstraction

• Have a button that says "Make coffee"

How to Create it Without Abstraction

• Have a button that says "Boil the water"
• Have a button that says "Add the cold water to the kettle"
• Have a button that says "Add 1 spoon of ground coffee to a clean cup"
• Have a button that says "Clean any dirty cups"
• And all the other buttons

Can you see how, when we use abstraction, we don't expect the user to know how the machine makes coffee? But in the machine without abstraction, the user has to know in which order to press each button, which forces the user to understand how the coffee is made.

Why You Should Abstract Your Details

When we use abstractions well, we make our system/codebase/task and so on much easier to understand and use. By hiding away complicated details inside a module, class, prototype, or function, we can make a super simple way to do complicated things.

So for example, let's say we have some complex code that ends up doing lots of complex, hard to understand math. We can wrap all that logic up in a function and provide a really easy interface where you just pass in your number and the function will do the work.

Developers in all languages and across all ecosystems make use of abstractions. The NodeJS team doesn't force you to understand how to modify 0's and 1's on a hard-drive to save text into a file – you can simply call the writeFile function.

When we use abstraction, we are essentially not forcing the person who uses our code to worry about the implementation details. They can just call the function and they'll get their answer back – they don't have to worry about what the function is doing "under the hood".

That's the strength of abstracting details away in your code.

I used to work at a company with a codebase that was 4 million lines long. Can you imagine a senior developer expecting me to understand every function? Every module? Every class? I would have NEVER merged a single change in that codebase if I did!

You can create a reusable, simple to understand, and easily changeable codebase by abstracting away certain details into the correct modules/separating out your code.

An Example Abstraction

Let's try and illustrate this with a code example.

Imagine you're working on a banking app, and you keep coming across this same weird subtraction over and over again, in different places in the code.

const res = bankAccountBalance - 1200

const res = bankAccountBalance – 1500

const res = bankAccountBalance - 1400

Why do we keep subtracting random numbers from everyone's bank balance once a year?! This is so unclear, there are zero comments explaining this?! What's happening? Is this an error?

Now imagine if this feature was clearer and did this:

const minusFeesInUSDollars = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1200 (USD)
    const YEARLY_FEES = 1200;
    return bankAccountBalance - YEARLY_FEES;
}
const minusFeesInGBPounds = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1500 (GBP)
    const YEARLY_FEES = 1500;
    return bankAccountBalance - YEARLY_FEES;
}
const minusFeesInEuros = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1400 (EUR)
    const YEARLY_FEES = 1400;
    return bankAccountBalance - YEARLY_FEES;
}

The example isn't perfect, because we could remove some duplication in these functions – but we have abstracted logic into "something", in this case, a function.

Why Should I Embrace Abstractions?

I have explained abstractions so far in the context of code, but it can apply to your learning journey as well.

If you can't embrace abstractions (at least when you are starting) you will never be able to understand and excel as a developer.

Why is this the case?

Well, because there is always an abstraction beneath you, that you will be tempted to try and understand. This will ultimately frustrate you, overwhelm you, and kill your learning.

Here's an example.

1. You start to learn React.

This is going well! I'm starting to learn my first few bits of code and render some things to my computer screen. This is going well. 😊

2. You learn that React is a library of JavaScript.

Okay that's cool! I should learn a little bit of JavaScript before I start with React then. I'm going to stop learning React, and learn vanilla JavaScript first.

3. You learn JavaScript is a programming language made up of lots of different pieces.

Okay this is getting more complex now. There are JavaScript engines, third party API's, different runtimes. This is getting confusing.

4. You try to understand how an engine interprets JavaScript code.

Okay! So your JavaScript code is being run, by a piece of software coded in C++. What is C++?

5. You start to learn C++.

This learning journey isn't going so well anymore. This is starting to get very confusing and much longer.

6. You learn that C++ is simply an extension of C.

What on earth is C?!

...and so on.

If you continue to dig deeper and deeper and deeper, into every tiny little detail, you are much more likely to quit your learning journey, and it will only be because you feel overwhelmed.

And if by some miracle you haven't given up, you're going to spend a much, much longer time trying to learn some basic skills you might need for a job.

How Do You Embrace Abstractions?

As you're learning, you're going to have to get comfortable with not fully understanding some things in your learning journey.

You can just "abstract" this knowledge away, and stick to the things that are relevant to what you're currently doing.

Don't chase down every tiny little detail that you encounter if you are new in your learning journey. Truth is, even the experts don't know everything! They normally know lots of things in a narrow area.

One Day You Can Dig into the Abstractions

I don't want this article to come across like I am saying you should never delve below the abstractions you use everyday. But what I am saying is it won't help you to delve into the abstractions before you have spent a decent time coding first.

You should try to learn things as you need to learn them if you are early in your journey to become a developer.

After all, learning to code is hard enough, without committing to learning the entire ecosystem before even understanding the basics.

Once you start to become comfortable in your learning journey, and want to improve your skills, then learn how your abstractions work.

Conclusion

I hope this has been useful, and is encouraging if you are feeling overwhelmed with everything you're currently learning.

I tweet my articles here if you would like to read more.

There is some work "under the hood" to ensure that, when you type in a human friendly name like Google, it takes you to the website you're expecting it to.

So, what's happening under the hood?

What are URLs?

You may be familiar with what a URL is. It's a simple link to a bit of content on the web. People use URL's daily to share videos, pictures, sites, articles – almost anything on the internet.

URL is an acronym for Uniform Resource Locator, and we can break them down into multiple smaller "pieces". Here's what makes up a standard URL:

Anatomy of a URL showing the Scheme, Domain Name, Path, and Parameters

A URL is just an address for a resource. The resources differ like we discussed, but they're just pointers all over the internet to take you to content you want to view.

As you can see in the graphic above, the breakdown of a URL is often:

• Scheme: this is the protocol a browser uses to access your content. Normally for websites it's HTTP (insecure), or HTTPS (secure).
• Domain name: the website name ("www.google.com" here)
• Port: a network port (80 in this example)
• Path: a path to a particular resource on the server
• Parameters: often key-value pairs, to serve extra data to the web server.

What are IP Addresses?

Humans and computers navigate the web very differently. Whilst most humans use URL's like we just discussed, to communicate between computers, computers use the Internet Protocol (IP).

The IP is a set of rules that route and address data packets (all the data you want to view) to make sure it arrives to your computer.

The Internet Protocol relies on devices and domains, all having their own IP address to connect and identify all the different segments (packets!) of the internet.

An IP address is a series of standardised numbers that range from 0 to 255 – separated by dots.

If you want to see IP addresses in action, and are familiar with terminals, you can type ping google.com in whichever terminal you like and you can see the IP address of Google.com.

A screenshot from a PowerShell terminal, showing a ping command to 216.58.212.206, and 0% packet loss.

You can test this further by typing 216.58.212.206 directly into your browser and seeing if it takes you to Google.

Hopefully this small example highlights why we use URL's. If both addresses (IP address and domain name) took you to the same place, would you rather be asked to remember Google.com or 216.58.212.206?

Note that some IP addresses change day to day (called dynamic IP addresses) – so the above IP address may not work, depending on if the IP address is dynamic or static.

Static IP addresses are ones that don't change – but to assign a single IP address to every machine would be impractical. It would be a logistical nightmare, too, as some people only log onto computers once a month to send an email, for example.

We could very realistically run out of IP addresses on today's current technology if we gave every device a unique IP address (if you want to read how IP addresses are allocated in greater detail, read here).

What is a DNS?

If we know computers communicate via the Internet Protocol and communicate using IP Addresses, how do we turn google.com into the website we use so regularly?

The answer is using a Domain Name System (DNS). The job of the Domain Name System is to transform human readable domain names into IP addresses.

There are four servers specifically that we'll discuss.

DNS Recursor

A DNS Recursor is like a waiter in a restaurant. It acts like a "front facing" part of the system to receive orders (normally from browsers) where the waiter then heads into the back to get what is needed.

In reality, it's just a server that receives DNS queries from browsers and returns information.

There are 3 different places the DNS recursor can generally get the information from depending on if any data has been cached:

• Root nameserver
• TLD nameserver
• Authoritative nameserver

So let's discuss them one by one.

What is a Root Nameserver?

The root nameserver's main job is to return the Top-Level Domain (TLD) server. **

This is an important step to map hostnames into IP addresses.

The root nameserver essentially acts like a catalogue that points to more specific locations.

What is a Top-Level Domain (TLD) Server?

If the root nameserver acts like a catalogue, the TLD server acts like a page in a catalogue.

The TLD server generally returns the final part of the host-name, like com for example, in "google.com".

What is an Authoritative Nameserver?

This server is like a row entry on the specific page of the catalogue.

The authoritative nameserver now can return the IP address for the requested hostname from the browser, back to the DNS recursor – which can hand it back to the browser.

DNS can be super confusing, and to understand the whole process may take a little while, so let's tie it together with a final example.

Example Request

Let's break down an example request from a user, and hopefully tie together this pretty complex process.

Each step in the flow starts to point closer and closer to the final address the user will eventually end up hitting.

Diagram showing the steps in the request process

Let's break down what's going on in this graphic:

Step 1:

A user types 'kealanparr.com' into their browser, and the query hits the DNS recursor.

Step 2:

The DNS recursor then queries a Root nameserver

Step 3:

The Root nameserver then responds to the DNS recursor with the address of a Top Level Domain server (TLD) such as .com.

Step 4:

The DNS recursor then makes a request to the .com TLD.

Step 5:

The .com TLD server then responds with the IP address of the Domain’s nameserver, kealanparr.com.

Step 6:

The DNS recursor sends a query to the domain’s nameserver.

Step 7:

The IP address for kealanparr.com is then returned to the resolver from the Domain nameserver.

Step 8:

The DNS recursor responds to the web browser request with the IP address of the domain requested.

Step 9:

At this point, the DNS lookup has returned enough data for the browser to make the request for the web page.

• The browser makes a HTTP request to the IP address.
• The server at that IP returns the webpage content to be rendered in the browser.

Conclusion

I hope this article has helped you to understand a few networking principles that affect the websites you use everyday.

IP addresses, DNS, and more are all technologies most people use daily but may not be very familiar with.

Cloudflare has an article that was helpful as I researched for this article, which you can read here.

I tweet my articles here if you would like to read more.

And you may know that HTML is a language used to create websites – but what does markup mean?

Markup languages are languages that use tags to define different elements within a text document. Most people are familiar with Rich Text Editors – programs that allow users to add extra formatting, images, and links to their documents.

A screenshot of the GUI of the Microsoft Word software (a Rich Text Editor).

But markup languages use tags like:

• is a paragraph tag.

• makes bold text.

There are quite a few markup languages like XML, HTML, and the topic of this article: Markdown.

Developers generally use markdown for documentation – and it is often included in most repositories. For example, I used markdown to write this article on freeCodeCamp.

So let's look at all we can do with markdown.

Disclaimer: There is no unifying body or specification to standardise markdown – just some widely accepted best practices. So your mileage might vary depending on what markdown parser you're using for this cheat sheet.

Markdown Cheat Sheet

Here are some of the most commonly used methods for manipulating text in markdown.

How to Create Headers in Markdown

There are six markdown headers, H1 thorough to H6. I'll show you how it displays visually, and also the way you create it using markdown.

H1's are the biggest and generally are the "main" headers, and each header after H1 gets smaller.

H1 tag

# H1 tag

H2 tag

## H2 tag

H3 tag

### H3 tag

H4 tag

#### H4 tag

H5 Tag

##### H5 tag

H6 tag

###### H6 tag

How to Add Typographical Emphasis in Markdown

The ways you commonly add emphasis with text are bold, italics and strikethroughs. Combining too much emphasis can make words much less clear, so choose carefully how you want to emphasize each bit of text.

There are also subscript and superscript notation that you'll use to write the names of various chemical compounds, for example. You may also use them as part of mathematical notation.

How to make text bold:

Add double asterisks around your text. It'll make that text appear bold. Like this: **Bold text**

How to make your text italic:

Add single asterisks around your text to make it appear in italics, like this: *Italics*

How to Strike through certain text:

If you want to "cross something out" in text, use the strikethrough method, like this: ~~Strike through~~.

How to Write Subscripts in Markdown

If you want to write the chemical symbol for water, for example, you can make a subscript "2" by typing H~2~0.

This results in: H₂0.

How to Write Superscripts in Markdown

Say you want to write an exponent - or superscript. You do that like this: X^2^ which results in this: X².

How to Make Lists in Markdown

There are multiple types of lists in markdown. For example, you can have ordered lists and unordered lists.

Ordered lists are commonly used when you want to follow steps in a certain order (like following a recipe: cook the chicken...serve the dish). But unordered lists work well for things that don't require sequential steps like a recipe (a shopping list, for example).

How to Make an Unordered List in Markdown

This is how the unordered list looks.

• Chili oil

• Rice

• Spring onions

And this is how you create it in markdown:

- Chili oil
- Rice
- Spring onions

How to Make an Ordered List in Markdown

This is how the ordered list looks.

1. First item

2. Second item

And this is how you create it in markdown:

1. First item 
2. Second item

How to Create Links in Markdown

The two most common ways of linking things in markdown documents is either by hyperlinks or images. Both can help make your writing much clearer and more eloquent, and should be used where appropriate.

Here's what a hyperlink in text looks like:

Kealan's site

And here's how you'd create that link in Markdown:

[Kealan's site](https://www.kealanparr.com)

You put the text you want to link in square brackets (here, "Kealan's site"), and then immediately follow them with parenthesis containing the URL.

Say you want to include an image in an article. To get it to appear like this:

You simple use the following notation:

![View of natural rock landscape formations making a valley ending in a road crossing through with a blue sky.](https://images.unsplash.com/photo-1660866838784-6c5158c0f979?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=387&q=80)

It's similar to a regular link, but you include the exclamation point before the brackets.

How to Use HTML in Markdown

You can use regular HTML in Markdown documents (depending on the parser that's being used).

So feel free to just input any valid HTML you like.

How to Add Spacing in Markdown

If you want to add a horizontal line to divide up sections of a document, you can make one like this:

By using three dashes like this:

---

How to Create Tables in Markdown

Tables come in handy in your articles. To make a table that looks like this:

Here's the notation you'd use:

| Name   | Age |
| ------ | --- |
| Kealan | 25  |
| Jake   | 28  |

The only real "gotcha" you have to be aware of when making a markdown table is that you keep the pipes (|) vertically in line. Then your markdown table will appear as above in this article. An image to make that clearer is:

A markdown table is displayed, with Name and Age as the headers and Kealan, Jake and 25 & 28 as the values.

How to Add Code and Syntax in Markdown

Adding code snippets to your markdown can be incredibly helpful if you are creating documentation for developers, for example.

The below is a very simple JavaScript example, but almost all modern programming languages are supported (with syntax highlighting and so on).

console.log('example log')

console.log('example log')

Just type the three backticks followed by the programming language and then enter to start writing your code. End the code block with three backticks.

How to Add Quotes in Markdown

When you reference someone else's work, it is expected and courteous to credit them. One easy way you can do that is by quoting them.

If you want to add quotes in markdown:

"This is a quote, from someone who is very wise" - Anonymous

Just add this symbol, which renders it like the above quote:

> "This is a quote, from someone who is very wise" - Anonymous

Conclusion

I hope this has been a useful reference for you, and that you've learned a new feature of markdown you hadn't seen before.

There are lots more features (not even counting all the HTML variations you could create), but this article has covered the most used features.

We can guarantee that certain properties or functions are present in our code by making them conform to types.

This can hugely reduce the amount of client-side errors you might have in your website, because it reduces human error bugs like calling functions on the wrong objects, for example.

TypeScript does this by utilising Collective Types and Literal Types.

So, what's the difference?

Collective Types in TypeScript

Collective Types are a concept that are familiar to most developers who work with TypeScript. For example:

const addOne = (numb: number) => num + 1;

This code uses Collective Types.

Collective Types are types like number, string, boolean or number[].

These types encompass a huge amount of variables present – the number type for example can cover: 1, 2, 3, 4, 5...and so on.

But TypeScript also offers us sub-types on these Collective Types that are stricter.

Literal Types in TypeScript

You can also use values as types, so let eleven: 11 = 11 is totally valid TypeScript code.

When I first saw this, I thought it looked a little weird.

But it is used heavily, and can really make your code more readable.

You can start to construct enum-like types, and strictly only allow certain values to be assigned, for example:

type Door = 'open' | 'closed' | 'ajar'

The Door type can now be used throughout your code – with a stricter set of values than the string type would have allowed.

If the | in the above code is unclear, it is a Union Type – and essentially means OR. Any type that conforms to Door can only be open OR closed OR ajar.

Conclusion

Literal Types are sub-types of Collective Types.

We can say all Literal Types are Collective Types – but not all Collective Types are Literal Types. To make that clearer, we could say the Literal Type 11 is a number but not all number types are 11.

I hope the difference between the two types is clearer now, and if you need to constrict types strictly, you can make use of Literal Types.

I tweet my articles here if you would like to read more.

So what exactly is transpiling, and what is type erasure?

Higher Level vs Lower Level Programming Languages

Before we explain further, we have to understand higher and lower level languages.

Higher level languages are more abstracted than lower level languages. By abstracted I mean they're easier for humans to understand.

For example, you would say machine code (binary) is lower level and closer to the computer than JavaScript. Higher level languages generally are more simple to write and understand than writing lower level languages (Assembly for example) where you have to understand and deal with memory addresses directly, and so on.

Compilation and transpilation are very similar steps, but they're not identical. I'll explain both so you know the difference.

What is Compiling?

Compiling is a catch-all term for turning code that you've written into some lower-level executable for the computer (generally machine code).

An example of some compiled languages are Java, C# or C. Sometimes it's compiled in multiple steps, each step optimising the code and getting it closer to machine code with each "pass" it does.

Through this process, a high level, closer to human readable language ends up "lower" or closer to binary.

What is Transpiling?

Transpilers are sometimes referred to as "source to source compilers" – so, a short hand way of saying "source code to source code". Transpiling means converting one higher level language to another higher level language.

For example, TypeScript is a high level language but after it's transpiled it's turned into JavaScript (another high level language). Or Babel for example can transpile ES6 JavaScript code into ES5 JavaScript.

The benefits of transpiling are that you can write one high level language and still end up with another high level language.

Type Erasure in TypeScript

Part of this transpiling process is called type erasure.

Type erasure is quite simply when all the types get removed from the TypeScript code as it is transpiled to JavaScript.

The types you use in TypeScript can't be inspected at run-time, when JavaScript is being executed. The types are only accessible during the compilation/transpilation step.

TypeScript code that looks like this:

let name: string = 'Kealan';

Eventually gets compiled/transpiled to this:

let name = 'Kealan'

The output might vary depending on your specific build steps (the variable may be renamed, or inlined) but the example of type erasure still stands true.

This isn't just with primitive types like number or string – but even with your own custom types you may create:

type StringType = string;

const firstName: StringType = "Kealan";

Type Erasure in practice

More than just conceptually understanding what type erasure is, this concept explains an important step in the transpiling process where types are thrown away and aren't used in the source code you generate.

It also means that pieces of your code aren't even "used" in JavaScript during the transpiling step – and the code is just completely removed. So your 100 line interface you create just gets removed, and the code sent to the user is smaller.

You can look at an example of this in the TypeScript playground, where an interface used in the TypeScript code is absent in the transpiled JavaScript.

Conclusion

I hope some of the steps TypeScript takes to turn your code into JavaScript are a little clearer, and that you have a good overview of the differences between compiling and transpiling.

I tweet my articles here if you would like to read more.

You need to move some folders higher, move some other folders lower, and move lots of files into some new folders you're going to create.

You start shifting the code around, checking that everything works, and adding some folders that the next project is going to need.

These new folders are empty at the minute. But the next project starts in 2 days and it's best if you add these new folders since you're already moving the codebase around.

You push everything into your project branch and you're ready for someone to QA it. So you tell the code-reviewer you're finished on Slack.

They then clone your branch, and fail your code-review because you forgot to add all the new folders you promised to add.

Wait.... what?

What happened?

git can't push empty directories. It can only track files.

If you try to push a folder with nothing in it, although it will exist on your local machine, nothing will go into your branch.

So if someone tries to clone your code, they won't have the same folder structure as you do on your local machine.

So if it doesn't work, what do you need to do?

How to Use .gitkeep

Now we know that Git only tracks files, so we know we need to add something to the folder.

You can add anything. You just need to add a really simple dummy file to make sure that the folder is tracked, and will be pushed.

You could copy and paste a text file file.txt with nothing in it, and that would work. You could put a PNG image of a cat.

A common, standardised practice to solve this exact issue, however, is to push a file called .gitkeep into your empty folders.

This isn't a feature of Git! So you could name it anything. There's nothing special about the name .gitkeep – some developers add .gitignore instead, for example.

.gitignore is a little confusing, though, as you are trying to make git not ignore your file, and actually push it into your branch.

Either way, by adding this simple file to your folders, they'll get pushed when the time comes.

Conclusion

.gitkeep is a common thing you will see in codebases, where an empty folder needs to be tracked via Git.

The name of the dummy file may not always be .gitkeep but you'll see the actual practice over and over again as a developer.

I tweet my articles here if you would like to read more of my writing.

Whether it's a physical feat like reaching a new best lift or a mental challenge like learning a new language – both entail months of work, multiple setbacks, and hundreds of hours of time put in. And then you still might just be at an intermediate level.

Spending hours failing over and over again, before finally being able to do it effortlessly, is the route ahead for any beginner.

But being bad at something isn't fun.

It's hard to continue doing something you're struggling to do.

It's hard to keep coding regularly when you feel like you're making no progress with your buggy code and worse yet, aren't sure how to improve your situation.

The only way to get better is to...keep getting stuck and just persevering? That doesn't sounds very encouraging.

But that is exactly what is necessary for you to become great.

I think learning to code is especially hard, as it is so different from most other activities, and sometimes it's hard to see which of your other skills might be transferrable to programming.

But because coding is challenging to do and can be so frustrating is exactly why you should do it.

Why it's good to do hard things

Strangely, life gets harder when you try to make it easy. Exercising might be hard, but never moving makes life harder. Uncomfortable conversations are hard, but avoiding every conflict is harder. Mastering your craft is hard, but having no skills is harder. Easy has a cost. – James Clear

I have found that the biggest leaps in my character, technical skills, and personal development normally come from something difficult I have to face.

There's this false idea amongst new developers that generally experienced developers know exactly what to do, and just "do it".

I haven't found that to be the case at all.

I have been coding for 4 years and recently wanted to create an automated job that would run a Node script monthly. Then at the end of the Node script running, it would commit the file with all results to a repository on GitHub.

I got it all wired up pretty quick, but couldn't work out for days why this script wasn't committing anything into my repository.

I was trying to work out if the Node script wasn't running, or if it was running but wasn't committing.

I tried what felt like everything. I contacted developer friends. But they had no idea what was wrong either.

Everything worked on my machine, why was this so hard?

I finally solved it. The machine that was running my Node script was a different OS than what I was using (it used Ubuntu) and was a case-sensitive shell, whilst my shell wasn't case-sensitive.

So although it worked on my machine it "blew up" on the other machine as I had the casing of the file (that I wanted to commit with all the results in it) wrong.

Here's the commit where I fixed it.

In that moment I just wanted the bug fixed.

I was sick of not being able to properly debug the issue, as I didn't have access to the machine that was running my code. I felt like I was guessing as the feedback loop was so slow.

But now that I have experience doing this, I know how to optimally debug these types of situations again.

The only thing I'm trying to show you is that the only way to improve is to struggle and work things out. No matter how slow it feels.

In my experience, the only difference between the state I was in as a newbie coder who "didn't get it" and the state I'm currently in is that I just didn't quit.

Investing in Loss

There's an excellent way to frame "getting better means struggling, persevering and not giving up" called Investing In Loss.

If you want to get good at something, you need to spend a lot of time being bad at it. View loss as an investment, rather than something to avoid.

This concept is from the book The Art of Learning.

To master any new skill, you need to go through a prolonged period of being bad before you can be good.

Each new part of software feels like a whole new world you have no experience with: deployments, networks, coding, data-structures, documentation, the list goes on. And there are multiple times – even when you're experienced – that you'll feel like you're a beginner again.

Often times the thing holding us back is our expectations of where we should be and losing patience with the process before we have finished it.

If you're good at other things, going back to being a beginner is jarring.

But you need to focus on viewing the loss as an investment – and not giving up too soon.

Don't quit!

I have not failed 10,000 times. I have not failed once. I have succeeded in proving that those 10,000 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work. – Thomas Edison

There are always times to cut your losses, but if programming is something you sincerely want to improve in, either for a new career or for pleasure – don't give up.

When I first started learning JavaScript, I spent time coding in the Eclipse code editor as I thought Java was the shorthand name for JavaScript.

If you aren't aware, they're not the same, and that editor doesn't (natively) work with JavaScript!

There have been countless times when I was a newbie, where I have gone through interviews and felt like I completely failed them, only to be surprised later when I got a job offer.

Remember the reason you first started learning and just keep going. Any progress no matter how small, is valuable.

Conclusion

I remember so clearly years ago a time when I was coding on freeCodeCamp and was very disheartened about how stuck I was on a particular problem.

I read this article, and it was one of the many articles that formed my opinion on this topic, inspired me to keep going, and to write my thoughts in this article.

If you're a newbie coder, I wrote about steps I took to improve as a developer here and maintain a list of high quality coding resources here.

I tweet my articles here if you would like to read more of my writing.

The Software industry is obsessed with the idea of 10x engineers. These are engineers who are supposedly 10 times better at their job than their peers. But how does anyone become so talented?

"The best programmers are not marginally better than merely good ones. They are an order-of-magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design, or problem-solving ability." – Randall E. Stross

Here are four actionable steps I have used myself, or seen others use to succeed in improving their skills.

If you are new to programming, I think this is a great thing to read first.

Teach and Write as Much as Possible

“What many people underestimate is that being a good writer, whether that is through emails or through documents, allows you to be more impactful. I see many engineers ignore that skill.

You might be proud about your code. You should also be equally proud of the craft of writing… Writing is a highly underestimated skill for engineers.” – Urs Hölzle (Google’s first VP of Engineering)

You are the person who's the most responsible for your skills and development. Being a better developer is largely up to you. It's your job to improve your weaknesses and hone your craft. Being a better developer is an ongoing process that never stops, and writing helps you learn more.

By writing, you force the boundaries of your comfort zone. You learn about new topics to discuss, and you "put yourself out there". You start a discourse where when you're wrong, people are very happy to correct you and offer feedback.

The best way to become a better engineer is to teach 10 people what you know, and empower them in their development skills.

Put your expertise online and open source what you know. Your technical writing acts as portable capital as you move job to job, to show the depth and breadth of your knowledge. Writing not only showcases your skills, but develops them, too.

Read A Lot

Mark Twain said that the person who can read good books but chooses not to do so has no advantage over the person who actually can't read a book.

Reading is such a powerful tool. Read a big well documented open source codebase, read technical books, read your colleague's code and read technical documentation.

Find the brightest minds on Twitter, engineers with decades of experience and people who create the specs you love. Be a fly on the wall for their conversations.

As a starting challenge, change your watch preferences on a codebase you are most familiar with (a work repo, or an open source one). Then review and read every change (or as many as you're comfortable with) that goes into master/main.

If there is syntax/code you don't understand or can't work out, ask the person who did it. Learn from everyone. It will help the coder clarify what the code is doing (if you can't work it out, it mustn't be very clear!) and will help you have more context on the changes for the ecosystem you work in.

Work on Passion projects and/or Contribute to OSS

"We are what we repeatedly do. Excellence, then, is not an act, but a habit." – Aristotle

One of the largest jumps in my skills and confidence came when I made my first major program that visualised path finding algorithms. I started with Djikstra and did A* too.

It forced me to:

• plan something out start to end
• give estimates
• hold myself accountable
• work on new API's I was unfamiliar with
• plan out my own architecture
• consider how to implement clean design patterns

If you aren't sure where to start, that's ok. Here's a link to lots of public API's you can dev against, or some project ideas I collated here.

If you haven't got a personal website, start there!

Even just publishing my personal project was an amazing educational experience in itself. You end up learning the entire SDLC start to end, and fill in the gaps in your knowledge.

For me it was deployments and CI builds that I didn't know a lot about (I use Netlify). Working out things like:

• How do you want to test your project?
• How will you release it?
• Do you want automated builds?

• Do you want to buy a domain for it?

  You begin to self-educate in an intensely practical way, as you have an end goal in sight – getting the thing online!

Everyone's passion projects look different. Plough away on some open source project for a few months, and see how much you grow. When you begin to interact with people from different countries, who have their own formed opinions and who don't know you, you can't help but learn from your mistakes.

You get the added benefit of identifying one smart person you get on well with, from whom you can glean valuable insight based on their years of coding and expertise.

If this works well for you – that is, having someone with whom to discuss your tech progress – you can apply for a mentor (for free) here.

You don't even have to code an entire program or app, but just work on something that you enjoy. Solve Leetcode problems or Codewars katas. Write a compiler and a language. Or read through almost 400 ideas here.

The biggest jumps in growth came when I had a few small projects I was trying to implement. Having lots to do (that I enjoyed!) forced me to adapt to become more time-efficient and made me code quicker.

Make Sure to Exercise and Get Plenty of Sleep

"It is a shame for a [person] to grow old without seeing the beauty and strength of which [their] body is capable." – Socrates

Exercise helps your memory and your thinking, directly and indirectly. The direct benefits of exercise are many, but among other things it:

• allows your body to reduce insulin resistance and inflammation
• stimulates chemicals in your brain to affect the health of brain cells
• encourages the growth of new blood vessels in the brain, and
• even increases the quantity and survival rate of new brain cells.

Indirectly, it can help you improve your mood and sleep and reduce stress and anxiety (which, research indicates, can impair cognitive function).

Studies have also suggested that the prefrontal cortex (clarity of thinking) and the medial temporal cortex (memory) have greater volume in people who exercise versus people who don’t.

Just as it's important to look after your mental health, you need to look after your physical health as well. IQ drops off as we age, and one theory is that the amount of oxygen our brain receives slowly declines if we get old without staying in good cardiovascular health.

Conclusion

My final bit of advice that ties all of this together is to try and consistently challenge yourself.

There is a middle ground while you're working normally referred to as flow. It happens when you're feeling fully energized and "in the zone".

If you start something too difficult you won't complete it due to feeling overwhelmed. If you start something too easy, you won't complete it due to boredom.

You need to do your best to balance something being difficult enough to challenge you to learn new things and make you grow your skills versus being bored to death doing something well below your skill level.

This is hard to accomplish when you first begin, because everything just feels too difficult. If you find yourself here, I'd recommend starting the freeCodeCamp curriculum at the very beginning and working your way through the certifications.

Keep a notebook of ways you can grow and what you would have done differently when you make mistakes. Be kind to yourself, and keep moving forward learning all the way.

I tweet my articles here if you would like to read more of my writing.

There are a few different incarnations of it – some have slightly different wording, different names, or change the items in the riddle slightly. But they are all the exact same core problem.

The riddle itself is used as a benchmark in the evaluation of constraint satisfaction problems for computer algorithms.

What is the Einstein Riddle?

Even the origin of it the riddle is a little unclear. It's famously known as the Einstein Riddle because it was supposedly created by Einstein as a young man for fun. Others say it was used by Einstein to only select the smartest PhD students he would supervise.

But there are some claims online that it actually was invented by the author of Alice's Adventures in Wonderland, Lewis Carrol.

It's highly unlikely that it was written by Einstein, but that doesn't really matter. What's important is that, with a basic understanding of truth tables (and a bit of patience), you can solve it, too.

How to Solve Einstein's Riddle

I'm now going to give you a list of clues, and then you will need to answer a question at the end of the clues.

Just to be absolutely clear, all the clues are enough for you to solve it. You don't need any extra hints, and there aren't any assumptions I expect you to know.

There are 5 houses painted five different colors.
In each house lives a person with a different nationality.
These five owners drink a certain type of beverage, smoke a certain brand of cigar, and keep a certain pet.
No owners have the same pet, smoke the same brand of cigar, or drink the same beverage.

• The Brit lives in the red house
• The Swede keeps dogs as pets
• The Dane drinks tea
• The green house is on the left of the white house
• The person who smokes Pall Malls rears birds
• The owner of the yellow house smokes Dunhill
• The green house’s owner drinks coffee
• The man living in the center house drinks milk
• The Norwegian lives in the first (leftmost) house
• The man who smokes Blends lives next to the one who keeps cats
• The man who keeps horses lives next to the man who smokes Dunhill
• The owner who smokes BlueMaster drinks beer
• The German smokes Princes
• The Norwegian lives next to the blue house
• The man who smokes Blends has a neighbor who drinks water

Now to solve, tell me who owns the fish?

I solved it, but it did take me a couple attempts and a bit of scribbling on paper.

How I Approached the Problem

To solve the problem, the first thing I did was to try and group together the clues. There are two references to the green house in the clues, so I tried to "solve" and consider those two clues together when I was able to.

I then also filled out the center house's beverage as one clue immediately tells you, and I was also able to immediately fill out the leftmost house's nationality.

I essentially drew a really basic grid and eliminated and filled in possibilities based initially just on the clues. Then as I filled in more, I was able to fill in more details on other houses.

I don't want to keep going with the hints if you want to solve this for yourself, but that's a starting point.

A screenshot of part of a 5x5 table with every different possibility of Nationality, Color, Beverage, Pet and Smoking Cigar that can be removed on click.

To try and make it easier for anyone who wants to solve it or check their answer, I have made a basic site you can find here: http://einsteins-riddle.com/ – the screenshot from above is a part of the grid on the site.

On that site, you'll find a table with all the options laid out as clickable buttons. The grid is initially filled out with all the possibilities, and as you learn more you can remove possibilities until eventually there is only one option left.

At the bottom is a "Check Answer" button that will evaluate what you have left on your grid.

Try and solve it and see how you get on! If you prefer to do it via paper please do so.

I wish you luck 😊

If it stumps you, and you want to know how to solve it, you can find the solution here.

Why are Truth Tables Helpful?

I enjoy trying to work through these truth table problems, as it helps improve my clarity of thought.

Sometimes when I'm coding and need to carefully consider some complex Boolean states in my code (not this, and not that OR this and that (and not those)) I think that these puzzles help me reason more clearly to simplify my code.

They also help me technically plan out my approach to a problem, from the very beginning to the eventual solution.

I start from a basic set of requirements and no idea how all they fit together. But as I move along, I can go through a process of fact finding, checking edge cases, verifying/testing my logic against the requirements and finally submitting my work. All of these steps translate exactly to software development.

Whenever you have a complicated set of states you are confused by, draw a basic truth table. Or however you want to represent the problem. Breaking it down into smaller and smaller problems will allow you to solve almost anything.

Conclusion

I hope this has been an enjoyable brain teaser, and that you solved as much or as little as was fun for you.

I share my writing on Twitter if you enjoyed this article and want to see more.

Some parts of the codebase last longer than other parts, but inevitably new coding standards emerge to reduce technical debt. Then you have to rework a large application, with zero downtime, making a "new way" of working without breaking anything in your release or development.

The Strangler Fig Pattern is one effective way to solve this problem.

What is a Strangler Fig?

The name Strangler Fig Pattern actually comes from a collection of plants that grow by "strangling" their hosts.

They grow in areas where competition for light is intense, and they have evolved to have their seeds dispersed (normally by birds) to the top of a host tree where they can get sunlight easily.

Their roots grow down around the tree and the seedlings grow upwards to consume all the sunlight they can. This "strangles" the tree and the fig seedlings can often kill their host tree they landed on.

Here's an image of a Strangler Fig, which I found on Wikipedia .

_An image of a strangler fig, where the roots grow down the tree trunk to the soil whilst the seedlings grow up above the trees canopy. Source._

So how does this apply to software? 🤔

What is the Strangler Fig Pattern?

To completely re-write a large, complex codebase with lots of different interactions often with different teams results in a planning nightmare.

In big complicated brown-field projects like this, going big-bang (where everything is released at once) generally forces you to:

• understand every interaction in depth to ensure you won't break anything when you release
• have all new bug fixes done both in the new and old codebase as you re-write it
• keep both merged and up-to date
• spend weeks in test
• deal with tons of callouts and out of hours support for the new codebase's rollout

To top it all off, it normally ends with developers doing a lot of overtime along with an influx of bugs.

One big difficulty we are trying to remove when we use the Strangler Fig is making whoever is using your software aware of where your new software is now accessible.

When you are rewriting your backend, for example, if you put everything on a new endpoint and kindly ask your users to point to your new endpoint. But then if something goes wrong, you may have to ask them all to point back to the old one.

You may end up going back and forth between these two endpoints if you have really difficult bugs, which might frustrate your users.

When we use the Strangler Fig pattern we can avoid all the above.

Why Strangle Our Code

The Strangler Fig pattern aims to incrementally re-write small parts of your codebase, until after a few months/years, you have strangled all your old codebase and it can be totally removed.

The rough flow is: add a new part to your system that isn't used yet, switch on the new part of the code – normally with a feature flag so it coexists with the old code – and finally remove the old code.

Benefits of the Strangler Fig pattern

Aside from helping you avoid all the issues we've already discussed, it also:

• reduces your risk when you need to update things
• starts to immediately give you some benefit piece by piece
• allows you to push your changes in small modular pieces, easier for release
• ensures zero down time
• is generally more agile
• makes your rollbacks easier
• allows you to spread your development on the codebase over a longer period of time if you have multiple priorities.

There are multiple ways of implementing the Strangler Fig pattern and it depends on the system you're removing, and so on. So let's get concrete and cover an example.

Façade Payment Provider Example

Let's say as an example you have a huge monolithic back-end codebase to handle payments. It is huge. A few million lines of code, with multiple endpoints, that you want to re-write into something new for your company, for a multitude of reasons.

Performance is now poor, the architecture is too confusing to onboard new developers, and there is lots of dead-code you need to remove but don't want to break anything.

Breaking a huge codebase involving customer payments might just cause the unlucky developer who pushed up last to lose their job!

Okay. How do you slowly choke out this old codebase? Even more tricky, you don't want to just put a new endpoint there and force everyone to move. You have hundreds of customers using this software, they can't just flip back and forth between your endpoints if you have bugs and need to rollback.

Just to add one last challenge, you don't want to change your interfaces to these endpoints either. Everything being passed as arguments or returned should remain the same.

The Strangler Fig Pattern-based Solution

We can create a façade that intercepts requests going to the legacy endpoints.

The new façade will hand off to the new API you've written, or hand off to the legacy API if you haven't rewritten that piece of the codebase yet.

This façade is essentially a shim to catch network requests and hand them off to the right place.

You can then gradually migrate across to the new API piece by piece, and your users will be unaware of any changes to your underlying code as you have correctly abstracted it away.

If you are doing this correctly you will generally:

• Just have the legacy way at the beginning
• Make the new API
• Make it coexist with the legacy API, where you can turn it on and off with feature flags
• Move more and more across to the new API
• Delete the old way when fully migrated

The strangling part is happening piece by piece where you remove more and more responsibility from the legacy API and into the new API.

Conclusion

I hope this has explained what the Strangler Fig Pattern is along with some of its benefits.

I have seen this pattern used in real software projects and it works really effectively. It was easily one of the most complicated projects I worked on and the Strangler Fig made it so much easier.

It stops you from writing software projects for months, and then crossing your fingers and sending it to production whilst hoping you haven't forgotten anything.

There were two invaluable resources that were very useful when I was writing this:

• Strangler Fig Application by Martin Fowler here, and
• Avoid rewriting a legacy system from scratch, by strangling it found here.

I share my writing on Twitter if you enjoyed this article and want to see more.

There are multiple ways to get third party code included and updated. And I read something recently which has easily become my favourite way of doing this, so I had to share it.

This method is to Always Shim Your Abstractions.

To properly break down what this means, let's define each word before we talk about the bigger idea that it encompasses.

Abstractions

Developers often use abstractions in code to simplify a system.

Abstractions are a way of hiding complicated code inside something, and they normally provide an easy interface to use it.

So for example, let's say we have some complex code that ends up doing lots of very specific math. We can wrap all that logic up in a function and provide a really easy interface where you just pass in your number and the function will do the work.

We are essentially not forcing the person who uses our code to worry about the implementation details. They can just call the function and they'll get their answer back – they don't have to worry about what the function is doing "under the hood".

That's the strength of abstracting details away in your code.

You can abstract things away in a multitude of data structures or code architecture. And you can abstract implementation details inside a prototype, class, function or more.

If you had to understand every single line of code in a big codebase (let's say a 2 million line codebase) you'd never be able to start coding.

You can create a reusable, simple to understand, and easily changeable codebase by abstracting away certain details into the correct modules/separating out your code.

How code abstraction works

An example of abstracting away logic would be: imagine if you were creating a machine to make coffee for your users. There could be two approaches:

How to Create it With Abstraction

• Have a button with the title "Make coffee"

How to Create it Without Abstraction

• Have a button with the title "Boil the water"
• Have a button with the title "Add the cold water to the kettle"
• Have a button with the title "Add 1 spoon of ground coffee to a clean cup"
• Have a button with the title "Clean any dirty cups"
• And all the other buttons

Can you see how when we use abstraction we don't expect the user to know how the machine makes coffee? But in the machine without abstraction, the user has to know in which order to press each button which forces the user to understand how the coffee is made.

There's one definition we need to cover before we can move on and understand the concept I introduced at the beginning (always shim your abstractions), and that's shimming.

Shimming

Shimming is the act of putting something in front of something else to intercept data being passed.

Let's look at an example of how it works.

Let's say a bank has a really old API that doesn't accept JSON due to some technical legacy defect. Instead it can only accept XML. We'll call this LegacyAPI.

But a high percentage of developers who want to hit this bank API want to send JSON. The bank refuses to change LegacyAPI as it's too risky and might break the API. So much of their system depends on it, and they can't risk doing lots of new development and taking huge parts of their system down if they make a mistake.

They could always shim LegacyAPI if they don't want to do new development on it.

They could do this by creating an API that sits "in front" of LegacyAPI. We'll call it NewAPI.

The wording "in front" just means the order of who first deals with the network request. By "in front" we just mean NewAPI will be the first to receive the network requests.

You would tell the developers they can now hit NewAPI with JSON as they wanted, and NewAPI will turn the JSON into XML for the LegacyAPI and both parties can be satisfied.

The bank can now expand their services (they can accept JSON, for example) via the NewAPI without changing their old legacy API that they were wary of changing.

This is just one example of shimming. And just to review, it is essentially adding something in front of something else to act like a man in the middle to pass data to something else.

A diagram of how NewAPI intercepts LegacyAPI network requests.

Hopefully you have a good understanding of what shimming is and what abstractions are. Let's bring both definitions together to define what we mean by Always Shim Your Abstractions.

Why You Should Always Shim Your Abstractions

The problem

Whenever we need to manage our dependencies, we want to make sure we stop the third party code "leaking" all over our main code.

By "leaking", I mean that the dependency code is imported multiple times to different places that need it in your code.

If you let a dependency "invade" your source code, you are becoming increasingly tightly coupled to it each time you import it.

This can (at times!) mean you will be forced to code in the direction the library choses as you are tightly coupled to it. This may end up leading to significant cognitive overhead as you are increasingly trying to make this library work in your code, but it isn't in keeping with the rest of your architectural decisions.

This can make any refactoring you need to do take much longer than if you isolated it. For example, if the dependency changes, what arguments would it need to accept to create an object in the dependency?

In addition to it being difficult to keep your build working well with the dependency, if it no longer suits your needs or you find a better library to replace it, your refactor becomes much more difficult to actually get rid of it.

The solution

To try and stop all the above from happening, firstly let's put any dependencies we need into their own modules where they're only referenced once in your codebase.

This is in essence our shim.

Whenever you need the third party dependency, you just have to import the wrapper module we put around it, to act like a "man in the middle", to provide a level before we call into our third-party dependency.

This shim module also allows us to make our dependencies abstractions. The developers who need to use our third party dependencies can just use an abstraction instead (you'll probably end up just wrapping it in a function or simple class). You'll default the arguments to sensible defaults and try to remove as much of the nitty gritty implementation details as you can.

Anywhere else that needs this dependency will just load your module and then that module can be injected where necessary.

Why? One big reason we already discussed is that it stops your dependencies and your code from being too tightly coupled.

This works when you only have it in only one module. As long as everyone that is loading your module respects an interface/data contract for that module, everywhere else "gets it for free". Then you only have to change one module for lots of other places to get access to something.

This then allows us to make changes far more easily, and keeps a clean separation of concerns in the code.

We have only spoken here about one dependency – but you can see how much worse this may get if, for example, you are relying on 25 other custom libraries and you need to understand how they work. This would generally be a pretty fragile codebase, and would be a code smell.

HTTP dependency example

Let's look at an example of a dependency you might use that makes a simple HTTP client.

It's a basic dependency that lets you hit endpoints and pass JSON etc as data.

Let's imagine then we currently are using Fetch in Node and we want to use Axios (another HTTP client we want to now switch to). We've decided to drop Fetch and switch to Axios because our application is growing in complexity and we have found that Axios now fits our use-cases better.

If Fetch has leaked all over our codebase, then our refactor to remove it is going to be much harder than it needs to be.

Rather than just go to our one module where we shimmed the function call, we now have to go to every place where we use it. This creates a domino effect in the source code that inevitably will occur from changing something in multiple places.

// You're now going to have to find any place you imported fetch
// Any place you alias'd it
// And deal with any source code failures wrapping around where you have used it once it's removed
// Which might be more complex than just simply searching for
const fetch = require('node-fetch');

We can improve this by wrapping the dependency into an appropriate shimmed abstraction and isolating its usage to one place.

You also get a win when onboarding people. They'll be able to see abstractions called API or DataStore which become clear signposts as to what your classes do (rather than a library that a developer may not be familiar with).

// In your abstractions, you get the power to give it a descriptive
// name, if the current name isn't clear in your code too, maybe like:

var Money = require('dinero')

This won't be an issue for well known dependencies like Express or Lodash maybe. But I don't have a perfect memory of every NPM package and what they do.

When you've properly shimmed it, it doesn't even matter to the developers using your shim if you are using Fetch or Axios "under the hood". They'll never know the difference if you change it, as long as you are sensible with the shim.

Conclusion

I hope this gave a good overview of the benefits of shimming, and how it helps you maintain your dependencies.

This whole article was influenced by the writings of Sarah Dayan, found here, and shared with her consent.

I share my writing on Twitter if you enjoyed this article and want to see more.

Wait, what?

What are dense arrays?

Dense arrays are the most well known type of Array. They are the "normal" arrays most are familiar with.

A dense array is an array where the elements are all sequential starting at index 0.

In this instance, the length property of an array accurately specifies the number of elements in the array.

let array = [1, 2, 3, 4, 5]  
array.length // Returns 5

What are sparse arrays?

A sparse array is one in which the elements are not sequential, and they don't always start at 0.

They are essentially Arrays with "holes", or gaps in the sequence of their indices.

So an example would be:

let array = [];
array[100] = "Holes now exist";
array.length // 101, but only 1 element

Normally, the length property of an Array accurately returns the number of elements in the array, but in sparse arrays they don't. If the array is sparse, the value of the length property is greater than the number of elements.

Why can Arrays be sparse?

Arrays under the hood in JavaScript are Objects. Their keys are numbers, and their values are the elements.

let array = [];
array[20] = {};
array[100] = {};
array[19] = {};
alert(array.length); // Logs 101

The length property on an Array takes the last element's index and adds one. So if you have an array with holes between index 0 through 100, and an element at index 101, the length will return 101, as it's the last index + 1.

The above happens regardless of how many elements are in the Array.

The spec specifically details this behavior if you want to read more on the ECMAScript spec here.

How do you get a sparse array?

You have seen some ways already, but there are more:

Use the Array object

let array = new Array(10); // array initialized with no elements
array.length // 10

Insert a key/value at a certain index

array[1000] = 0; // Assignment adds one element 
array.length // But .length returns 1001

Use the delete operator

let array = [1, 2, 3, 4, 5]
delete array[0]
array.length // .length returns 5

Initialize an Array with holes

[,,,,] // You have created an array with nothing but holes
[1,2,3,4,,5] // Oh no, you mistyped a comma and entered a hole between 4 and 5!

Browser implementation differences

The browser you are on (as well as the version) represents sparse array's holes differently.

Chrome displays this the best (in my opinion) and shows empty.

The newest version of Firefox (80.0.1 at the time of witting) shows it like so:

Conclusion

The final solution of the bug I introduced at the beginning is to just check that the element isn't falsy before using it. Something like:

let array = [,,,,]
for(let i = 0; i < array.length; i++){
    if (array[i]) {
        console.log(array[i])
    }
}

Because the holes are falsy, it won't do the logic you are trying on any holes you have in the Array.

So why did my browser show it as empty?

I was using Safari and it showed nothing for the holes. So I logged out the Array's length which was 31, and when I logged out the contents it just showed me an empty array! Pretty confusing at first glance.

It's how you convey your ideas, influence people, advocate for your skills and pay raises, as well as produce comments and documentation to assist others.

“What many people underestimate is that being a good writer,
whether that is through emails or through documents, allows you
to be more impactful. I see many engineers ignore that skill.

You might be proud about your code. You should also be equally proud
of the craft of writing… Writing is a highly underestimated skill
for engineers.” –Urs Hölzle (Google’s first VP of Engineering)

Writing can:

• Impress future employers
• Help you solidify what you recently learned
• Share insights to other developers
• Save others the pain of hours of research

freeCodeCamp can really help develop your writing skills too. They can help give you ideas based on what people are searching for, and they proof-read and edit your writing to make sure everything is explained well. Then they help publish it to a wide, diverse audience.

All this is done by the Editorial team and they're all really friendly and (most importantly) really useful. As you write more articles, you will learn more about who everyone is and how they can help you.

I'm going to briefly explain how I started writing for freeCodeCamp and my experience with it so far. We'll also touch on freeCodeCamp's publication style guide which you can find here.

Who writes for freeCodeCamp?

There are all sorts of people who write for freeCodeCamp.

Some are professional teachers who run programming courses, some are indie developers, some are still learning programming, others are full-time employed software engineers...and the list goes on.

There are people from all different places in the world who speak many different first languages – lots of voices are represented on freeCodeCamp.

There are no hard prerequisites for becoming a contributor to freeCodeCamp News. They don't check whether you have a Computer Science degree (in fact, many self-taught programmers write articles on News), submit you to a test, or expect you to finish their entire curriculum before writing.

You just need to have some prior writing experience so you can provide samples of your work when you apply to become a contributor.

But there are some guidelines about the content you contribute (maybe freeCodeCamp isn't the place for your lasagne recipe).

I'm a full time software engineer. I write to learn more about topics I find interesting.

freeCodeCamp distributes their articles so widely that last month alone (January 2021) people spent 600 hours reading the articles I wrote. That's pretty cool.

What does freeCodeCamp's style guide cover?

The style guide is the way freeCodeCamp standardises their expectations and guidelines so that all contributors know how best to research, write, and present their articles. It also helps ensure that what is published is high quality.

The style guide covers topics like article length, composition tips, how to write a good headline, how to choose a cover image, how not to plagiarize others' work, some rules about cross posting, and a lot more.

I also found it useful to take a Google technical writing course that you can find here. If you don't want to take the course, you can read my summary of it here if you don't have the 4 hours to do it all.

This course helped me learn some common helpful tips for technical writing, but it's not mandatory for freeCodeCamp.

How do freeCodeCamp authors apply?

If you want to apply to become a contributor to freeCodeCamp News, you should first read the style guide. In it, you'll find the application form.

When you're filling out the application, you are asked to link to 3 articles you have written in the past.

If you don't have three samples, or the work you've done is private, make an account on dev.to or Hashnode and write some articles. This helps the freeCodeCamp Editorial team learn about your writing style, what you like to write about, and whether you'd be a good fit for the publication.

I just want to really emphasise that you should read freeCodeCamp's style guide. Read it two or three times and email the team if you aren't 100% sure about what something means.

If you write those 3 articles following freeCodeCamp's style guidelines, you will hugely increase your chances of being approved as a contributor.

But they do also "only approve a small percentage" of contributor applicants, so don't be discouraged if you don't make it the first time around.

My best advice to get approved is to try and find what is missing from articles you are currently reading. Are you going to write the articles for total beginners or intermediates? How much detail are you going to put in? Do you have a favourite programming language? How much do you use humour? None, or lots of jokey references? How should readers apply this knowledge?

When I first started writing I got the genre wrong a few times (I wrote satire for one article, and some article ideas I had weren't great). But through some practice and speaking to the team, I started to improve and understand what freeCodeCamp's genre is.

But I can't write well

So what? The best way to improve is by writing! If you feel like your writing skills are weak, try and set yourself a specific goal – for example to write 50 words a week on any topic. Something achievable for you, and on a topic you will enjoy.

Give yourself 6 months to see if you are making improvements. Reflect on what you don't like about your writing and try to address it.

My only other advice to improve your writing is to read more. The more I have read, the better my writing has become over time by seeing how others do it.

I don't know what to write about!

Write about something you want to learn about. You don't have to be an expert in something to write about it. You develop expertise by writing, discussing, and researching topics you're passionate about.

You can also ask the Editorial team too if you want some help once you get your contributor account.

What if I'm wrong?

It's proof read by the team so you aren't alone. They offer a second pair of eyes, and you are able to make edits post-publishing if you misunderstood something in your research.

It's a good way to learn, too. When you publish something and you're wrong, people will direct message you to correct you. I have been messaged about things people thought were unclear. I thanked them and reviewed what they said, which often helped me improve that article.

Don't feel too scared about failure to try it!

I write too slowly

freeCodeCamp doesn't have a schedule for you. They don't email you to chase you about writing an article a week.

You just write as and when you want to, and the Editorial team are there to proof read and help in any way they can when you're ready. If you only want to publish once a year, go for it!

English is not my first language

This is the case for many freeCodeCamp News contributors. They're practising English by writing, and contributing to the freeCodeCamp audience.

I hope you feel encouraged rather than intimidated to push your comfort zone boundaries if you have always wanted to try technical writing.

Conclusion

You can apply here to contribute to freeCodeCamp News.

Part of my writing was influenced by a talk Quincy did here about writing technical articles. I would encourage you to watch if you plan to apply to freeCodeCamp in the future. He also gives some fascinating case studies of people who began writing and some benefits that came from it.

I have enormously enjoyed writing for freeCodeCamp and it's been an incredibly positive experience for me. I would encourage anyone to try their hand at writing.

Even if you don't end up doing it at freeCodeCamp it's a skill worth investing time in, and makes you a well rounded developer.

I share my writing on Twitter if you enjoyed this article and want to see more.