10 Lessons from a Self-Taught Engineer Working on Large Scale Software

Late game, abstraction can save lives.

But trying to abstract too early can be murderous. If you are confident in some key patterns, abstract away. For everything else, wait until patterns emerge.

The old heads of architecture are more right than wrong.

We throw away the teachings of folks like Martin Fowler, Vaughn Vernon, & Eric Evans at our own peril. Scaling distributed software development is a hard problem. Innovate, but also learn the art.

Be a rockstar, but respect the band.

You can't clone yourself. Communication is what separates good engineers from great ones. The most epic engineering feats require a team.

Resume shmesume.

When I first started conducting interviews, I would often get intimidated by an accomplished resume. Imposter syndrome or whatever. Over time, I realized people's resumes could be much more impressive than their actual ability to contribute. Choose co-workers that are capable, honest, and driven first; accomplished second.

Conway's law is worth understanding.

It will rear its head. Find the places you are creating friction against it & fix them.

Performance is a hard problem. Monitoring it can be even harder.

Shift left early and don't take your eye off it. Don't make it the responsibility of a single team to track. Empower devs with good tooling and resources to tackle performance directly. RUM is great, but so are synthetics. Use both & prosper.

Prefer composition over configuration.

Being able to construct an application via loosely coupled components is a super power. It benefits testing, on-boarding / team scaling, documentation, and re-use. You probably don't need to build a framework... You just need a well communicated approach & mental model.

Outside of (maybe) observability & analytics, singleton patterns are rarely worth it...

Especially if you are trying to build through composition. Dependency injection can feel tedious, but there is nothing worse than cleaning up an ugly singleton reference in 400 source files (and tests). Learn to think in ports & adapters. Thank me later.

Software will evolve.

Creating or relying on systems that are hard to pivot from will bite you later. The abstract magic that saves you 1 day of work could cost you weeks or months later. I'm looking at you modern web dev 🧐. If you can't "eject" from the magic, strongly consider whether you should use it.

"It depends" is the most important mantra in engineering.

Don't get too stuck in any particular dogma, especially around a piece of technology. Even my points above are subject to change / criticism in different circumstances. An open mind is the antidote to an ever changing world.