via GIPHY

Ok truth be told, it’s only been 25 years, but that didn’t flow as nicely in a title. What can I say?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

But seriously, thinking through those decades, I felt like piecing together the big themes. While many folks work at one firm for 2+ years, two decades would bring experience at ten firms.

In that time I’ve worked at 5-6 per year, bringing my total to over 100 firms. This has given me some perspective that’s unique and some useful patterns emerge.

1. Should have, could have, would have

In quite a number of companies, I’ve been brought in as the second wave. What do I mean by this? Well the first founders, builders and creators have left, and their technology still stands. So it is not our job to sift through the documentation and maintain those systems or expand.

What challenges happen with this?

A. Managing and reducing complexity

When you are handed an infrastructure with myriad servers, databases, programming languages, frameworks, libraries, security keys, and assets, you’re thinking, how can I simplify all of this. That is your number one concern.

So for the folks enabling microservices these days, please please please consider the future. Does that mean microservices is a non-starter? I don’t know. What I do know is the cambrian explosion of each dev gets whatever they want, is dangerous. By not standardizing on languages, frameworks, databases, or anything, you allow the inevitable creep of complexity.

B. Looking for documentation

When it’s quitting time, you won’t be able to document things. Push for this early and often. You won’t always get it, but try try try. Code commits can enforce comments. Inline, infrastructure, and automation go a long way too.

C. Managing performance and support

As complex systems age, performance often suffers. Packages and libraries need to be patched, or are no longer maintained. That’s when the big boring technologies really become your friends, because they’re still around, and still doing their jobs!

All this points back to reducing complexity and even god forbid using boring technology.

Read: Should every engineer try a spell in consulting?

2. Look for low hanging fruit

Low hanging fruit are like the elephant in the room. They’re big and can have a big impact. But sometimes nobody seems to notice them. Your job is to think critically and notice them.

For example the age-old battle with ORMs. They’re still finding their way into web applications mostly because nobody wants to learn SQL. Hey they solve the problem right now, the performance problems won’t occur until I’m long gone. No! I love what Justin Etheredge wrote – relational databases aren’t dinosaurs, they’re sharks. Wow, that packs so much truth into one sound bite!

If you can remove technologies, do it. If you can do the job with 5 servers instead of 10 smaller ones, on 5 different stacks, do it. Keep it simpler!

Read: Is it time to diversify your cloud?

3. Good data is gold

Whether it’s state agencies, fighting with the federal government about who is doing what correctly in the pandemic, or business teams making fair forcasts of the market for your minimum viable product.

All of these require clean data. Data that has been scrubbed of inaccuracies, messy state fields, missing names, round off errors, and the rest. It’s a dirty job, but it has to be done.

Being serious about how *good* your data is, where it is lacking, where it is downright untrustworthy, these are all disciplines, that everyone in the organization must participate in.

A stubborn nose for finding the truth will help. A Lt. Columbo sense of curiosity. And persistent diligence. All contribute to this end goal.

Related: Can I secretly deploy a key to production?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters