Fabio Cicerchia - Issue #131
👋 Hi, this is Fabio with the biweekly issue of the DevPath Newsletter.
Each issue delivers curated content for engineers and leaders in tech,
ideal for busy people as it gives an extract of the latest news and trends.
Before software can be reusable it first has to be usable.
— Ralph Johnson
Architecture
Martin Fowler Was Right: Microservices Suck*
Reading time: 5 mins
Andrew Hunt and David Thomas’ “The Pragmatic Programmer: From Journeyman to Master” is by far one of the most popular books among software developers, yet I wonder just how many software engineers actually read the thing. While that’s certainly not the book that goes into the ins-and-outs of microservices and monoliths, it teaches a fair bit — dare I say everything — to make educated, some might say pragmatic decisions when it comes to building software. The TOC alone is pure gold! Yet 25 years later, the industry still doesn’t seem to have learnt its basic lesson — namely to use the right tool for the right job.
Another big name, one that made his name following just that philosophy, is Martin Fowler. Anyone who is familiar with the concept of continuous refactoring has likely also heard of Martin. He has an entire book on just that, but if you’re lazy or broke, here’s the extremely abridged version: “Always be refactoring. If you touch the code, and you can improve it, improve it, but never optimise early.” There. A book in two sentences. Luckily, he hasn’t just shared his wisdom on refactoring, but many other contemporary software development topics such as architecture, more specifically monoliths and microservices.
Career
How Managers Can Make Time for Their Own Development
Reading time: 7 mins
Managers today must balance their day-to-day work with multiple “ands,” such as delivering on quarterly objectives and thinking strategically. Given these numerous demands, managers tend to deprioritize their own career development. It doesn’t have to be that way. The more managers take control of their development, the better able they’ll be to avoid the common career mistakes that will get in the way of their growth. And the more their team members see the positive impact of investing in their career development, the more likely they are to do the same.
Health
Should There Be a Developer Mental Health Day?
Reading time: 3 mins
Developer burnout is growing and I see little being done to reduce this. The amount of software being created is growing by a growing number of developers. The number of developers burning out will continue to grow.
Developers overworking for free and trying to sprint for months without a break is a process that is working for managers, so they keep doing it (getting more work out of development resources)
Developers overworking plagues software development and developers have less time for development with the increase in teams meetings (But without a change in deadlines).
Methodologies
If You’re Not a T-Shaped Skill Member, You’re Not Doing DevOps Correctly
Reading time: 4 mins
DevOps is not just a methodology; it is a mindset and a cultural shift that emphasizes collaboration, agility, and continuous improvement. By embracing T-shaped skills, organizations can unlock the true potential of DevOps, fostering a workforce that is adaptable, collaborative, and capable of delivering high-quality software at a rapid pace. T-shaped skill members bridge gaps, break down silos, and drive innovation, propelling organizations towards success in the ever-evolving world of software development and operations. So, if you aspire to excel in DevOps, remember that being a T-shaped skill member is not an option but a prerequisite for doing DevOps correctly.
Productivity
Too Many Meetings At Work? Here’s How to Stop the Meeting Madness
Reading time: 13 mins
Too many meetings. I had said those three words way too many times that month. Sometimes as a fleeting comment to myself. Other times in the form of self-pity as this excessive, self-absorbed unhappiness over the current state of my work.
Instead of shouting at the top of my lungs and getting myself out of the rut I had fallen into, I simply accepted it as a way of life “this is how it’s supposed to be and I can’t really do much about it.” After all, I consciously opted in to be a manager and way too many meetings somehow seemed like a part of a manager’s job.
A few months passed by and then things got worse. My scope increased, my team size more than doubled and so did the number of meetings. I absolutely lost control over my time. I was in a constant state of frenzy throughout the day moving from one meeting to the next only to be left exhausted, disoriented and grumpy.
Mix
Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.
Reading time: 13 mins
Software engineering teams can be complicated, and finding a solid approach to structure them for success is not easy. Probably, because there is no single way of doing it. My experience taught me that whilst there is no one-fix-all solution, some approaches have more pros and a higher success rate than others. I want to share and review some of the most common team structures and dig a little bit into a solution that worked well for me across different organisations of various sizes and specialisations. Whilst I don’t have the perfect answer, it could be good as a starting point for any high-performance team of skilled individuals who value contribution and meaning above politics and typical corporate BS, which creeps into organisations too often.
Thank you for making it to the end! 🤗
If you enjoyed this newsletter, please send me feedback, fill out a quick survey or share it with others!
If you were forwarded this newsletter and liked it, subscribe here.
Have a great week 😉