https://longform.asmartbear.com/delegation

I’ve been on various teams in my career, from single person freelance, sub-contractor where I was the only UI guy and the rest were back-end, to consultant amongst a dozen+ helping a client, to employee on feature teams, startups, scale ups, and contractor or sub-contractor for startups and scale ups. What was consistent in all of them was I would learn from people. Some were just 100% brilliant, where others would occasionally have moments of brilliance that you had to look for because we were all locked in because of deadlines or stress or just being super busy and no time to chat.

One thing I started to notice was the better I got, the easier it was to get out of people’s way. For example, in the early days, if someone really felt passionate about some architecture or coding approach, I used to get nervous, usually because I was projecting my insecurity about being held accountable for something I couldn’t fix in the case of it breaking or just not getting done on time. As a contractor/consultant, this can mean you just don’t get paid, and don’t pay your bills/rent/mortgage, and possibly get a client who will give you bad press, so it was quite hard to suppress emotions.

Over time, though, I started to get good where if something broke, I could fix it. If something broke, and I had never seen the code, I’d read it and understand it. If someone spent a week building something, and it was a mess, I could spend 2 days cleaning it up or rewriting it, eventually learning how to pair with the team to speed up & improve this.

This unlocked a lot of positive abilities. I no longer was afraid. I became a lot more open to wild, new ideas or approaches. If a junior/mid-level engineer wanted to do something crazy, I’d ask a few key questions, and then encourage their passion and let ’em rip. If they got into trouble, I knew I could help them. I started learning about certain guardrails to help these explorations be safer and more fun for everyone. Instead of risk mitigation, it became “what can we learn today and how can we have fun?”.

Now, while I accrued a lot of experience, the one nice thing about tech is you are surrounded by people who just start off, on day 1, being smart. So it’s always been a 2 way street; I teach ’em the fundamentals, things to watch for, and lead by example. They in turn teach me new things they learned, or different versions of techniques, or something from a past career path. Most importantly, they teach me how to be a better teacher. If you do this long enough, you’d watch many get to your level and eventually surpass you. I always saw leaders, the ones I liked, continue to push someone higher. If you look, often no one is pushing them; they are just selflessly helping others. Often that means getting out of their way and letting the other person cook. Those are the leaders I want to emulate.

I’ve been a Tech Lead for awhile, and I’m old enough to remember when many in the industry were juniors, and now some are Directors and VP’s, while others are the same, just an insanely leveled up version of themselves. The age helps because I can see the fruits of the labors. 100% of the time it was the person’s natural desire to get better, no doubt, but I love that I could be a part of their story where “Jesse helped”.

I try to remember this as I’ve had experiences where I felt a dictator approach was appropriate. Meaning, I know best, we’re going to do this. In Freelancing/Consulting solo on some projects, that’s the de facto way to handle some clients since they literately hired you to tell them what to do. However, in a team, democracies can get things done, and if you are polite, respectful, and honest, a vulnerable team builds trust, and this allows people to just do their thing and the work gets done right. Balancing that has been my favorite challenge. I never liked people who dictated ways to do things in code, but on the flip side, I recognize some devs just never knew certain problems had a name, and a pattern for ensuring they don’t happen. Sometimes, even if you explain that, a dev needs to experience those problems for themselves. They deserve that learning experience, but unlike many of mine, I want to ensure they have safety nets, including me, to be there in case things go wrong. You can allow others to learn with a small blast radius and way way less pain.

Over time, you watch many devs do 1 of 3 things:

1. grow to take on more and more responsibility, often going high up the reporting chain
2. changing roles as they discover they like managing more, or leading product/business more, or perhaps staring their own company
3. same as me; wanting to be close to the work, wanting to do more of it

There is a part of you that feels a little insecure when you start this; like why am I not some high level executive, or why haven’t I gotten bored and wanted to change my career path in tech? Over time, though, you “learn yourself”, what you like, and what your goals are. I’ve always enjoyed working with the juniors and the mid-level devs; teaching, having them teach me, and experimenting with ways to help them grow. I still get, and take opportunities to help more than just my team. Ultimately, my impact has always been the intimate communication for the sake of growth of a small group of people I have daily access too and being a Tech Lead allows me to do that. Maybe someday I’ll see and understand the allure of being a higher role than I am currently, but for years, I’ve enjoyed working on teams where I eventually get to the point where I’m not needed on that team because they become awesome. I believe they became awesome because they started as awesome, just little to no experience and I helped point them in the right direction and helped them lessen the pain of failures; basically what I always wanted people to do for me in my career. So they would of leveled up without me, but after seeing bad leadership and management in my career, I want to ensure their journey has good leadership and we have fun, and there is no way they can fail as long as I draw breath.

Keep in mind, leadership/management up the reporting train wants people to treat teams like that. If you take initiative, and ownership, of people’s growth, you make the team better, the software better, and the company better. That’s the job sometimes.

With age comes perspective, and as human programmers, we see patterns, and the pattern I see is that eventually, all those fellow devs grow, and eventually don’t need you. This can be hard to accept. You want the learning journey to last forever. You want to feel valuable to them forever. Some seek you out in the future to work with because they value your personality, attitude, knowledge, or just extra coding muscle. What I’m talking about specifically is they don’t need your leadership anymore; they’re at a point where they can lead their own team, or even teams. Some will still seek your advice from time to time, so it’s not 100% “done”, but you just need to emotionally prepare yourself that it’s a journey to love and the ending can be bittersweet. You want to, and should be, happy for their growth, but recognize that eventually they’ll no longer ask for help with a unit test, or why primitive obsession is a thing, or how you break up a PR. The best thing you can do at that point is get out of their way even more than you use too.

That could mean never talking in a meeting, or allowing them to take the initiative on “all the things”. You want to provide them space to be able to do that. There will always be work, and thus there will always be things for you to do. So sometimes you’ll be doing way less mentoring, BUT you can always still help in the normal ways even if they’ve grown beyond you; helping on PR’s, thoughtful comments on ADR’s, or networking on people who may fit a role for their team. The leadership and mentoring may change, as will the intensity, but it’s still needed, just a different form. You can still play a part in helping them, and often times that means getting out of their way, and trusting them to sometimes tell you what’s next.

You’ll often get a hint they’ll rise to this level when in the early days, they have a quick grasp of the business problems, or vast experience in a particular tool, possess a wonderful communication ability, or some niche project reveals their inner-genius. That should not intimidate you, but instead excite you to know you’re training not only potentially your replacement, but your future VP. Keep in mind some people don’t see their potential; it’s there, but for a variety of reasons, they don’t. You can be the simple key that unlocks it. I say simple to imply that small efforts on your part can make a big impact. I’ve also seen the opposite; wonderful people put in positions where leadership didn’t see that potential, and never found ways to unlock or give them opportunities to shine. You should view that as a duty to ensure those negative outcomes never happen.

I’m a self taught programmer with an art degree amongst many many people who got good grades in high school and got MBA’s from Stanford. I’m used to being around people way smarter than me. You’d think “How can I help these people if they’re so much smarter than me?” You should remember that your experience is valuable, and your desire to help is valuable.

I also have built up my confidence over the years by many small wins that accumulate over time. This is how I can feel secure in this environment, and at the same time be vulnerable, learn, and enjoy it so much. I want to build cool stuff with smart people, and I want those smart people to succeed, and they know that’s how I feel.

Reiterating, your experience is important, that’s why you became a Tech Lead; people trust your ability to “know where the team should go next, or what to focus on next”. You have to figure out what’s a suggestion vs. what’s a target that isn’t negotiable. You don’t have to do this alone, either; managers can help, fellow IC’s can help, and searching the internet for articles like these can help. Just always defer to assuming benevolent intent, and believing in the capabilities of others. Emulate leaders you admire. Make sure you’re having fun, else it’s not worth it. Learn yourself as to “why” you’re doing this.

One developer I debated with this on has a training course, and it looks quite thorough and good based on a 5 minute scan. That is also worrisome because in our debate he said “DI injection has nothing to do with testing” and “adding DI in just so it’s ‘easier’ to test is a terrible choice. DI doesn’t make testing easier. It makes testing systems that use DI easier, and that’s a big distinction.”

Given the amount of AI psychosis going around currently, I’ve been introspective to ensure it’s not “me” that’s confused. When they say “AI does all coding”, no it doesn’t. When they say “AI is worthless”, no, it can be helpful. I’ve used various models, tools, and practices to learn. I’m left with either I’m a rational centrist… or both of them are lying or crazy… wait, am I the one who is crazy?

For DI, I have no insecurities. The industry has been doing this for 40+ years, and for good reasons. Over half to do with testing, the rest with design despite design being the origins. It’s long and documented. To say it has nothing to do with testing, or is as bad choice is just wrong. To build a training course without using DI at this point is willful ignorance.

Introduction

There is some negative cultural stigma associated with DI because in early Java, there was a large exodus of developers to other languages. While Java development & industry use remains strong, so to does the stigma of “Java esque” connotations.

I hate when YouTube videos dive into history for 7 minutes instead “just tell me why DI is good/bad!”. DI is good, for both Object-Oriented Programming and Functional Programming. However, to understand why it’s so tainted, understanding the history explains why you get completely different reactions from from developers when it “seems so obvious to just use it”.

I get it, but you’ll need to have this context if you ever start “just coding, DI is a normal part of that” and you have a new co-worker or client who freaks out, or the reverse, you see they use no DI in their code, and their tests are… “interesting”. (That’s tact for “I need a new job, I can’t work with this code base”).

Java/.NET Egress

Many Java developers in the 2000’s fled to Ruby and Rails with it’s simplicity and basically one way to do things. A lot less code, a lot less configuration (hence the convention over configuration mantra they have).

Years later, many did the same to Node.js. Specifically, JavaScript on the server, not the client. While it may seem normal to lump JavaScript server-side developers with web developers, they are definitely two different communities and do not always agree.

Understand that many in this world WERE OOP devs at heart, they just disagreed with the approach Java took, and were heavily prejudiced against the complexity. Understand, too, the age differences. Some were from a C++ background from the 80’s and 90’s, and had similiar feelings. Others were much younger, but after a short stint in both languages, without all the experience, and context, many were quick to say “This seems much simpler than Java”. So you had a type of cargo culting happening as well to varying degree’s, but it was encouraged, sometimes unknowingly.

The same with Python and Django. What all 3 had in common was they still supported Object-Oriented Programming (OOP) paradigms, but without the low return on investment type ceremony in early Java, and all the configuration complexity. This meant getting up to speed, from a variety of skill levels, was much easier, but you could still pick and choose to bring what you knew. The same applied to early .NET/C# as well. Want to use the same class keyword, and a few OOP design patterns? Works about the same. What to build a lighter weight Inversion of Control framework? Much easier to do in dynamic languages.

These are the people who taught me.

Why DI?

DI was created in the 80’s to make configuring OOP code bases easier. Whether using a concrete class, or an interface, you could make your classes more flexible by injecting the class or interface instead of having the class build itself. Classes are often a black box; that’s the whole point of OOP, encapsulation & abstraction (I’m ignoring message passing because that is a depressing path).

Instead of a class instantiating it’s own logger:

class MyGame {
  constructor() {
    this.logger = new Logger()
  }

  movePlayer() {
    this.logger.info("Moved to new position.")
  }
}

You’d instead inject a logger instance in the class constructor:

class MyGameDI {
  constructor(logger) {
    this.logger = logger
  }

  movePlayer() {
    this.logger.info("Moved to new position.")
  }
}

This was often called “Inversion of Control”. Before, the class you created had control of what it created and when, but now, it’s done by classes higher up the class tree. The advantages were it was easier to swap out a new class that did something different (in-memory logger for profiling vs disk), or multiple implementations (decoding mp3, ogg, wav, etc files for an audio player).

Around the same time (in non-Java circles) there was a small rejection of inheritance being a good idea. It took awhile, but many in OOP felt composition, having classes inside of classes instead of extending a base class, was a better idea for easier to maintain code. DI helped make composition easier and throughout the late 90’s and early 2000’s, the “Composition Over Inheritance” phrase grew in popularity. The cargo culting here was less because all a developer had to do was create large inheritance hierarchies, then maintain the mess they created. So the general idea that classes should not create their dependencies, but instead receive them from the outside became a lot more standardized (but still not widely accepted).

Years later it was also discovered this made testing a whole lot easier because the tests could inject fake versions and the real code could inject the real versions, but your main source code didn’t need to change. This really helped software quality and speed, while still retaining the design & architecture benefits.

Testing

During the 90’s, developers from many backgrounds started recognizing DI’s usefulness in testing. At the same time, a ground swell was happening in both how you test, and how you build software. Kent Beck’s XP book, which talked about Test Driven Development, came out in 1999, and then 2 years later in 2001, the Agile Manifesto came out. A year later, the Spring Framework for Java came out, utilizing the “DI Container”.

Despite the $500,000,000 Sun marketing budget for Java and OOP, there was also this growing sense of software craftsmanship culture growing. 3 years later in 2004, Martin Fowler wrote the seminal “Inversion of Control Containers and the Dependency Injection pattern” that further popularized and cemented DI as the term.

From then on, you had this perception that DI was strictly for testing, and had nothing to do with design despite DI’s original purpose being for design.

Containers

What never finalized was “who creates the dependencies” in production code. In tests it was straightforward; the test. However, with the advent of Spring, DI Containers, e.g. “things to make the dependencies” became the norm in multiple languages, namely Java, .NET, and even in niche communities like ActionScript in Flash. These started as a class with no state; just 2 static methods that “make the production dependencies” and “make the test dependencies”. They weren’t all bad; having a global way to inject different behaviors was powerful, no doubt, but they never stayed simple.

The myriad of type systems, and their continued low value also complicated approaches. Some used interfaces “because that’s what the Java OOP people do”, whereas in the dynamic languages, you didn’t need any of that.

The complexity just spread from there, eventually infecting the tests. Around the same time, JUnit and other frameworks inadvertently created confusion around which test-double to use, when. To this day, even with Gerard Meszaros’s definitions, no one can agree on what they mean.

The Python, Ruby, JavaScript, and other communities rejected wholesale any type of DI Containers, but oddly imported the test-double confusion.

They keep trying to make a comeback in various languages with various success and failures. .NET continues to have many projects happily using DI containers, whereas in Node.js NestJS (Nest, not Next)does have some traction, but goes against the core, original Node.js rejection of overly complicated Java DI setups and design pattern soup.

Functional Programming and DI

In the background, Functional Programming was still practiced in niches and dark shadows. Many intelligent programmers visited, and some of those came back with good ideas, most of the smarter ones not explaining where they got them to ensure better adoption.

Two particular things that helped popularize DI in the FP world was:

1. some FP languages had side-effects
2. the type systems removed the need for interfaces

And, a 1b, those practicing FP ideas in non-FP languages also had to deal with side-effects.

If you’re not an FP developer, I cannot underscore how much FP developers detest side-effects and spend every waking moment attempting to avoid side-effects. This is because the draw to FP is determinism. If you base all your code on math, and math is always right, and always wrong, then you feel super comfortable and excited to build an entire program out of it… because your program will be predictable.

Except, that’s not how the real world works; at a minimum, you have side-effects, things that aren’t deterministic like reading a file, connecting to a server, or accessing environment variables. Will they work? Who knows.

Since everything in functional programming (Scala/OCAML being weird) is usually functions, that means dependencies are passed in as parameters, just like you’d do it in class constructors.

function movePlayer(logger) { ... }

There is one thing you can do, though, even in non-FP languages, and that’s build pure functions that always work, or always fail. That means, using stubs, you can use DI to inject happy path stubs and unhappy path stubs for testing, just like you’d do in OOP.

stubInfo = (...rest) => {}
stubLogger = { info: stubInfo }
result = movePlayer(stubLogger)

That’s the reason you never see “DI Containers” in FP languages because why would you build a framework around passing a parameter to a function?

The last part is types. Type systems traditionally have been much better in FP languages. This means creating those stubs in FP tests is easier because the function has to match a type. Interfaces in classes typically start with 1 method, but never stay that way because it’s too easy to add more, which is why it gets harder and harder to create test-doubles for things in older OOP projects. In FP, a function type is 1 function type; that’s it. You can easily create a function that returns a particular value in a test. The types ensure they match; no need for interfaces, importing those interfaces, then creating a fake class to implement that interface. This varies between languages; some are easier, but less type safe, and some are more type safe, but harder to stub.

Either way, while one could say DI exists naturally FP, it’s quite the opposite; passing parameters to functions has been normal since functions and methods were created. OOP became so complicated, they had to invent Inversion of Control, then rebrand to Dependency Injection, cut their teeth on the mostly bad parts of DI containers, then learn that “huh, you know, instead of Constructor Injection, you could just pass the dependencies in on the method that needs it, we could call it Parameter Injection, like… passing a parameter to a function”.

Conclusions

DI has a 40+ year history from starting as a code design tool to eventually becoming a core testing tool for both OOP and FP languages over 20 years ago. It is a powerful design tool, and powerful testing tool, and it’s normal, and expected to use it. If someone says it shouldn’t be used for testing, they don’t know what they’re talking about.

Our types currently:

type RegionsPossibly = Array<any>
regions1 = [ 'us-east-1', 'us-west-2', null ]

The regions Array is actually a union of string or null, so:

type RegionsMaybe = Array<string | null>

That means you’d have to filter them out at runtime.

Kibosh that nonsense, let’s have an Array of strings only:

type Regions = Array<string>
regions3 = [ 'us-east-1', 'us-moo-cow-moo' ]

Oh no, that removed the null’s/undefined’s, but now we have the possibly a region isn’t really a region.

… what _is_ a Region?

Let’s define a region using a Union to narrow it to just 2:

type Region = 'us-east-1' | 'us-west-2'
type RegionsForRealDoh = Array<Region>

We’re good now, right?

regions4 = [ 'us-east-1', 'us-west-2', 'us-east-1' ]

Oh no… Array’s allow duplicates!

Tuple’s are fixed length Array’s and fixed position. Let’s define all possible combo’s:

type RegionsAndOnlyOne =
  | ['us-east-1', 'us-west-2']
  | ['us-west-2', 'us-east-1']

Nice! This compiles:

regions5 = ['us-east-1', 'us-west-2']

But if you added dupes, it wouldn’t.

“Hey, can you add ‘eu-west-2’?”

Dude… tuples are cool, but also exponential based on their amount. That’s a type with >9 possible combo’s, I’m not writing all that! What if there were a way to create a type from a Union that handled that in case you need to add a new one later?

type Permutations<T, U = T> =
  [T] extends [never]
    ? []
    : T extends T
      ? [T, ...Permutations<Exclude<U, T>>]
      : never

Think of Permutations like a function, but for types.

We can use that to create a more flexible way to creating fixed tuples for drawing lists in our UI code without having to manually type all permutations. As the list grows, the type will become quite unreadable too.

Let’s add our new region to our Union:

type RegionNew = 'us-east-1' | 'us-west-2' | 'eu-west-2'

Then create a type using our type function vs. manually typing all the possible tuples:

type RegionsWithEU = Permutations<RegionNew>

regions6:RegionsWithEU = [
  'us-east-1',
  'us-west-2',
  'eu-west-2'
]

That allows any order with no duplicates. It’s safe to use in your naive React/Angular/Vue code to iterate through a list and draw it, no Cypress/Playwright or Unit Tests needed to validate.

Much more preferable, and flexible compared to the 2nd attached image .

And with that, your NULL/undefined issue in your UI is crushed, no unit tests or acceptance tests needed. (That said, you should still write tests).

Happy (and safe) array dot map ‘ing!

1959: COBOL was called “Common Business Language” so non-programmers can read it. We were so expensive, the Pentagon got involved. Now COBOL Cowboys charge up to $1,000 per hour. The syntax morphed to OOP to be more likeable/usable by programmers.

197?: MYCIN, the 1st AI/LLM like inference engine, used to recommend antibiotics for infections. Despite high scores, wasn’t used because of hardware limitations (like the data center bulid out & RAM shortage drama we have today). Later Intellicorps LiveModel allowed you to leverage this AI to model business processes. This in turn spawned many data scientist & software consulting opportunities.

1973: Wang 2200 computer was called “computing calculator” so it wouldn’t scare customers. Marketed as “exceptionally easy to operate” and “no esoteric skills are required”. Yet saving files was so obtuse, many users would reach out to tech support (reminds me if iPhone file saving). You had to program it in BASIC vs. “File > Save As or Command + Shift + F”.

1982: OpenEdge Advanced Business Language: programming language w/integrated database build for people who weren’t computer scientists. Same later “I guess only programmers use this, let’s make it more OOP”.

1983: IBM’s Query Management Facility & Crystal Reports ensured business people could get reports without IT involvement. Some of my early consulting work was “customizing these charts for this data with these systems”.

1985: Went the other way, attempting to remove the Domain Expert via CLIPS (NASA’s AI Language). Some used these Expert Systems to generate code which sometimes was better than a dev could write. You don’t hear much about expert systems from the 90’s – 2000’s, but you DO hear about devs building rules engines leveraging those Domain Expert’s and their knowledge.

1991: Visual Basic, PowerBuilder, and Delphi lead the way in “using visuals, you don’t have to know much about code and databases”. Then those apps reached a level of complexity, consultants/freelancer devs were hired to fix, modify, or rewrite these apps.

1994: Many CASE tools like Rational Rose utilized visual boxes and arrows to represent domain models, such as UML, and these would generate your application, not needing developers. UML’s creators today use UML to communicate architecture to other devs, but doesn’t use it to generate the code.

2000’s: Business Rules Engines were touted to allow Business Analysts to make decisions without programmers (offering a loan, credit card, or mortgage). Many data specifications, tools, libraries, and microservices are created to allow access to these rules, and today many devs & data scientists build these systems to run businesses.

Excel: … yes, the business doesn’t need us here. All hail the almighty Excel.

With the exception of Excel, all of these innovations created to replace devs either led to more of us needed or new job roles created. All lead to new tools and approaches. COBOL to using English vs math in coding syntax, MYCIN for LISP & Prolog to be cool, inference engines to be a thing, including Bayesian networks, RAG, logic programming, and truth engines.

Wang + others lead to the personal computer market, word processors, & accessible accounting tools to run businesses & people’s lives. PC’s were gateway drugs for many people to be exposed to BASIC, VB, and game dev. The UI & case tools of the 90’s raised the bar on expectations of developers for IDE’s; we expect IDE’s nowadays to visually help us navigate our code intelligently and allow the LLMS to help.

The RAD Tooling was overshadowed by the RAD development style which helped influence the world away from Waterfall to more Agile styles of working. This allows us to continually learn with our users to help inform how to build things, leading to constant learning and fun. UML and it’s ilk has lead to all kinds of great data formats like JSON, Markdown, and Mermaid charts.

All of these are cool, new things we can learn to make our jobs better, or new types of jobs with software. They always try to replace us. We always end up with new toys instead.

So don’t worry about your software job being replaced, or no new junior positions. If you like being here because you have a short attention span, love to learn new things, and build stuff… or all 3, you’ve chosen a technically great time to get into software dev.

We’re all still figuring this AI thing out, which is fun! Part of software dev is bravely/excitedly wading head first into ambiguity and going “I wonder how this works… what does that button do…” While opportunities right now suck because of the economy & over hiring, there ARE a lot of people who really don’t want to be here who are leaving, and the economy historically always gets better. Just keep going.

Get that STEM degree, go to that bootcamp, or keep trying to break into your junior role; the amount of software we have to build is only increasing, and we’ll use AI/LLM’s to help us do it. Find your passion in the field, whether that’s web dev like me, game dev, systems programming, data science/machine learning, cyber… or maybe you just gravitate towards a particular language, that’s cool too. There are so many fun niches in software dev.

There seems to be this trend that light, cheap bikes may have adjustable preload. Mid-weight have some combo of adjustable preload, front & rear with much better suspension parts. Heavyweights max out on top brands.

This creates 4 markets:

• oil viscosity
• drop-in cartridges ( aka emulators)
• fork kits
• adjustable rear kits

Most of the cheap suspension has little holes in the tubes in the front; liquid goes through these little holes to absorb bumps. It’s called “damper rod fork”.

The rate at which that happens is based on how thick the fork oil is. They can get hydro-locked when the hole is too small or the oil the wrong viscosity; meaning the oil can’t move fast enough to allow the fork to absorb the bump. Tradeoff of cheap forks. Regardless of suspension, oil viscosity can help / hinder based on road vs dirt.

The cheap way to significantly improve your front forks is to use a drop-in cartridge (aka “fork emulators”). Little circles w/valves that go into your front fork and can be adjusted to let more oil in & out. Help prevent hydro-locking & can increase plush feeling.

Many fork kits also come with new springs you drop into the front forks. Some even come with a new tube where you drill your own hole in the metal. They range from $200 – $400, so a great low-hanging fruit. Emulators + kits can absorb bumps, remove brake dive, & help in turns.

Finally, rear shock kits vary, but many provide preload, rebound, and damping adjustment with JUST a turn click; no tools needed. You can work on the shock, refill the oil reservoir, and they can last a long time. Spring choice here can be customized to your weight as well.

A lot of the above depends on the bike, and what kind of riding they’re doing, and where. Me, the street is fine, it’s when I get my ADV bike on off road I notice it’s not great (at least when compared to the dual sports blasting past me). Worse when I’m plowing over rocks.

So it appears the lowest hanging fruit is, in order:

1. adjust your suspension; most suspensions, even preload, can drastically improve the enjoyment of your riding. Use what you have, no need to buy anything.
2. doing cartridge drop ins
3. upgrade rear

The rear seems to be least passionate since, off road in the dirt/rocks at least, the front are what contribute the most. Seems opposite for the sport bikes? Anyway, Ari Henning has a good video on how to do the cartridges yourself.

However, there appears to also be drop in from Cogent which does not drilling anything so much easier to install. I may do some more research to compare the drilling vs not.

I may seem odd buying a bike, then spending $300 – $3000 on upgrading the suspension. However, regardless of bike and riding style, this seems to be the consistent thing that links them all: everyone loves better suspension. That means even if your bike comes with “ok” suspension, EVERYONE seems to be in agreement if you have the money, it’s always worth it.

The common refrain is “Once you’ve experienced good suspension, you never go back”. Again, the repeated caution is “your existing suspension _may_ actually be great, you just didn’t adjust to your weight & riding style”; even just preload adjustment can help.

That said, $300 seems paltry to improve quality of life + the learning experience, so… I may give it a go.