Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
I read the paperback version of this book (20th anniversary edition 1995) a few years back, when I was getting deeper into being the core Solaris gatekeeper and figuring out how to improve our back-end tools.
At that time Solaris org was ~2500 people and we had many many decades of experience at different methods of software project planning, implementation and delivery.
The core message of TMM which has stuck with me over the years is that the project team size at which you need to get a project/program manager and somebody whose primary focus is tooling is actually quite small. That is exactly what we did with Solaris - though we did rotate people through those roles so that both the benefits and the pain were shared throughout. As a worldwide organisation this was perhaps even more important than in a geographically disparate but still same-country team.
Another core value we had was that everybody was empowered to not only suggest improvements in (or log bugs against) the common build tools, but to also go and fix those tools themselves. Apart from providing a good way for new staff to learn about our dev methods and approaches, it was just a core part of the corporate culture.
That's the one bit of advice that I wasn't so sure about from TMM -- that even groups as small as four people should have an "architect" and a "tools designer". But I don't have much experience in the industry, so I'll have to take your word for it!
Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
My experience is that when you've got fewer than 10 people in the team, many of those roles can be combined - or even just shared around. Though I'd make sure that there's just one architect. If you've got a small team you have to work with and around each other, and I suggest that in that sort of environment everybody should be tasked with process as well as code.
That could get a little interesting if you have people of wildly differing skill levels, but the more senior members should be taking the lead on pulling the juniors up to their level. If you're in a team that small and the seniors aren't doing that, then they're not pulling their weight and you need to find a way to get them to do so.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I read the paperback version of this book (20th anniversary edition 1995) a few years back, when I was getting deeper into being the core Solaris gatekeeper and figuring out how to improve our back-end tools.
At that time Solaris org was ~2500 people and we had many many decades of experience at different methods of software project planning, implementation and delivery.
The core message of TMM which has stuck with me over the years is that the project team size at which you need to get a project/program manager and somebody whose primary focus is tooling is actually quite small. That is exactly what we did with Solaris - though we did rotate people through those roles so that both the benefits and the pain were shared throughout. As a worldwide organisation this was perhaps even more important than in a geographically disparate but still same-country team.
Another core value we had was that everybody was empowered to not only suggest improvements in (or log bugs against) the common build tools, but to also go and fix those tools themselves. Apart from providing a good way for new staff to learn about our dev methods and approaches, it was just a core part of the corporate culture.
That's the one bit of advice that I wasn't so sure about from TMM -- that even groups as small as four people should have an "architect" and a "tools designer". But I don't have much experience in the industry, so I'll have to take your word for it!
My experience is that when you've got fewer than 10 people in the team, many of those roles can be combined - or even just shared around. Though I'd make sure that there's just one architect. If you've got a small team you have to work with and around each other, and I suggest that in that sort of environment everybody should be tasked with process as well as code.
That could get a little interesting if you have people of wildly differing skill levels, but the more senior members should be taking the lead on pulling the juniors up to their level. If you're in a team that small and the seniors aren't doing that, then they're not pulling their weight and you need to find a way to get them to do so.