Approaching 40 years old and two years since I changed direction as a software developer, I conclude that the grass really is greener on the other side. Perhaps I should have jumped earlier.
Where I'm coming from
Most of my career I've been a consultant working with .Net development and specialised in SharePoint (described in Getting a Divorce From SharePoint). When I read The Phoenix Project I strongly identified with the pre-transformation description and the different characters described in that book. At one time, me and a colleague had a great laugh comparing our work situation to the film The Martian (where the main character is stuck alone on Mars, click the link and see the trailer to get a feeling for what I mean). Our job felt just as complex and challenging – and we were only maintaining a bloody website! To be fair, it was a website selling products for a couple of hundred million EUR annually, but still.
Not all problems should be solved, some should be avoided. When things are complicated due to accidental technical debt rather than complex due to supporting a complex world, walk away.
Another aspect of your career is how much you learn over time. Do I have x years of experience or 1 year of experience x times?
Sample tech:
- Visual Studio (Not responding)™
- .Net Framework 4.x
- Team Foundation Server (using TFVC)
- SharePoint Server
- MS SQL Server
- Windows Server
- Virtual machines weighing 100+ GB
- Lenovo P50
- README for monthly "deploy weekend"
Where I'm now
Now I'm in ops, part of a team named Tooling that provides the infrastructure and tools for other development teams to run their applications on. I'm the least experienced in the team when it comes to infrastructure and the tools we use, so I learn a ton of new stuff all the time. Having taken a web interface for granted for almost all of my career, the primary user interface our team is building right now is a CLI.
As a developer in our organisation, you create a new service (API, web app, etc.) by using our CLI. It will ask you a few questions: name and description for the service, what team owns it, select the upstream services it depends on etc. That takes care of all the boring stuff you need, but don't want to deal with as an application developer, like logging, monitoring, TLS certificates etc.
Naturally, the idea of infrastructure as code isn't something you have to sell to someone like me with a coding background, but seeing it in action is still fantastic. Even if this isn't feasible for a small company, we're certainly not as big as Google, Amazon, Microsoft or Facebook.
I find it delightful to primarily work with open source products. We buy commercial software when we find that's the best option, but we don't buy a product that claims to do everything. There is a big difference in choosing the pieces that best fits the puzzle you're trying to assemble, vs buying a complete puzzle that you have to retrofit your existing pieces into.
Sample tech:
- Visual Studio Code (still avoid Vim)
- JavaScript/TypeScript
- Go
- Node JS with koa or Apollo Server
- Docker, Terraform, Nomad, Consul, Jenkins, Neo4j, Grafana, Graylog, Prometheus...
- Mob station with large TV and Ubuntu Linux NUC + personal MacBook Pro
Next actions
I will keep evaluating my learning and how fun I think my job is. In hindsight I should probably have made a change earlier, but I wasn't unhappy before either and I guess that's the tricky part when it isn't as clear as black and white.
I hope I have contributed to better ways of working earlier in my career as well, but some things are hard to change within a specific role or organisation. Some people prefer stability and familiarity, but "git hooks" are better than "deployment weekends"!
Read (or listen to the audio books) The Phoenix Project and The Unicorn Project and listen to Rich Hickey's talk Simple Made Easy if you haven't, that's my next actions for you 😉
Top comments (0)