Forem: Tomas Forsman

Decorator Pattern through Ice Cream

Tomas Forsman — Sat, 30 Sep 2023 19:55:44 +0000

I'm working on a series of articles on the Decorator Pattern.
Any and all comments and feedback is highly appreciated.
This is the first part in the series.

What You Will Learn in This Article

Introduction to the Decorator Pattern: Gain a basic understanding of what the Decorator pattern is and why it's useful in software design.
Concrete Components: Learn about the primary elements like VanillaIceCream, which forms the core functionality we want to extend.
Decorators and Interfaces: Get introduced to the concept of decorators via the IceCreamDecorator class and understand the role of interfaces with Flavor.
Dynamic Behavior: See how the pattern allows for the dynamic modification of object properties without altering their structure, demonstrated through cost calculation.
Example Usage: End with a simple example to showcase how these pieces fit together in practice.

Introduction

The Decorator pattern is a structural design pattern used in software development to add new functionalities to objects without altering their existing structure. This pattern treats both the original objects and the decorated objects as instances of the same interface, making them interchangeable. Essentially, it allows you to "decorate" an object with additional features, without modifying its code. To visualize this, imagine adding toppings to a basic vanilla ice cream; each topping enhances the ice cream while keeping the original flavor intact.

Why It's Useful

Open/Closed Principle: The Decorator pattern adheres to the Open/Closed Principle, which states that software entities should be open for extension but closed for modification. You can extend the behavior of an object without modifying its code. This is like being able to add new ice cream toppings without having to create a new kind of ice cream altogether.
Flexibility: Instead of having a large monolithic class that handles different scenarios, you can break down functionalities into individual decorators. This allows you to mix and match behaviors at runtime, much like choosing different toppings for your ice cream.
Code Reusability and Maintenance: Smaller, specialized classes are easier to understand, debug, and reuse. When each decorator is responsible for a specific function, debugging is often simplified.
Composition Over Inheritance: The pattern offers an alternative to subclassing to extend functionalities. Subclassing adds features to a class at compile-time, whereas the decorator pattern adds them at runtime.
Clean Code: By segregating functionalities into distinct decorators, it makes your code more organized and adheres to the Single Responsibility Principle. In real-world applications, the Decorator pattern is commonly seen in GUI libraries, stream handling libraries, and even in some web development frameworks.

Real-World Analogy
Imagine you're standing in a quaint little ice cream shop. Your options range from exotic flavors like mango-chili to timeless classics like chocolate and strawberry. Today, you opt for the simple yet satisfying vanilla. This essential flavor is the base upon which countless other ice cream experiences can be built.
In software design, vanilla ice cream serves as our Concrete Component. It's straightforward and meets a specific need: satisfying your craving for ice cream. But suppose you wish to make your experience more exciting? On your next trip, you decide to add chocolate chips to your vanilla scoop.
Just like in the ice cream shop, the Decorator Pattern in software design allows your "vanilla" objects to be "topped" or "decorated" with additional features, like chocolate chips, without altering their core functionality. This sets the stage for more complex and versatile objects down the line.
By employing the Decorator Pattern, you create endless possibilities for future enhancements to your "vanilla" object. In this article, we'll begin by implementing our first topping, the "Chocolate Chip Decorator," to add another layer of functionality and flavor to our base object.
In the next article, we'll explore more "toppings" (or Decorators) that can add even more functionality and versatility to our basic "vanilla" objects.

Now, let us break the pattern apart into its core concepts.

Core Concepts in the Decorator Pattern

Interface

The Interface sets the standard for both Concrete Components and Decorators by specifying a common set of methods that they must implement. It serves as a contract that ensures the interchangeability of these elements within the system.

Concrete Component

The Concrete Component is an object that implements the Interface, providing the basic functionality that can be extended. This component serves as the foundational element upon which additional features, provided by decorators, can be built. It fully adheres to the contract stipulated by the Interface, making it compatible with any Decorator that also adheres to the same Interface.

Decorator

The Decorator class also implements the Interface but is designed to extend the functionalities of a Concrete Component. Unlike the Concrete Component, the Decorator holds a reference to a Concrete Component (or another Decorator) and delegates the core functionalities to this wrapped object. It then performs additional operations either before or after delegating to the original object's methods.

Relationship Among Core Concepts

Interface and Concrete Component: The Concrete Component is structured according to the Interface. This design makes it compatible with any object that also adheres to the Interface, ensuring system-wide consistency.
Interface and Decorator: Like the Concrete Component, the Decorator adheres to the Interface. This ensures that Decorators can be interchangeably used with any Concrete Component or even another Decorator.
Decorator and Concrete Component: The Decorator encapsulates a Concrete Component (or another Decorator), thus inheriting its properties and functionalities. This composition allows the Decorator to extend the functionalities of the Concrete Component without altering its structure. By adhering to a common Interface, both the Concrete Component and the Decorator can be used interchangeably, allowing for flexible and extensible design. The Decorator adds functionalities to the Concrete Component in a non-intrusive manner, adhering to the principles of single-responsibility and open-closed, thus promoting maintainable and scalable code.

Now, let’s look at these concept through the lens of our ice cream scenario.

Setting the Stage: The Flavor Interface
To kickstart our implementation of the Decorator Pattern, we'll first define a common interface that both our core ice cream flavor and its various toppings will implement. This interface will serve as a contract that enforces a certain structure on all the classes that implement it. In our case, we'll call this interface Flavor.
In our ice cream example, what's the one thing all flavors and toppings have in common? They all contribute to the final cost of the ice cream. So, we'll include a Cost() method in our Flavor interface that will return an integer representing the cost of that particular flavor or topping.
Here's what our Flavor interface looks like in pseudo code:

Interface Flavor:
Method Cost() -> Integer

The Flavor interface declares a Cost() method that must be implemented by any class that adheres to this interface. This sets the stage for creating both the foundational ice cream flavor—our Concrete Component—and various toppings—our Decorators. Each of these will implement the Cost() method, ensuring that they conform to a common interface. This interchangeability is at the heart of the Decorator Pattern and allows us to add or remove features seamlessly.
By adhering to a common interface, we lay the groundwork for a design that is both flexible and extendable, keeping in line with the principles of clean code and effective software design. With our interface in place, we are ready to move on to the core flavor of our ice cream: vanilla.

Creating Our First Concrete Flavor: The VanillaIceCream Class

Now that we have set the stage with our Flavor interface, it's time to create the foundational element in our ice cream example: the VanillaIceCream class. This class serves as the Concrete Component in our Decorator Pattern. As the name suggests, a Concrete Component is a concrete implementation of our established interface, providing the fundamental functionalities that we can extend later on with Decorators.
In terms of our ice cream example, think of VanillaIceCream as the simple but satisfying vanilla scoop that serves as the base for adding various toppings. The class will implement the Flavor interface, specifically the Cost() method, which returns the basic cost of a vanilla ice cream.
Here's how our VanillaIceCream class looks in pseudo code:

Class VanillaIceCream implements Flavor:
Method Initialize():
this.base_cost = 10
Method Cost():
Return this.base_cost

In this implementation, the VanillaIceCream class has an Initialize() method that sets the base_cost to 10. The Cost() method, adhering to our Flavor interface, returns this base cost. This makes VanillaIceCream a concrete class that fulfills the contract specified by the Flavor interface.
The VanillaIceCream class is simple but crucial. It lays the groundwork for future extensions. Without a well-defined Concrete Component, we can't have Decorators, because Decorators depend on something to decorate!
So, why are we starting with vanilla, you might ask? In the context of the Decorator Pattern, it's essential to start with a Concrete Component to establish the basic functionality that all subsequent Decorators will build upon. Our vanilla ice cream isn't just a flavor; it's a paradigm for the kinds of functionalities our system should offer.
Having set up our VanillaIceCream class as the Concrete Component, we're now ready to layer on additional functionality with Decorators.

Introducing Decorators: The IceCreamDecorator Class

With our Concrete Component (VanillaIceCream) in place, let's introduce the Decorator class that will help us extend functionalities dynamically. In the context of our ice cream example, a Decorator is like an optional topping you can add to the core vanilla scoop to enhance its features—whether it's adding chocolate chips, sprinkles, or even fruit slices.
In technical terms, a Decorator is a class that also implements the Flavor interface and is designed to extend the functionalities of a Concrete Component. It achieves this by holding a reference to a Concrete Component—or even another Decorator—and delegating the core functionalities to this wrapped object. After the delegation, it performs additional operations, thus extending the object's functionalities dynamically at runtime.
Here's how our IceCreamDecorator class is implemented in pseudo code:


Class IceCreamDecorator implements Flavor:
Method Initialize(ice_cream_flavor):
this.ice_cream_flavor = ice_cream_flavor
Method Cost():
Return this.ice_cream_flavor.Cost()

In the above code, the IceCreamDecorator class takes an ice_cream_flavor object as a parameter during initialization. This object could be a Concrete Component like VanillaIceCream or another Decorator. The Cost() method in IceCreamDecorator then delegates to the Cost() method of the ice_cream_flavor object, effectively inheriting its cost and potentially adding more to it.
At this stage, IceCreamDecorator doesn't do much more than forwarding the Cost() method call to the object it wraps. It serves as a structural basis for more specialized Decorators, which will add actual functionalities.
For instance, if we create a ChocolateChipDecorator, it would extend IceCreamDecorator and add the cost of chocolate chips to the basic ice cream cost.
This approach ensures two important things:

Extensibility: By using a common interface for both the Concrete Components and the Decorators, we can endlessly extend our objects with new features without having to modify existing code.
Single Responsibility Principle: Each Decorator class will be responsible for a specific type of functionality, making the system easier to manage and scale. We'll explore a more specialized Decorator in the upcoming section, "Putting It All Together: The GetFinalIceCreamCost Function." There, we'll show how to make a more complex ice cream combination by stacking Decorators.

Putting It All Together: The GetFinalIceCreamCost Function

Having established our Concrete Component (VanillaIceCream) and a general-purpose Decorator (IceCreamDecorator), let's bring these elements together to achieve our ultimate goal: dynamically calculating the final cost of an ice cream with various toppings.
In a real-world software application, this is akin to orchestrating different functionalities to form a complex, feature-rich object dynamically at runtime. This is where the strength of the Decorator Pattern truly shines. You can combine different decorators in a highly flexible manner without altering the underlying code of the individual components involved.
For this example, let's say we want to calculate the cost of a vanilla ice cream decorated with chocolate chips.
The function GetFinalIceCreamCost is designed to bring these separate components together to calculate the total cost. This function first creates a VanillaIceCream object, which serves as the base or the Concrete Component. It then decorates this base with a ChocolateChipDecorator, which is our specialized Decorator.
Here's how it's done in pseudo code:

Function GetFinalIceCreamCost() -> Integer:
basicIceCream = new VanillaIceCream()
decoratedIceCream = new ChocolateChipDecorator(basicIceCream)
Return decoratedIceCream.Cost()

In this function, the VanillaIceCream instance basicIceCream is initialized and passed to a new ChocolateChipDecorator instance called decoratedIceCream. Finally, we call the Cost() method on decoratedIceCream.
This is a simple but powerful example demonstrating how the Decorator Pattern allows for easy composition of behaviors. The Cost() method of the ChocolateChipDecorator will delegate to the Cost() method of VanillaIceCream, add its own extra cost for the chocolate chips, and return the final cost. In this way, we manage to extend the behavior of our VanillaIceCream object without altering its original implementation.
The function returns 12, which is 10 for the base vanilla flavor plus an additional 2 for chocolate chips.
This modular approach allows you to add as many specialized Decorators as needed, each contributing their own unique features to the final object. This is an excellent demonstration of adhering to principles like Open/Closed and Single Responsibility, making your codebase flexible, extensible, and maintainable.
Full example in pseudo code

// Interface that defines a common contract for all ice cream flavors.
// The Cost method returns the financial cost of a specific ice cream flavor.
Interface Flavor:
Method Cost() -> Integer

// The VanillaIceCream class is a concrete implementation of the Flavor interface.
// It serves as the Concrete Component in the Decorator Pattern, providing foundational functionality.
Class VanillaIceCream implements Flavor:
// Initializes the VanillaIceCream class with a base cost value.
Method Initialize():
this.base_cost = 10
// Returns the base cost of the vanilla ice cream.
Method Cost():
Return this.base_cost

// The IceCreamDecorator class provides a framework for extending the features of existing ice cream flavors.
// It also implements the Flavor interface to ensure compatibility.
Class IceCreamDecorator implements Flavor:
// Constructor that accepts an ice cream flavor to be decorated.
Method Initialize(ice_cream_flavor):
this.ice_cream_flavor = ice_cream_flavor
// Returns the cost of the decorated ice cream by delegating to the original ice cream flavor's Cost method.
Method Cost():
Return this.ice_cream_flavor.Cost()

// The ChocolateChipDecorator class is a specific type of ice cream decorator.
// It extends the general-purpose IceCreamDecorator class.
Class ChocolateChipDecorator extends IceCreamDecorator:
// Constructor initializes the base decorator and sets the additional cost for chocolate chips.
Method Initialize(ice_cream_flavor):
super.Initialize(ice_cream_flavor)
this.extra_cost = 2
// Calculates and returns the total cost, which includes the base cost and the extra cost for chocolate chips.
Method Cost():
Return super.Cost() + this.extra_cost

// Main function that demonstrates how to dynamically calculate the final cost of an ice cream flavor with toppings.
// It applies the Decorator Pattern to assemble a vanilla ice cream with chocolate chips and then calculates its cost.
Function GetFinalIceCreamCost() -> Integer:
// Create an instance of VanillaIceCream, serving as the base flavor.
basicIceCream = new VanillaIceCream()
// Decorate the vanilla ice cream with chocolate chips.
decoratedIceCream = new ChocolateChipDecorator(basicIceCream)
// Calculate and return the final cost of the decorated ice cream.
Return decoratedIceCream.Cost()  // Outputs 12 (10 for Vanilla + 2 for Chocolate Chips)

Summary

In this first installment of our series, we've peeled back the layers of the Decorator pattern to understand its core principles. Utilizing a relatable ice cream example, we’ve journeyed from simple vanilla to a more elaborate, chocolate chip-topped treat. We explored how to define an interface, implement a concrete class, and extend functionalities through decorators, all while adhering to software design principles like the Open/Closed Principle and the Single Responsibility Principle.

What's Next

The road ahead is sprinkled with even more exciting features and nuances to add to our Decorator pattern. In the next article, titled "Enhancing Flavors with Toppings," we'll scale up the complexity by introducing more decorators. We'll explore how to layer multiple features on top of our base ice cream flavor, creating endless combinations to suit any palate.
Beyond that, we'll generalize our approach, expanding from ice creams to any product with a cost. This will provide a scalable and adaptable framework that can be employed across a myriad of scenarios. We'll also delve into the mechanics of parameterized decorators, robust error handling, and dynamic user choice integration.
So, strap in for an enlightening journey through the world of design patterns. The Decorator pattern has much more to offer, and we're just scratching the surface.
Stay tuned!

**
Additional Resources**
The Decorator pattern is a topic well-covered in literature and online resources. Here's a list that could greatly enhance your understanding:
Books

"Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (aka the "Gang of Four"): This seminal book introduced the concept of design patterns, including the Decorator pattern, and is considered a must-read for any serious software developer.
"Head First Design Patterns" by Eric Freeman and Elisabeth Robson: This book offers an easier-to-digest look at design patterns, including the Decorator pattern, making it accessible for those new to the topic.
"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin: Though not exclusively about design patterns, this book talks about code organization and principles that relate well to the use of patterns like Decorator.
"Patterns of Enterprise Application Architecture" by Martin Fowler: This book provides an in-depth look into enterprise patterns, including the Decorator pattern, and offers practical examples for real-world implementation.

Websites

Refactoring Guru - Decorator Pattern
- This site provides an easy-to-understand explanation of the Decorator pattern, complete with examples and diagrams.
SourceMaking - Decorator Design Pattern
- Provides a deep dive into the Decorator pattern, including its history and usage.
GeeksforGeeks - Decorator Pattern
- Offers multiple implementations of the Decorator pattern and is good for those who prefer learning through coding.
Dofactory - Decorator Design Pattern
- Features a .NET example of the pattern and offers the pattern's UML diagram.

Online Courses

Pluralsight - C# Design Patterns: Decorator
- A course focused on implementing the Decorator pattern in C#.
Udemy - Design Patterns Through Python
- Covers multiple design patterns, including Decorator, and teaches you how to implement them in Python.
Coursera - Object-Oriented Design
- A course that covers design patterns at a high level, including the Decorator pattern.

YouTube Channels

Academind
- Frequently covers design patterns, including the Decorator pattern, in various programming languages.
The Coding Train
- Offers easy-to-understand video tutorials that include various design patterns. These resources offer varying degrees of depth and perspective, so you're likely to find something that suits your learning style.

Why (! + [] + [] + ![]).length is 9

Tomas Forsman — Sun, 14 Jul 2019 17:11:23 +0000

Edit: At the bottom I've added what I've figured out since I wrote this.

Today I sat down and figured out why you get this result in JavaScript

(! + [] + [] + ![]).length
> 9

So I sat down with the js console and tried to figure things out. There were a lot of this going on:

(!"")
>true

(![])
>false

(!+[])
>true

(!+[]+[])
>"true"

(+[]+"2")
>"02"

([]+"2")
>"2"

What I have come up with, and I might be totally off on some of these so please correct anything that doesn't look right, is the following.

JavaScript does operations from right to left.
The + operand first tries to add the left to the right, if that isn't possible it tries to convert the operand on the right to a number and if it can't do that it converts it to a string. If there is something to the left of the + it adds them together, and if it can't it sticks around. If there is nothing to the left it goes away.
The ! operand converts the operand to the right to a boolean and then reverts it. Only the following values are the same as false as booleans:

false
0
""
null
NaN
undefined

All other values is not false and thus true.

So now it goes something like this:

// We start with
(! + [] + [] + ![]).length  // Remember that we are going from right to left starting 
                            // with the operation before doing -length
![] === false               // ! converts the content of [] to true, since it's not part of 
                            // the false group above, and then reverts it.
+ === +                     // the + is lonely so far with no operand to the right but sticks 
                            // around since it has something on the left.
[]+[] === ""                // The contents of [] can't be added or converted to a number so 
                            // the right operand becomes a string. There's still something to 
                            // the left so the + stays.
!+[] === true               // This the same as !+0 since +[] is 0


// Now we got: 
("false" + "" + false).length
""+false === "false"        // + adds "" to false. It then sticks around.
"true" + "" === "true"      // The + stays after adding "true" to ""


// ---
("true"++"false") 
+"false" ==== "false"       // + has nothing but an operand to the left so it goes away.
true + "" === "true"        // + adds them together and stays

// ---
("true"+"false")
"true" + "false" === "truefalse" // + still stays

// ---
(+"truefalse")
+"truefalse" === "truefalse"     // + has nothing to do after this so it goes away

// ---
("truefalse")               // The operation is done so now we are left with what's outside.

"truefalse".length === 9

Yes, I did go through every step, even those that seems pointless. I'm not at all sure this is how it works but it is what seems to happen to me.

Thoughts?

Edit:
After comments and looking at the documentation this is now how I figure things going.
((!(+[]))+[]+(![]))
Unary operators are going right to left thus !+[] becomes +[] -> !0 === true.

Moving on

Tomas Forsman — Fri, 28 Jun 2019 09:18:46 +0000

About half a year ago I wrote an article about what it was like coming back to the tech industry after two decades as a 'middle-aged junior'. I wrote the article simply to share my mixed feelings of frustration and hope and was not ready for the reaction I got. The article exploded (well, as far as personal posts from an unknown writer goes anyway) and got thousands of views the first couple of days. To date it has gotten 9.4k views on Medium and 6.8k on Dev.to.

While it's nice when something you create attracts attention, what really took me aback was the kind of reaction I got. After over a year of trying to get my foot in the door anywhere companies were suddenly contacting me. Over the next couple of weeks I was contacted by over a dozen companies that were interested in hiring me. Without asking for a CV or code sample I got offers from both large organisations like Egmont Publishing and smaller companies like Accodeing To You. I was contacted by CEOs, CTOs and developers, but nobody from HR and not a single recruiter. I ended up working for Accodeing To You, a small Swedish development and hosting firm where everybody works remotely.

The reason I went with Accodeing was a simple one: values. While all companies that contacted me seemed to have great values, Accodeing stood out as a company where the founders were driven by theirs and had built their company strongly based in those values. Now, after five months, my time with them is coming to an end and I find myself doing a retrospective of my time with them and what I've learned.

The first thing that comes to mind is that I'm in a lot better situation now than I was at the beginning of the year. One of the things that worried me a lot when I was looking for a job was my lack of experience working together with others. Now I've worked with a team that has a really high code standard and that has code reviews on all code that are pushed to the git-repos. I have certainly not always produced the best pull requests but comparing what I push now compared to when I started shows that I've come a long way. When I code I tend to focus on solving problems and clean code and clean commits have always come second, if at all. While I still tend to focus more on solving problems and creating the product, the tasks involved in producing clean and readable code does not take as much energy as it used to do. So, while the focus on details is still something that slows me down I've come to appreciate the need for it and while I don't think I'll be produce code up to the standards of Accodeing I'm a better programmer due to being pushed in that direction.

On-boarding is another thing that comes to mind. Being a small and young company the on-boarding process was not the smoothest when I started. I believe this is where they learned a lot from hiring me. I came in at a time where there were a lot to do and while they had a good document in place I wasn't ready to jump straight in and work solo like I did. I should have said as much but my lack of experience in working with others meant I didn't really know what I should expect in that situation. For me it's not all bad though, I learned a great deal the first month, but I think that I could have done more for them with a smoother on-boarding. While the process could have been smoother I felt welcome and felt that I was getting a place in the company.

Meetings has made my time both great and less valuable than it could be. Each day starts with a morning meeting. Monday meetings is a bit longer since it also contains a weekly code challenge and at the end of the week we have a weekly meeting where we do a retrospective of the week that has passed and look ahead to the next week. These meetings have been important to make me feel like part of a company when everybody is working from home, but since I've only been working part time they have also taken up a big chunk of my time. Days when you work 4 hours, a 1 hour meeting is 25% of your time. That's a lot more than the 12% of a normal workday. I'm not sure how I would go about this differently though.

I suck at administrative tasks. The amount of energy it takes for me to keep track of when I work on what is extremely disproportionate to the actually time it takes to do it. This is one of the issues with having ADHD and working from home. It's not unreasonable to expect someone to keep track of time but the anxiety this simple task causes me means the cost might be higher than what is feasible. I have been told not to bring up my ADHD when I talk to companies, but this is one of the reasons why I do. If I don't mention my issues with repetitive administrative tasks I'll end up feeling like I've cheated myself into a job. Now, even though it still is a cause of anxiety, at least I've been up front about what I'm not great at from the get go.

All in all I'm extremely grateful for these 5 months since it means I'm in a much better position going forward in my career. I'm not worried about having to give up on this path like I was 6 months ago. The reason I have to move on and look for another position is a lack of work and I know that I didn't have time to start giving back more value to them than I've cost. I hope that I will be in a position in the future where I can give back to these great people who gave a middle aged junior a shot. I don't feel like a junior anymore.

Solo developer & life project management

Tomas Forsman — Tue, 25 Jun 2019 09:14:34 +0000

tl;dr
What project management tool, or tools, would you recommend for a solo-developer?
By tools I mean both software, hardware and systems.

I'm currently rebuilding my dev webpage and my more general webpage.
I'm (slowly) solo developing a game as well as experimenting with a couple of different game ideas/mechanics.
I'm developing a component library together with a friend.
I'm working on my dev ops skills by having everything on a local server, including a git repository and my own websites.
I'm also learning more about React, Web Component, ES6, C# and C development.
I'm building a radio for my son with raspberry pi and a timetracking device.
I'm also slowly expanding my smart home, looking for a new job, working at a dev firm, building furniture, planning a vacation to Scotland, writing a book, becoming a healthier person and, as you can imagine, I'm not sure what I'm forgetting top put on this list.

So, you know, I'm living.

I belive in single-tasking rather than multi-tasking but, especially when it comes to the development projects, it has become increasingly harder to keep track of all the single tasks I have in front of me. I constantly have to juggle many different ideas and when I focus on one project I often remember I was supposed to have done a task in another project that I forgot about and when I'm done with the current task I forget about it again.

What project management tool, or tools, would you recommend for a solo-developer?

By tools I mean both software, hardware and systems.

I am a middle aged junior developer, Ask Me Anything!

Tomas Forsman — Thu, 04 Apr 2019 08:11:12 +0000

I recently wrote an article about being an unemployed junior developer, coming back into the industry after 20 years at the age of 40.

Now I'm about to write the second article in that series, the "perseverance wins" article I was hopeing to be able to write at this point. First I thought I'd host an ama to get some insight in what topics would be interesting to hear more about.

I'm hoping for some good discussions in the comments that I can draw from when writing the article.

Some background:

I live in Sweden
I have a wife, two dogs, three kids and four letters; ADHD
I got many job offerings after posting the article, from both big and small companies
None of the many people that contacted me was from HR or a recruiter, they were all management or developers
I now work with web development and hoping to move into game development in the future

Being a middle aged junior

Tomas Forsman — Sat, 30 Mar 2019 15:49:43 +0000

Pretext

I wrote this article on Medium a while back and the response was overwhelming. I had more than a dozen companies contacting me about work. Some offered me a job on the spot and I'm now employed, but more about that in the next article.

Being a middle aged junior

I thought I’d share my experience of being an unemployed junior programmer at the age of 40. It’s not a very inspirational tale, but perhaps it is one some can relate to.

I started programming 34 years ago, at the age of 6. Writing code has been part of my life in different ways throughout my life. 18 years ago I worked as a web developer, building advanced systems in ASP, but being a person with ADHD and a mind that couldn’t rest while there were problems to be solved I started working 16 hour days and 7 day weeks and it wasn’t long until I found myself faceplanting that famous wall. It happened because I had forsaken most social contacts in the pursuit of becoming rich and successful. I was on the right track to succeeding, bringing in more money each month than I’ve done in any 6 month period since, and yet I crashed. I ended up laying in bed for three weeks, only leaving it to care for the most basic of needs. Then one day I woke up and made one of the most important decisions of my life, I stopped caring about money, prestige and what I at that point viewed as being successful.

During the next 16 years I shifted focus and focused on work in areas that included human interaction. I’ve worked in education, both as a student assistant, teacher, and lecturer. I’ve spent years as a computer game journalist and e-sport event manager. I’ve lead projects for unemployed youth, projects exploring art in 3D worlds and other equally unrelated areas. I drove an ice cream truck for a year, I worked in a home for people with Autism, I had my own marketing company and I’ve started two non-profit organizations. I have done a lot of things and during all this time I’ve been an unemployed programmer.

Now I’m 40 years old and I’ve decided I want to get back to doing what my brain is built to do, program. I figured that the market is screaming for coders and I’ve been coding all my life so I should be able to get back into it without much hassle but with no formal education in programming and no current work experience in programming I find myself being a 40-year-old junior and that is not the greatest selling point. After a year of struggling with catching up with the market and almost getting a job several times I find myself doubting. I doubt my skills, I doubt my capability, I doubt my worth and I struggle to keep writing code.

Most of the jobs out there aren’t for companies that need you but for staffing companies, and they are looking for a product that is easy to sell and a newly graduated 22-year-old is more attractive than a 40-year-old with varied work experience.

I’m afraid this piece doesn’t have an inspiring conclusion or a pearl of deeper wisdom to impart on you. I hope that I soon will be able to write that article though, the article that tells you that perseverance wins, that it’s worth sticking to your dream, that if I can make it, so can you. Now I’m going to open Unity and Visual Studio, code for a few hours, spend time with my wife and kids that is the reason I’m not afraid of hitting that wall anymore and tomorrow I’ll send out another batch of job applications.