DEV Community: Izaak Chater

How burnout creeps up on you and 6 strategies to avoid it

Izaak Chater — Sun, 12 Nov 2023 00:31:24 +0000

If you reach a point where your screen is facing the wrong way and you're still confused why your code isn't working then it's probably time for a break.

Burnout is something we are all familiar with, a human universal that can happen to. Burnout is a state of emotional, mental, and physical exhaustion caused by prolonged stress and overwork, often resulting in reduced motivation, productivity, and a sense of detachment from one’s responsibilities. It is something that, sadly, I am very familiar with.

For my whole adult life, I have been very physically active. Whether it’s badminton, jujitsu, weights, a foray into Latin dancing or hiking I can’t imagine life without the ability to be constantly in motion. While being physically active is a healthy thing to do, and is something I believe every responsible adult should make time for, it is, sadly, also something that we can have an unhealthy relationship with.

Case in point, while I now take steps to mitigate them¹, I have been plagued with injuries my whole adult life. It wasn’t until this year when I hired a strength trainer that the concept of training periodization proper recovery and managing energy levels was introduced to me². I will not make this post entirely about strength training concepts (this is a tech blog after all!) however suffice it to say that to continuously progress in strength training you need to be mindful of your energy levels and give yourself adequate time to recover.

The purpose of this post

What leads me to write this post is simple: where managing burnout is concerned it’s all related. It isn’t just that there is an overlap between physical and mental burnout, it’s that they are the same. The same principles that can be applied to strength training to avoid injury can be applied to programming or studying to avoid burnout. Likewise being physically injured or burnt out will lead to cognitive burnout and vice versa.

Our energy levels are universal. If we don’t sleep at night due to a sick kid, if we argue with a significant other, or if we marathon a hard game of Civilization 6 until 4am³ our overall energy levels will be drained and other activities will be harder as a result. If left unaddressed and unchecked this can cause a cascading effect and lead to burnout, see the below graph⁴.

The green line shows adequate recovery after a workout, red line shows working out again before fully recovering.

What is Cognitive burnout?

Mental burnout, also known as Cognitive burnout, is a state of mental and emotional exhaustion that occurs when a person experiences prolonged and excessive stress. It can have a significant impact on cognitive functions and overall well-being. It can lead to poor sleep, emotional exhaustion, mental fatigue, and reduced performance (both physical and mental).

If mental burnout is left unattended, that is to say, if you don’t take your foot off the pedal, some of the above symptoms can become more permanent and very difficult to shake. This can lead to fun things like insomnia, depression, chronic fatigue and disassociation. To belabour the analogy of physical overtraining with mental/cognitive burnout I strongly liken this to a crippling physical injury.

So, now that we know what burnout is and why we want to avoid it let’s talk about some strategies to mitigate it…

1. Know the signs and track them

This is a strategy I have recently implemented myself and it involves listing down the key signs of fatigue and habitually rating them on a scale of 1–10. The six metrics I use are appetite, irritability, exercise enjoyment, brain fog/awareness, sleep quality and general soreness/fatigue⁵.

For the ratings, a 1 is “I feel as strong in this area as I ever have”, a 10 is “I have never felt worse and I cannot function” and a 5 is “I feel fatigued but I can push through it”.

If the overall rating is between 24–35 (4–5/10 average) then it is something to be mindful of and it’s time to make plans to reduce workload slightly for a day or two and take a mental break for an evening. If the rating is above 35 (≥=6/10 average) then, if possible, it’s time to stop everything that is taxing completely for 24–48 hours until you’re back to your regular function.

My calculator with the numbers changed by way of example.

The thing about fatigue and these metrics is that in your everyday life, it is very difficult to know if you’re close to burnout while you’re living it. These markers represent your current state as a human as opposed to something you can intellectually think about or know. If you have tasks in front of you that need completing they will exist in a different part of your brain than your current energy levels and it is very easy to disassociate the two of them.

What tracking these numbers will lead to is understanding when and why you’re fatigued. If you are consistently in the red or orange and it’s your sleep quality that is always >5 then that tells you that a lifestyle change may be in order⁶.

It’s something we’re all aware of but it is easier said than done

Before moving on there is a caveat I want to offer. That is the prescription of slowing down during orange and stopping in red is general advice for when environmental factors are somewhat under your control and is not to be taken as gospel.

There are times in life when slowing down is not an option. Life can be chaotic and throw unexpected things at you and it’s unlikely that you can just say “Hey sorry Mum I know you’re sick but I am in the orange right now and can’t take you to the hospital”.

Furthermore, your actions can be situationally dependent. Maybe you are working towards a deadline at work and you know that after it’s completed you will have some time to yourself for recovery. In this instance, pushing yourself through some clear signs of fatigue might be okay because you will have time to recover, just make sure you can enjoy your time off.

On to the next piece of advice…

2. Hijack your cognitive rewards system

Podcaster and neuroscientist Andrew Huberman speaks about how the reward system that we have as humans is entirely internal⁷. If we can reward the effort process we can start to feel joy in the process itself. The more you feel an internal reward for completing a task, the better you’re likely to be at that task and consequently, the more energy you will have for it.

While “hijack your cognitive reward system” is a catchy title what this boils down to is:

Find a way to be passionate about what you’re doing.

If you are here reading this there is a good chance that you are a dedicated software engineer or professional who wants to perform better, why else would you be taking your time to read articles like this? This means that on some level you are passionate about what you do. Something drew you to this pursuit (or any pursuit).

For the software engineers reading, why would anyone under any circumstances want to write alien-looking code that communicates with machines if they weren’t drawn to it in some way shape or form? Reasons for being drawn to this profession (or any pursuit) can vary immensely.

/*
  This code might look generic and familiar to you but it's easy to take 
  for granted that to the general public, it looks like weird voodoo magic
  that will never make any sense
*/

function Video({ video }) {
  return (
    <div>
      <Thumbnail video={video} />
      <a href={video.url}>
        <h3>{video.title}</h3>
        <p>{video.description}</p>
      </a>
      <LikeButton video={video} />
    </div>
  );
}

Maybe you don’t care so much about the how and are more concerned with the why and the what. If this is the case then you likely feel a sense of pride in what you’re creating and seeing the finished product will be the reward. If you’re like me and the code and system architecture itself is what satisfies you then writing clean, well-tested, expandable, eloquent code will be a huge reward in and of itself.

We all have jobs that we look at and think “I could never do that”, life is too short to not find enjoyment where you can.

In a nutshell, this can be boiled down to the following:

Ask yourself what part of the pursuit gives you satisfaction and chase after it.

3. “Warm up” before starting something hard and “cool down” when finished

This is a basic concept that is seen as essential and obvious where physical activity is concerned but in my experience is often neglected when it comes to cognitive activities.

If your lats aren’t loosened up and warm then how on earth do you suppose you’re going to be able to code?

Imagine loading up a barbell with a weight close to your maximum on a given lift and attempting to lift it with zero warm-up. This is not only likely to fail but it is also dangerous and can result in a minor or severe injury. For this reason, Powerlifters often warm up for between 20–30 minutes before lifting serious weight⁸. There is no reason why we shouldn’t take the same attitude towards difficult cognitive activities.

If you have something very difficult and involved that you’re working on which has many small facets involved then maybe it’s not wise to jump straight in. In my previous post, I outlined a bad habit software engineers often have where they jump straight into coding before gathering any context for what they’re attempting and why they’re attempting it. Unfortunately, this is a common habit and can lead to hours spent wasting energy on a likely inherently flawed solution.

In this instance taking the time to familiarize yourself with what you need to accomplish next before beginning your task is wise. If it’s something you’re yet to start then dedicating a solid amount of time to gathering context and understanding the task will help you ease into it.

If it is a part of an ongoing project then taking the time to refamiliarize yourself with where you are up to in the project, what you need to do next and how it will fit in with everything else is also a good idea. Even if it seems tedious and it’s something you feel you already have a solid grasp of it will still be time spent thinking about a task before starting it.

Following these steps will make you understand what you’re doing, how you will accomplish it, what you will do next and where it fits in in the overall context of the bigger piece of work. It will lead to mental clarity.

Of course, there are instances where you will be able to jump straight into a task and complete it with minimal warm-up or time spent gathering context. But these will be instances where said task is well within your skillset and not something you find particularly difficult. The aforementioned powerlifter lifting a software engineer’s max is an example of this.

4. Understand the difficulty of the task relative to your current capacity and skill level

Point number 1 on this post was about how to track your current work capacity. While understanding your capacity is important it is also important to understand where your overall skill level currently is and what you can foreseeably attempt without running into too many brick walls.

Again to reference my previous post I spoke about how to go about deliberate learning and constantly, incrementally pushing yourself to grow. If this is something that you are doing then you should have a solid idea of what your skill level is relative to a task you’re trying to complete.

Both skill level and energy levels are relative from person to person. The fictional powerlifter that has appeared in this post will still outlift the average software engineer on his worst day.

Even hungover and depressed Eddie Hall is still out lifting me on my best day.

If you are a senior React developer who is approaching burnout (amber on the aforementioned calculator) and the task in front of you is something mid-level, like adding a feature to a code base you understand like the back of your hand, then have at it. If you are an entry-level full-stack developer and you’re asked to do something advanced, in an unfamiliar codebase, in a language you’ve barely worked with, then it might be time to adjust your expectations of what you can accomplish by yourself and proceed accordingly.

Whatever your skill level is and whatever your circumstance is on the fatigue scale the point is:

Understand and be honest about what your current capacity and ability is and plan accordingly to maximise results and avoid burnout

The relationship drawn between current capacity and skill level leads me nicely on to the next piece of advice…

5. Seek Flow State

Mihaly Czikszentmihalyi was a Hungarian psychologist whose formative years were during and post WW2. He came to ask the question ‘When do we find happiness in everyday life?’ He asked artists and musicians why they continued to do what they do despite little financial incentive. An answer he received from one was very telling…

You are in an ecstatic state to such a point that you feel as though you almost don’t exist. I have experienced this time and again. My hand seems devoid of myself, and I have nothing to do with what is happening. I just sit there watching it in a state of awe and wonderment. And [the music] just flows out of itself.

What the musician and Mihaly are referring to is called Flow State. We have all experienced a state of flow at one time or another. For programmers, it’s that state where you write beautiful code quickly and efficiently without stopping to think, where you effortlessly implement solutions that may have been difficult for you mere months ago and where time seems to pass by in an instant. You’re not bored, you’re not anxious, your head is not hurting, and you are completely in the moment with the current task you are undertaking almost as though the code is writing itself.

To achieve this your skill level and the difficulty of the current task need to be in alignment. This is why the previous point is important to understand when seeking a flow state. Take a look at the below graph which summarises the state relative to the challenge level and skill.

Mihaly Csikszentmihalyi’s flow model

Flow is something that should be sought out and achieved as often as possible if you wish to maximise your potential and your enjoyment in any given task, however, as the flow model shows there are zones that you want to avoid.

I have an anecdote that fits in perfectly with the anxiety zone. In the last 18 months, I decided to challenge myself and forayed into Salsa dancing. Like many programmers, I am someone who is thinking all the time and as a result, letting go and being in the moment with music in a public space has always been difficult for me.

My time in the Salsa community was very rewarding (I may come back yet) and I met some fantastic people, however with much love and respect, the teaching style of the school was to throw everyone in the deep end and push them hard until they learn to swim which filled me with anxiety⁸.

While the school produced some truly fantastic dancers, and I did hear some compelling arguments for this style of teaching, for someone who was pushing their comfort zone just by walking in the doors this teaching style was not optimal. This was an example of low-skill meeting a high challenge leading to the anxiety zone.

The general energy of a Salsa performance is very unique and I am glad I had the experience

While the anxiety zone is not a desirable place to be the feedback from being in it is visceral and easy to pinpoint. The boredom zone is arguably more dangerous because it’s something that can creep up on you. Imagine a talented developer stagnating in a role where the tech stack is very familiar and the challenge level is below their skill. It’s easy enough to accept a paycheque for work that you did not find hard however while the anxiety zone can lead to a fast burnout the boredom zone is more of a slow erosion. In this zone, over time you will lose passion for your work, and your internal reward systems will not be met.

A different take on the flow model implies that the higher the skill level the easier flow is to get into and the more growth will occur.

Flow state is not only very productive and enjoyable but it is also a state that will naturally lead to improvement in your craft, help you find passion (remember the aforementioned internal reward system) and even lead to a positive impact on your energy levels.

So points 4 and 5 in a nutshell boil down to:

Understand your skill level relative to your current capacity and the level of challenge in front of you and seek out the flow state as often as possible.

The last piece of advice…

6. Remember to go easy on yourself

Mental health is very close to my heart and I will likely post about it in the future.

Having standards to hold yourself accountable to is not only a good thing it is also essential. The more in touch with your values you are the more certain you will be about how you choose to live your life. Knowing and acknowledging when you make mistakes and seeking to avoid them in the future is crucial for personal growth and being a person of integrity. Furthermore, if you desire to be better then that will require focus and deliberate work over a long period, there is no way around that.

However, it can become toxic when we start to expect unreasonable things from ourselves and then start to get angry and frustrated by our failure to measure up. There are many instances of mistakes that we will make while doing this thing called life. Maybe we have had a bad week and we haven't quite embedded the habits we set out for ourselves, maybe we're understanding a new concept at a slower pace than we thought we would or maybe we took something personally and reacted in a way that we wish we hadn't⁹.

While these mistakes should be acknowledged it is important to not pile more bad will onto ourselves with negative self-talk. Some examples of negative self-talk include:
I can't believe I don't understand this yet god I am an idiot
Everyone else can do this except me, I am a failure¹⁰
I made a mistake at work, I am always screwing up, why am I like this!?

If we were in the amber as far as our burnout levels are concerned this sort of talk is likely to push us into the red within short order.

I am hoping beyond hope that any of us guilty of this would not judge another person separate from ourselves this harshly, so if this is the case, my next question is why would we talk to ourselves that way? The saying 'you are your own worst enemy' comes to mind here because this act of being hard on yourself is only going to drain your energy levels even more. Let's reframe some of the above examples of bad self-talk:

I don't understand this yet but with persistence, I will. When I do grasp this concept I will be all the wiser for taking my time to understand it and I will be better equipped to help other people.
Not everything in life comes to me easily and that's ok
I made a mistake at work, everyone makes mistakes and I will learn from this and be better as a result.

As an exercise let's go back to the first piece of advice about tracking the signs of burnout. I imagine in most cases when we make mistakes or we feel that we are not measuring up it isn't at times when we're in the green and feeling fantastic… so go easy on yourself.

The truth is the path to success and self-betterment is not a linear one and on top of this no single human is perfect. A piece of advice I have heard when it comes to self-talk and forgiveness is:

Talk to yourself in the same way you would talk to your best friend if they were having a bad day.
Finally a bonus piece of advice…

Take Time For Yourself

One thing I have not spoken about much here is what to do when you are close to burnout or you do need to take some time for yourself. The fact is unwinding is easily worth a post in and of itself and it is unique to each individual.
I have a friend who takes every Friday night to himself to eat pizza, drink wine and play video games. This isn't something I have spoken to him about directly but I imagine taking this time for himself every week allows him to go about his week deliberately and work hard knowing that a good break is coming up.
Maybe your "you time" includes a quiet night in with a book, a series on Netflix or a social activity. Whatever it is if it is to avoid burnout then the more enjoyable and low-stress the activity is the better.

Wrapping Up

I am hoping that some of the advice in this blog post can help you (as it has helped me) to have a better gauge of what burnout is and to be self-forgiving when you're close to it. What all of the advice here comes back to is that life is about seeking balance and being able to enjoy the things you pursue while being mindful of your capacity.

If you are tracking the signs of burnout with the green-amber-red scale it will lead to more awareness of your current capacity, how you got there and perhaps most importantly self-forgiveness or not being your best self on that particular day.
Furthermore, the relationship between understanding the rewards you get out of a task and flow state is a close one
If there is one important lesson to take from this post it is this:

Some days you will feel on top of the world and perform very well while other days will be a struggle. Enjoy the days when you feel good, forgive yourself for the days when you feel bad, and make adjustments for your mental health as needed.

If I missed anything in this post please let me know in the comments and follow me for posts similar to this. I am aiming for this blog to be tech-focused however as a career changer a lot of my best advice isn't necessarily directly tech-related but can easily be applied as a professional working in the tech-space.

If any of you have bad knees or a bad back then please do yourself a favour and check out the Knees over Toes guy. https://www.youtube.com/c/thekneesovertoesguy ↩
Training periodization is a big topic and seperate to the scope of this post however but it's well worth checking out whether you're engaging in consistent physical training or not. https://www.trainingpeaks.com/blog/what-is-training-periodization/ ↩
guilty ↩
The super-compensation curve as it relates to this post is worth looking at and understanding. While it is exercise-specific I believe it has a 1 to 1 overlap with any cognitively involved task or skill. https://www.griffinfit.co.uk/the-supercompensation-curve ↩
There are many ideas on how to measure burnout effectively and I am by no means married to the ones I have used. As a rough guide, I feel that they are very good metrics but if you feel they don't apply to you and/or you can think of others that you think would suit you more then by all means. ↩
It almost goes without saying but I will say it anyway, if your sleep routine is all over the place then virtually every point in this post is moot. Sleep is something I have been improving on but still need to get better at, here is a podcast episode from Andrew Huberman that has very much helped me https://www.youtube.com/watch?v=h2aWYjSA1Jc ↩
I will let Huberman break down the brain science: https://www.youtube.com/watch?v=4bIATTQHooM ↩
https://www.boostcamp.app/blogs/best-guide-to-warm-ups-for-powerlifting ↩
Been there ↩
"Comparison is the thief of joy" - Theodore Roosevelt ↩

Tips for efficient learning from a self-taught programmer

Izaak Chater — Sat, 21 Oct 2023 03:34:57 +0000

For almost 6 months now I have been between jobs as a programmer. It’s not been an ideal situation, however, when one door closes another door opens. The mantra I have lived by has been “The longer I am out of the industry, the better I will be as a developer”. I have made it my mission to stay busy, to network and to upskill as much as possible and in spite of the uncertainty of the situation the experience has had some very rewarding moments.

Since I never went through any official institution for my programming education, self-learning is something I am very familiar with. I will go over some of the guiding philosophies I have worked with as well as some of the mistakes I have made.

Skill acquisition

Skill acquisition is an interesting topic. There are definitely right and wrong ways to go about it depending on what you’re trying to accomplish and your own learning style. If done right, learning a new skill should be enjoyable, include continuous progress, and burnout should be minimal. If done wrong, it can lead to frustration, exhaustion, learning bad practices that you will need to unlearn, and burnout.

I have a lot of views on how to go about learning new skills all of which could take up their own post. Some of these include staying humble while maintaining a growth mindset, limiting your focus to a few things at any one time, working smart as well as working hard, choosing what habits to embed, making sure the level of challenge is appropriate ¹, engaging in deliberate practice ² and a great example to start off this post…

Learning concepts before specific details and building on those foundations

Any given skill you can learn has its immutable foundations/basics upon which everything else is built. Whether it’s your basic step in dancing, understanding the different chords in music or understanding the basic movements in strength training the theme remains the same. While learning you will do yourself a huge disservice if you skip the basics and move straight on to something more advanced. My favourite example of this phenomenon remains Brazillian Ju-Jitsu where the difference between an inch of space or a grip variation is often the difference between something working consistently, or barely working at all.

Programming is not an exception to this rule and there are countless examples of foundations that need to be set before being built on. Using the library React as an example, how many issues will a developer run into if they try to learn it before getting a base in HTML, CSS and JavaScipt separately? How can you understand the Virtual DOM if you don’t understand the DOM? How can you understand when and why to use state if you don’t understand re-renders and what causes them? How will you debug issues caused by stale closures if you don’t understand how closures work?

An example of a pre-laid-out plan for learning a specific library (in this case React). Credit to Ramesh Fadatare from Java Guides for the image: https://www.javaguides.net/2022/01/reactjs-roadmap-for-beginners.html

Zooming out even further, what about concepts that are consistent throughout all of programming? How much easier is it to learn a new language if you already understand the basics of data structures and algorithms? What about static vs dynamic typing or Big-0 notation? Building a solid base of understanding in these universal concepts will pay dividends later on in your journey as it will make picking up new languages all the more seamless.

So how do you accomplish this with self-learning? How do you avoid skipping ahead without learning the foundations first? You need the discipline to prioritize your own understanding of concepts above immediate gratification and progression. You also need the humility to admit when you don’t know something and be able to circle back to reaffirm your knowledge.

The result of this will be a continuous and deliberate pace of learning where you are consistently improving and always challenged just beyond your own understanding.

Smaller steps towards your goal are a better long-term strategy

It is important to understand that you will miss things in your journey, you will get frustrated and there inevitably will be times when you need to circle back to the basics. When this happens, it is important to approach the situation with humility, a willingness to learn, and most importantly to go easy on yourself³.

Some more points…

Keep things specific

First and foremost, you should have a specific goal for what you want to accomplish. Programming is a broad field and it can often be overwhelming if you try to take on too many different things at once. You need to be honest with yourself about your current skill level, where you want to be and how you plan on getting there. You will do yourself no favours by overestimating or underestimating your skills as one could lead to burnout and the other can lead to time wasted in recapping things you already know. You need to ask yourself the following questions:

What do I know now?
What do I want to learn/be able to accomplish?
How will I get there?

Once you have the answers to these questions written down you will have a North Star for how to proceed. Now you can go about the next steps in a more methodical and educated way. If you are new to programming entirely or new to a language, then the next step I would recommend is…

Online Courses

I am a big advocate of online courses (Udemy in particular) however I see them as an introduction to a language and not a be-all end-all for self-learning. It is also very important to be deliberate in what course you choose and to know why you’re choosing it. Always read the reviews carefully, make sure the course is appropriate to your level and watch the sample videos to make sure that you gel with the instructor. Furthermore, it is important that the courses have sections where you are forced to think through problems yourself based on what you have learned.

A mistake I made early on was copying the code from the course content, making sure it worked and then moving on to the next slide. My code worked, but by the end of the course, there was next to no chance I would be able to replicate what I had written by myself.

Doing an online course is a huge time investment (generally >12 hours of content) on top of the cost of the course itself so choose wisely.

While completing courses it is important to take notes and understand the why behind the code that is being shown as opposed to just blindly copying whatever is being shown to you. If possible, take your time with the course, change and experiment with the code to see the results. Make sure your understanding is correct and then once you’re finished it’s time for the next step...

Personal Projects

A great way to go about learning new languages/libraries is to complete your own personal projects using them. The fact is to have literacy with a programming language you will need to have an environment where you are regularly solving your own problems, getting familiar with documentation, making mistakes, and learning from them.

There are hundreds of suggestions for personal projects to undertake online⁴(Toy Robot being a personal favourite). I think it is wise to try to choose something that will keep you motivated. This could be a project that might be useful in your everyday life, a game or a project you do with a friend or colleague.

Use of git issues/planning

As a learning developer/programmer, it is important to embed the habit of planning the code you will write before you write it and understanding the technology you are using. The context for any given problem you are trying to solve will help you solve the problem, continue to see the big picture and make the overall experience more enjoyable.

Using git issues is a great way of planning as it will train you to always step back and methodically think about whatever problems you are trying to solve. For personal projects, I have found having a few core issues where the rules of the project are written (folder structure, basic architecture, data flow etc) with other issues being written and checked off for ongoing work.

But issues are not limited to personal projects, if you’re practising interview questions, then it is also a very good time to write an issue or take notes somewhere breaking down the question into smaller parts. If you have a tech interview and the interviewer sees you taking 5–10 minutes to plan your code before you start then it is going to reflect very well on you.

If you do all of this correctly your code will be cleaner, your architecture will be more consistent, and when things go wrong you will be able to understand why with more clarity and over time you will become very familiar with the documentation for whatever language(s) you are using.

Networking

This could include attending meetups, posting on forums, reaching out to people on LinkedIn or anything involving expanding your network of developers. The less lonely your journey is the better. In my experience, programmers are often very keen to help you solve whatever problem you might have.

More experienced developers will be able to steer you in the right direction and answer questions. Furthermore, there is a lot of value in being able to have simple and enjoyable conversations about your craft with like-minded individuals.

The good thing about our community is that it’s full of passionate people who are always willing to share their knowledge. My general rule with networking is, you won’t know unless you ask, so reach out!

A mindset to avoid: “I just want to get this working”

If learning is your goal, then a toxic mindset to have is “I just want to get this working. Understanding the code or writing it in a clean and expandable way is secondary”. The pitfalls of this mindset include dirty, difficult-to-read code, excessive-tech debt and often your code base turning into a big ball of mud⁵.

Not only will this lead to inefficient learning, more frequent bugs in your code, and poor habits being embedded but it is also a mentally exhausting way to go about coding and learning. This instant gratification mindset is a recipe for burnout and is something that has cost me dearly in the past.

AI and learning

AI is an inevitable part of the industry and learning to code. It’s difficult to predict what the future will be and that goes beyond this post, however, as far as self-learning is concerned it can either be a very powerful tool or a hindrance. Remember what was said earlier about learning basic concepts and then building on them? This is where AI can really shine and act as an extremely patient teacher of sorts.

Is the future really so bleak?

The beauty of AI bots like ChatGPT or Bing AI is that you can ask them questions in your own language and ask qualifying follow-up questions. Maybe something in the documentation is not quite clear and the way that it’s written is not obvious to you. That’s when you can log into ChatGPT and ask directly “Is the following concept an example of A or B?” and continue to rephrase the question until you are clear on the concept.

AI for research/ git issues

If we go back to the example of using git issues to plan out our code. If you’re by yourself, then how are you going to know what the best folder structure is? I just asked ChatGPT “Can you give me a basic file setup for a React application?” and the following code along with an explanation of each file was given to me within seconds:

my-react-app/
  ├── node_modules/      // Dependencies installed via npm or yarn
  ├── public/            // Public files, like HTML and static assets
  │   ├── index.html     // Main HTML file
  │   ├── favicon.ico    // Favicon
  │   └── manifest.json  // Web app manifest (for PWA)
  ├── src/               // Source code for your React app
  │   ├── index.js       // Entry point for your app
  │   ├── App.js         // Main component
  │   ├── components/    // Directory for reusable React components
  │   │   ├── Header.js
  │   │   ├── Footer.js
  │   │   └── ...
  │   ├── styles/        // CSS or SCSS files
  │   │   ├── main.css   // Main styles
  │   │   └── ...
  │   ├── assets/        // Static assets like images
  │   │   ├── logo.png
  │   │   └── ...
  ├── package.json       // Project configuration and dependencies
  ├── package-lock.json  // Lock file for package versions (if using npm)
  ├── yarn.lock          // Lock file for package versions (if using yarn)
  ├── .gitignore         // List of files/folders to be ignored by Git
  ├── README.md          // Project documentation

The above isn’t anything revolutionary but there is a good chance that it’s much more scalable and easy to work with than anything a new developer may have come up with by themselves. Furthermore, you can ask about appropriate architecture, separation of concerns, or almost anything you can think of.

The limitations of AI and how to not use it

If we circle back to the bad habit code first ask questions later ChatGPT can also be used as its own Band-Aid solution. It is possible for you to copy and paste your code into ChatGPT and say, “Make this work” and after a few prompts have the code working without you understanding the how or the why. In some instances, this may be extremely useful but where learning is concerned, it is equivalent to a teacher flat-out giving you the answer.

Furthermore, ChatGPT as an example is not up to date on technology after 2021. For this reason, it will not be able to provide effective advice on the features of more modern versions of libraries (React 18 or NextJS13 as two examples).

To summarise

The way I see AI at this point is it is a tool that can augment our abilities as a programmer and make us more efficient. To use gaming terminology, let’s say that using AI can increase your efficiency by 50% as a developer. This is great but you will need to level up your baseline skills to make sure that the 50% is 50% of a substantial number⁶.

If AI is used as a crutch, you will not level up as a developer and you will hit a ceiling.
If AI is used as a learning tool as well as something that can increase efficiency, then really the sky is the limit.

Wrapping up

If you made it this far then congratulations! This post was much longer than I had originally intended. Originally, I wanted to write a brief post about how I use AI for learning but it just kept on growing. Other questions inevitably popped up such as, What is efficient learning?”, “Why do I do things this way?” or “Is this good advice for someone else?”.

There is a good chance that some of the advice I have provided here isn’t for you, and that is perfectly fine. There really is no one-size-fits-all-all advice when it comes to learning or life, and some people thrive off diving straight into the deep end and learning the foundations as they go.

The truth is that I have had to work against my own nature and unlearn a lot of bad habits during my journey as a developer. Every mistake I have outlined here is a mistake that I have made in the past, this post has been the result of wisdom gained from the 20–20 vision of hindsight.

Skill acquisition is a very broad topic and at its core, it’s a study of human nature. If you found this post interesting then I recommend checking out the books ‘Mindset’, ‘Grit’ and ‘Atomic Habits’. If you liked this post then give me a follow because I feel I am beginning to find my voice and I want to continue applying some of my other life lessons to tech-related topics.

The relationship between skill and difficulty is an idea I’ve gotten from reading about Flow State. If a challenge is above your current skill level then anxiety comes into play. Imagine asking someone fresh out of a coding boot camp to make high-level decisions for your organization and implement the code, it’s unlikely to go well for anyone. If a challenge is too low for a person’s skill level then boredom comes into play. Where learning is concerned ideally the challenge should be just above your current skill level at all times. https://www.theworldcounts.com/purpose/what-is-flow-in-psychology. ↩
Deliberate practice explained: https://jamesclear.com/deliberate-practice-theory. ↩
Mental health and positive self-talk are worth their own posts. I encourage you to remember that the journey towards bettering yourself is rarely if ever, a straight line and to also take stock of the progress that you have made. ↩
Stephan Miller at Codecademy has some good recommendations: https://www.codecademy.com/resources/blog/20-code-challenges/ ↩
Brian Foote and Joseph Yoder’s 1999 paper “Big Ball of Mud” is still very much worth a read and holds up well today. http://www.laputan.org/pub/foote/mud.pdf ↩
I really hope this made sense 🤦‍♂️ ↩

David Heinemeier Hansson removes TypeScript from Turbo-8: an unbiased take.

Izaak Chater — Sun, 08 Oct 2023 23:37:51 +0000

As a front end developer who has not used the Ruby programming language, I must admit that before this year I did not know who DHH was. My first exposure to him was at a Ruby on Rails meetup where two out of the three speakers offhandedly referenced their distaste for him and his political views. Since neither talk was directly about DHH this piqued my curiosity and in the coming weeks I made an effort to learn about him and why he is such a contentious figure and not your typical startup CEO.

DHH is the creator of the Ruby on Rails framework, has been very involved in the open-source community, and is the co-founder of Basecamp, an author, and a race car driver. He posts regularly on his blog where he candidly expresses his opinions on everything from tech to business. He has been involved in many controversies over the years and while I appreciate his candor I am not surprised that he is not universally popular. I won't go over his full history in this post (he has been in the industry for 20 years) rather I will mostly focus on one recent event that I referenced in my previous post.

DHH removes TypeScript from Turbo-8

For those who were not paying attention to these events a few weeks ago. Turbo-8 is an open-source library initially built by DHH and his team that is proposed for the hotwire technique ¹. As outlined on the repo the goal of the Turbo system is to do as much work as possible on the server before sending it back to the client code when the state changes. Like any open source code, anyone can pull it onto their machine, make changes, and then raise a pull request for said changes while following their guide. The code is written almost exclusively in JavaScript/TypeScript and is frequently contributed to by members of the open-source community.

Recently and seemingly out of the blue DHH announced on his blog that Turbo-8 is dropping TypeScript with a link to the PR on the framework. This decision was met with backlash for multiple reasons, as stated Turbo-8 is an open-source library which means it is not just 37signal employees that contribute to it, the decision seemingly came out of the blue with little to no warning. Many people in the community swear by TypeScript over JavaScript and to top all of this off DHH's reputation amongst many community members isn't positive. While many of the responses were in the form of memes and dry, sarcastic humor (which was often funny but not overly mature or helpful) the top comments were objective and well-reasoned:

It's been a few weeks, many active reddit posts were dedicated to it, many a YouTube video was made and many a complaint was had. So in what way can we add discourse to this event in a productive manner? What can we learn from this going forward?

Let's start by separating the art from the artist

A lesson I have learned as an adult is that the words that we say, our actions, and the art we create take on an existence that is separate from us as human beings. This can be a difficult thing to do due to our inherited bias and the halo effect, or in this case the reverse halo effect.

The fact is that humans are complex, malleable, imperfect, and likely to change over time. This is why I propose that the ability to separate the art from the artist, the words from the speaker or the ideas from the person is a very important life skill that will also benefit you as a software engineer. When you separate the art from the artist it opens space for more objectivity, it allows you to question, reaffirm or even change your own beliefs, it can create a productive dialogue and in some cases, it can come full circle and allow you to understand where the creator of the art or idea is coming from ². So let's get specific...

How can separating the art from the artist can be applied to this situation

As an exercise let's forget everything we know about DHH, whether our opinions of him are positive or negative. Let's be real programmers and break down the problem itself into smaller parts. From what I can see it boils down to two main questions:

"Why is removing TypeScript from any given code base an ill-advised thing to do? What are the arguments for and against it in this particular instance?"

and a question that I beleive gets to the heart of a lot of the criticisms directed at DHH/basecamp:

"Is it justifiable for a company to make sudden, dramatic changes to its open source code that relies on community support for it to thrive?"

Let's start by addressing question 1...

TypeScript or !TypeScript?

TypeScript was developed by Microsoft in 2010 and set out to solve the problem of type errors in JavaScript. For those of you wanting context on its inception then I'd recommend checking out OfferZen origins documentary. TypeScript is a compile-time type checker that subsequently compiles vanilla JavaScript for execution in the browser or server. It also offers developer benefits of enforcing strict use of types through the IDE, let's look at a quick example before moving on. Suppose we have a function that takes in a numeric value and does any amount of arithmetic before returning another numeric value:

Nothing in the ide or language is stopping us from passing parameters of any type to this very simple function and it isn't until run time that we are given errors, often said errors are not the easiest to understand. But looking at the same code in TypeScript:

Suddenly as a developer and in the ide itself, we have red underlines and very readable error messages. Obviously, this is an extremely simple example but when we consider how important consistency is with data types and how strong types like this are self-documenting it's easy to see what the benefits of Strong types are. As our codebases grow TypeScript funnels developers towards being constantly vigilant about the types that they use and will let you know when you step out of line.

The argument against static typing is that it takes longer to write and as a developer, you might spend more time trying to satisfy the compiler than writing the code itself. If you're working with a library like React or NextJS suddenly more types are introduced and when async calls come into play there is even more type complexity introduced.

Furthermore, TypeScript is a compile-time checker that can give a nonvigilant developer the illusion of type safety. As a developer you might satisfy TypeScript, have the code compiled into JavaScript and then during runtime a response might deliver an object in a shape you did not account for when you wrote your code. Of course, a very valid argument against this is that a good developer will account for run-time type checking as well but the point stands that TypeScript is not a cure-all solution.

This has been a very brief description of the pros and cons of TypeScript and I have missed a lot however this leads me to my next point...

The unintended benefits of DHH's decision

The removal of TypeScript from Turbo-8 has had some unintended positive side effects: it's made a lot of developers articulate their opinions on why we use TypeScript and what its strengths and weaknesses are. It has given us a chance to examine our opinions on TypeScript, static vs dynamic typing and why any of us have certain preferences. It created an opportunity to express and even reconsider strongly held opinions and very importantly to educate newer community members on why certain preferences exist.

For anyone newer to programming (myself included) watching these discussions play out is invaluable. TypeScript has been an industry standard for years and while it is easy to explain its benefits and see why it's so widely used its use is not something that is always interrogated vigorously.

Suddenly the reason TypeScript is used and the problems that it solved when it was introduced more than 10 years ago are now a part of an active and feiry discussion. Suddenly there are intelligent, senior developers really deep diving into its benefits and the "why" behind TypeScript ³.

So now that we have seen the arguments for TypeScript and removed the Halo effect let's continue with objectivity and exercise..

Seeing the argument from both sides

DHH made an argument in a podcast (worth a listen) after the fact that the extra code involved with writing types was creating a bad developer experience for him and his team. He likened dynamically typed languages to being more "free" with less code overhead, coming from a company that very much favors Ruby many of the employees were not crazy about the strong typed way of thinking. Let's examine the following statement in a vacuum:

We as a company collectively decided we don't enjoy the developer experience of TypeScript so we opted to remove it.

On the face of it, this is not an unreasonable statement and it is not surprising that a company of people who most likely predominantly come from a dynamic language background might feel this way.

Under what circumstance is it unacceptable for personal preference to inform the languages you use, your system architecture, and how you write your code? At a certain point, bad practices cost money or become very inefficient so the answer is: "Yes, but this is very irresponsible and short-sighted". For a team that prefers dynamic to static typing removing TypeScript does not quite fall under this category.

Some very good arguments have been made for the TypeScript compiler (I certainly found them compelling) but the decision to remove it isn't inevitably going to break the code or make it unmaintainable. If it does boil down to a matter of preference, then it is understandable why TypeScript was dropped by this particular company.

Now let's address the other more pressing question...

What are the ethics of an abrupt change to an open-source codebase?

I am a tourist in the open source community and unsurprisingly many of its members are very loud and passionate. The thing that I don't think DHH accounts for when he talks about the blowback he received is that contributing to open-source code is a labor of love. Anyone outside of his company dedicating their time to contributing is doing so because they care and they want to give back.

But as ever we need to remain unbiased and think about where DHH and 37signals are coming from with the decision. It is clear as day that DHH prioritizes himself and his company first and foremost with his decision-making with the community outside of the company being a distant 2nd place. But he argues that the open-source code that is released is something that they have shared with the community for free. Based on this how much does he objectively owe the people who choose to give up their time to contribute to their code? The hard truth is that, while good relations are always favorable, he owes you nothing. His choice to prioritize himself and his company above the open-source community, while making him unpopular, is a defendable position.

An idea that I always come back to is that if you are someone who thinks for yourself and expresses your opinions in a free and candid way then you will inevitably polarize people. Whether you're a fan of DHH or not you have to concede that he is a free thinker, he speaks his mind and he acts whether his decisions will be popular or not.

Wrapping up

So after looking at the situation objectively it isn't so hard to see where people on both sides of the argument are coming from. Productive conversations can come out of disagreement and at the end of the day it is important to try to see things from other people's points of view.

One question I will leave with: is there a way to bridge the divide? In this instance, it seems like both sides of the argument are left with the impression that the other side is hostile and unreasonable. DHH wrote a follow-up blog to his initial post Open source hooliganism and the TypeScript meltdown and there was a line in there that stood out to me:

"I'm always happy to have technical discussions in good faith with such individuals, and they're certainly entitled to their opinion on a move like this without getting tarred by association with the hooligans who showed up spoiling for a fight."

If I had to guess I'd say that he is sincere in this offer. So here is a throwdown to the open source and Ruby on Rails community: take him up on it. Compile (lol) a list of your grievances, try to empathize with his point of view and meet him in the middle. Remember that it's very important to handle yourself respectably and patiently while also making an effort to understand where the other side is coming from. If you take anything from this post it's that civil and respectful public discussions about opposing ideas are always beneficial to anyone listening

For my money, if this can be a result of DHH's decision then something very productive will have been achieved.

For a breakdown of the library and what it does check out this article by Bhumi on dev.to. ↩
One thing I would like to make clear is that I am not advocating for separating the art from the artist in every case (that would be exhausting), nor am I suggesting that you should give someone the time of day regardless of how reprehensible you find them. If you find something someone has said or done offensive to the point where you don't want to listen to what they have to say or you wish to boycott their work then it is absolutely your right to do so. ↩
This article provided a good breakdown of the more technical discussions involved: https://tomaszs2.medium.com/contributors-angry-after-turbo-8-suddenly-drops-typescript-4ffd4e0be7cd ↩

The Builder Pattern: making testing with type saftey easier in your growing React/TypeScript applications

Izaak Chater — Fri, 29 Sep 2023 06:34:45 +0000

Recently the creator of Ruby on Rails David Heinnmeier Hansson announced that TypeScript was being dropped from Turbo 8. This decision was not a unanimously popular one to say the least however it did spark an interesting discussion on the utility of TypeScript in enterprise level applications. Does it create more overhead for developers than it's worth? Does it make more sense to use strong types in some applications than others? Is it a good or a bad developer experience? Then in a fairly timely manner OfferZen Origins released the TypeScript Documentary where a lot of the people who originally worked on TypeScript back in 2010 explained how the language was built and the problems they initially wanted to solve. For someone who is relatively new to development (starting in 2019 when TypeScript was already standardised) these debates and discussions have been nothing short of facinating.

The Problem

While I am sold on the benefits of TypeScript and if given a choice would prefer to use it I also see the merits to some of the criticisms. There are instances where you can be in TypeScript purgatory trying to get rid of the red line of death under your code and make the compiler happy because of a small type mismatch. The issue I will aim to address here is keeping the compiler happy during testing. In enterprise level applications (and even personal applications) types can start to get very complex especially when they start to have relations to each other. It's not uncommon to need to re-create large pieces of data to test something quite isolated and simple.

For the rest of this article here are the types we will be working with and looking to re-create:

export type User = {
  id: number;
  username: string;
  bio: string;
  grade: Grade;
  comments: Comment[];
  likes: Like[];
};

export type Like = {
  id: number;
  userId: number;
  commentId: number;
};

export type Comment = {
  id: number;
  userId: number;
  text: string;
  likes: Like[];
  comments: Comment[];
};

export type Grade = {
  belt: Belt;
  stripes: Stripes;
};
export type Stripes = 0 | 1 | 2 | 3 | 4;
export type Belt = "white" | "blue" | "pruple" | "brown" | "black";

To continue the point about complex types and testing, say we have a React component we wish to test. The Component accepts the User type as a prop but out of the 10+ props passed through we only really care about the bio, or the grade. To satisfy the type compiler (and indeed React in general) we still need to pass in a full object in the correct shape for the test to even run. There are many ways to go about this from using factory functions to simply mocking and re-using the data in each test suite. But these solutions have their limitations.

While factory functions are a fantastic pattern which we will have a use for later in this post it is far from optimal here. Consider the following solution:

// Factory function with defaults
const createUser= ({
  id = 1,
  username = "John-d",
  bio = "I am a generic user",
  grade = { belt: "white", stripes: 0 },
  comments = [],
  likes = [],
}: {
  id?: number;
  username?: string;
  bio?: string;
  grade?: Grade;
  comments?: Comment[];
  likes?: Like[];
}): User => ({ id, username, bio, grade, comments, likes });

It isn't terrible, in fact its a very viable solution that will work well with a lot of tests

const userWithUpdatedGrade = createUser({
  grade:
  {belt: "blue",
  stripes: 2}
});

will equal:

{
  id: 1,
  username: "I am a generic user",
  bio: '',
  grade: {
    belt: 'blue',
    stripes: 2,
  },
  comments: [],
  likes: [],
}

It will work and satisfy the compiler however once objects start getting more complex (think of adding likes and comments or any number of nested objects) the code overhead will start to get higher and we will need to write additional functions to account for comments needing to have the right userID while being passed into the initial user object. This is doable and I can see arguments for swearing by the factory pattern however I propose an alternative.

What has worked well for me in my own projects as well as in previous workplaces has been 'The Builder Pattern'

What is The Builder Pattern?

The builder pattern is frequently used in Java and follows several OOP design principals. The idea is that there are a set of classes that come together to build an object in the shape that we as the developer desire. Think about the above example and how Comments and likes relate to each other as well as the User type. If we wanted to build an object that included a users comments as well as replies to said comments it might look something like this:

So that is the abstract concept of it, we "build" instances of each of these objects through classes and use them as we see fit, but how is it implemented? For starters we need something called a 'product class' which will represent the type of object we are trying to create.

export class UserInstance {
  id: number;
  username: string;
  bio: string;
  grade: Grade;
  comments: Comment[];
  likes: Like[];

  constructor(
    username: string = "JohnDoe",
    id: number = 1,
    bio: string = "I am who I am",
    grade: Grade = { belt: "white", stripes: 0 },
    comments: Comment[] = [],
    likes: Like[] = []
  ) {
    this.id = id;
    this.username = username;
    this.bio = bio;
    this.grade = grade;
    this.comments = comments;
    this.likes = likes;
  }
}

Straight off the bat the above class has type satisfaction from the User type and provides default parameters for our generic user, but we're not done yet. While this class by itself could be used throughout our app we have not solved the same problem that was present with the factory function pattern. Enter the builder class:

export class UserBuilder {
  user: User;
  constructor(userName: string) {
    this.user = new UserInstance(userName);
  }

  setId(id: number) {
    this.user.id = id;
    return this;
  }

  setBio(bio: string) {
    this.user.bio = bio;
    return this;
  }

  setGrade(grade: Grade) {
    this.user.grade = grade;
    return this;
  }

  setComments(comments: Comment[]) {
    this.user.comments = comments;
    return this;
  }

  setLikes(likes: Like[]) {
    this.user.likes = likes;
    return this;
  }

  build() {
    return this.user;
  }
}

Now to instantiate a new user with type satisfaction its a simple matter of const user = new User("John-Danaher").build()¹. So this is all fantastic but it sure is a lot of code and we havent even addressed the comment or like types yet! Why should we go to all of this trouble with these Builder classes? Why indeed...

Its clean and readable

While the Builder pattern has a decent amount of code overhead once your builders are ready for use using them is very simple, readable and dare I say elegant.

Imagine a component accepts our user class and uses the "belt" object to render certain colors on the screen based off the belt color and stripes. The component accepts the whole user class and has other things happening but for the same of this test we just want to test the belt.

<>
    <ProfileView user={user} />
</>

Using the builder pattern with our tests the code will look like this:

it("renders the belt component as purple with three children 
    when the belt object is purple with 3 stripes",
    ()=> {
      const userWithBelt = new UserBuilder("John-Danaher")
        .setGrade({belt:"purple", stripes: 3})
        .build()

      render(<ProfileView user={userWithBelt} />)

      const beltClass = screen.getByTestId("belt-component")
      expect(beltClass).toHaveStyle('background-color: purple')
      expect(beltclass.children()).to.have.length(3)
})

The ProfileView component has immediate type satisfaction with the builder class (no red lines of doom under your code) but on top of this the whole test reads as easy as a childrens book. Any other developer coming into this file will be able to immediately see whats being tested and how and adding additional tests will be just as easy.

Very complex types are easily instantiated under the hood.

One thing we haven't dealt with yet in our code is the comment and like classes, so lets instantiate those now.

For the Comments:

export class CommentBuilder {
  comment: Comment;
  constructor(text: string) {
    this.comment = new CommentInstance(text);
  }

  setId(setId: number){
    this.comment.id= id;
    return this;
  }

  setUserId(userId: number){
    this.comment.userId= userId;
    return this;
  }
  setLikes(likes: Like[]) {
    this.comment.likes = likes;
    return this;
  }
  setComments(comments: Comment[]) {
    this.comment.comments = comments;
    return this;
  }

  build() {
    return this.comment;
  }
}

export class CommentInstance {
  userId: number;
  id: number;
  text: string;
  likes: Like[];
  comments: Comment[];

  constructor(
    text: string = "Generic comment",
    userId: number = 1,
    id: number = 1,
    likes: Like[] = [],
    comments: Comment[] = []
  ) {
    this.text = text;
    this.userId = userId;
    this.id = id;
    this.likes = likes;
    this.comments = comments;
  }
}

For the comments another set of builder classes makes sense because there are a few different properties involved with the object, for the likes on the other hand since its a very small object our friend the factory function will suffice:

export const likeFactory = ({
  id = 1,
  userId = 1,
  commentId = 1,
}): {
  id?: number;
  userId?: number;
  commentId?: number;
} => ({
  id,
  userId,
  commentId,
});

So now if we need to test a user with comments it is a simple matter of using multiple builders in the same test file:

it("displays users comments in the comments section" ,()=>{
    const comments = [ 
      new CommentBuilder("first comment")
        .setLikes([likeFactory({})])
        .build(),
      new CommentBuilder("second comment").build(),
      new CommentBuilder("comment also").build()
      ]
    const user = new UserBuilder("John-Danaher")
      .setComments(comments)
      .build()

     render(<UserComments user={user}/>)
     expect(....)
})

In a few easy to read lines of code we have created a complex user object for testing purposes. Another benefit is that..

Due to its use of methods it is highly customizable

Test cases are often simple and don't care about a good portion of what is on the page. Imagine if we wanted to test the quantity of comments in a users profile or verify that the correct text is appearing in the correct place? Our pattern as it is (and indeed the factory pattern) does provide a way to do this but it will be rather verbose:

const userWithComments: User = new UserBuilder("active-user")
  .setId(1)
  .setComments([
    new CommentBuilder(1)
      .setId(1)
      .setLikes([
        likeFactory(1, 1, 1),
        likeFactory(2, 1, 1),
        likeFactory(3, 1, 1),
      ])
      .build(),
    new CommentBuilder(2).setId(2).build(),
    new CommentBuilder(2)
      .setId(3)
      .setComments([
        new CommentBuilder(3)
          .setLikes([likeFactory(4, 1, 3), likeFactory(5, 1, 3)])
          .setId(2)
          .build(),
        new CommentBuilder(4).setId(2).build(),
      ])
      .build(),
  ])
  .build();

This is where the beauty of the constructor patterns use of methods come in. Who says the method has to accept just one parameter type? Maybe we want to customize the methods for ease of use? Lets look at the setComments method on the user class and see what we can change to more easily cover more test instances:

  setComments(comments: Comment[] | string[] | number) {
    // User wants a set amount of comments but does not care about the content
    if (typeof comments === "number") {
      // Create an array from the number passed in
      const commentArray: Comment[] = Array.from(
        Array(comments),
        (_, index) => index + 1
        // for each element in the array create a new comment
      ).map((_, i) => new CommentBuilder(this.user.id).setId(i).build());
      this.user.comments = commentArray;
      return this;
    }
    // User cares about the text of the comments but nothing else
    if (!!comments.every((c) => typeof c === "string")) {
      this.user.comments = comments.map((comment) =>
        new CommentBuilder(this.user.id).setText(comment).build()
      );
      return this;
    }
    // lets make sure the comments have the correct user id
    this.user.comments = comments.map((comment) => ({
      ...comment,
      userId: this.user.id,
    }));
    return this;
  }

So now if we just want to test the number of comments a user has made:

it("only 10 comments are displyed per page", () => {  
  const user = new UserBuilder
  .setComments(21)
  .build()

  render(<Profile user={user} />);

  const commentsWrapper = document.getElementById("comments-wrapper")
  expect(commentsWrapper.children.length).toBe(10)
})

it("displays the correct comment text on screen", () => {

  const user = new UserBuilder
    .setComments(["comment 1", "comment 2"])
    .build()

  render(<Profile user={user} />);

  expect(screen.getByText("comment 1").toBeInTheDocument()
  expect(screen.getByText("comment 2").toBeInTheDocument()
})

Now the above is just something I have came up with while writing this and isn't something that I have put into practice, perhaps my code could be cleaner or there is a better way of acheiving what I am trying to acheive but the point stands: the methods can be customized quite easily and as long as the return type still satisfied the compiler it is safe to experiment around. Another benefit of the builder pattern is that..

As the application grows and types change the patterns can remain constant:

Applications grow, different data requirements come up for our users and schemas can change dramatically over time. This is something that the builder pattern and its use in testing scales for very well. Say a new property is added to the user type, a property is removed and one is changed. Getting rid of the myriad of errors in your tests and compiler is just a matter of editing the product class to add, edit or omit the nessesary fields and suddenly we're back to having type satisfaction across our app. Of course it won't always be this simple as there is no telling what direction schema changes will go in over time but by enlarge using the pattern correctly will be adhering to DRY principals and thus be easy to edit over time. Another thing to keep in mind about bulder pattern is that...

You are not limited to creating builders for data mocking:

Any object that you might need to re use in your app can be re created in the builder pattern. I've used it in personal projects as dummy data before I'd hooked up my app to the database. One use I have found for it that could be useful at a bigger scale is to mock context values for testing purposes. By way of a breif example:

  it("renders with the context correctly", () => {
    const funct=jest.fn()
    const data = new ContextBuilder().setInitialState("foo").setFunct(funct).build();

    render(
      <Context.Provider value={data}>
        <Navbar />
      </Context.Provider>
    );
    expect(screen.getByText("foo")).toBeInTheDocument()
    const btn = screen.getByRole('button')
    fireEvent.click(btn)
    expect(funct).toHaveBeenCalled()

We now have an easily customizable context which we can change test by test and reap all of the readability and DRY benefits that come with the Builder Pattern.

I am sure there are many other uses for the pattern. You could use it in nextJS to mock the next/navigation hooks not to mention it has utility whether you're using a strongly typed language or not.

Wrapping up

I will close with one final point about the builder pattern and go back to the beginning of the post where the downsides of TypeScript were mentioned. I have found that the act of creating builder pattern classes forces you to understand and interface with the common types in your app on a deeper level than you otherwise would. I have heard it said that both strong types and testing make you as a developer think on a deeper level about your code, how its implemented and what can go wrong with it. The builder pattern is yet another example of a way to funnel the developer towards thinking more about type saftey and reusability. While writing your code you may already have it in your mind "this is how I will test this" or "these are the types that I should have this component expect" but if you know you have builder classes in your back pocket for those types that you use with testing it is yet another layer of consistency and overall for my money will make the developer experience easier and more of a joy.

This was a very basic rundown of the builder pattern and two of its associated classes and there are more concepts to it, for further reading on the pattern the following article on refactoring.guru provides a comprehensive rundown. ↩