A friend of mine told me a story recently that's been stuck in my head. His company made an acquisition, and along with it they inherited the acquired company's infrastructure. Most of it was fine. But one system stood out: a desktop NAS with a couple of drives striped in RAID 0, running the acquired company's financial system.
I watched a video recently about the hidden costs of microservices, and it put words to something I've been thinking about for a while. The video walks through the usual pitch - break the monolith apart, give each function its own service, deploy independently.
The last post in this series ended with a line I wanted to come back to: managers - especially first-line managers in more hierarchical orgs - are not always empowered to change the systems they're operating in. They're functions of those systems too.
The last two posts in this series have been about curiosity - what it looks like when people have it and what happens when the environment kills it. A friend responded to the second one with something I've been thinking about since: the framing issue.
I wrote a post a couple of weeks ago about unprompted curiosity - the idea that the engineers who dig into things without being asked are the ones who end up driving direction. I still believe that.
Early in my career, I said yes to everything. Extra project? Sure. Meeting I didn't need to be in? I'll be there. Feature request that didn't quite fit the system? I'll figure it out.
I've been in this industry long enough to watch careers diverge. Two engineers start at roughly the same place - similar skills, similar experience, similar opportunities.