4 ms·

Interesting read, but I wish it wasn't so inflammatory. > "...release coordinators and the like are at the bottom of the totem pole. Why is it arranged like th

by keyanp 11y ago

Interesting read, but I wish it wasn't so inflammatory. > "...release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this? Because each role can do the job of all roles below it if necessary." I find this to be belittling those who choose to work on a different part of the stack than the author. It seems to suggest there is an innate incompetence that keeps release engineers from functioning as "developers". That couldn't be further from the truth. Release Engineering @ Mozilla: https://www.youtube.com/watch?v=7j0NDGJVROI https://www.youtube.com/watch?v=7j0NDGJVROI

falsedan 11y ago
Release Engineer here too. FUNNY STORY: we make the developers act as release coordinators, because it distracts us from the work of improving the release process by replacing it with automated software systems. The top of his hierarchy should be PMs/executive team; betrayed by his own developer ego…
- serge2k 11y ago
  It's a hierarchy of skills. PM and exec skills are almost entirely orthogonal to tech skills. Putting them in this hierarchy makes zero sense as a result.
  - lowmagnet 11y ago
    Because understanding the business's and customers' needs is somehow "beneath" developers in skill or status? Sounds like some people need to try the "less technical" parts of the stack like requirements gathering to appreciate their roles.
    - zaccus 11y ago
      "Orthogonal" means independent from, not inferior to.
  - falsedan 11y ago
    I see you work for a PHB
serge2k 11y ago
not gonna watch, but developers who work on release tooling are just a category of developer. The article is inflammatory to a degree, but it does make sense applied to groups rather to individuals. Devs do have to learn a lot of the skills the other groups do, but it doesn't go the other way. There are still obviously valuable skills that a DBA or sysadmin will have and your average dev won't. It doesn't change the fact that, as groups, I'd rather have a group of devs be forced into DBA and Sysadmin tasks than the other way around.
timv 11y ago
As well as being inflammatory and belittling, his reasoning in this area also fails to question the status quo, and realise that maybe a form DevOps is a path to a better outcome. It is the case, that in many organisations, the roles down the bottom of his totem pole are less skilled than the top. There are point-and-click DBAs and Server Admins and release managers who don't have the base skills to write software. But they're rarely very good at the roles they're doing. I have a bunch of issues with what a lot of organisations do under the banner of "DevOps", but part of what it is trying to do is bring engineering solutions to those layers "down the totem pole". I want DBAs that invest in reliable, repeatable, automated processes. And that means I want them to be able to build working software. And similarly with the other roles he mentions. Now, generally speaking, you'll get more useful work from a system admin who just follows the procedure they were given, than you will for a developer who does likewise. But, if you can do it, you will get plenty of value from hiring people with some engineering skills/training into all those roles. The counter examples are the system admin who takes 2 weeks to setup a new server because it's all done by hand every time. Or the release team who buys fancy "automation software" to automate a broken process because they don't understand the process well enough to build a working solution. Or the operations team that just reboots the server when it's broken because they don't have access to people with skills to diagnose the problem. Or the QA team that builds automated testing tools that are completely unmaintainable because no one in the team has a background in software engineering. The totem pole hurts because - it (often) treats the people at the bottom quite poorly. - as a consequence it discourages good people from taking roles "at the bottom". - which leads those teams to produce far-from-optimal solutions. Not (necessarily) for lack of effort, just because they don't have the skills + training to build the optimal solutions. (Obviously, as your Mozilla example shows, some organisations manage to escape that trap) If you need to hire less qualified/skilled people, then you're probably better off putting them into the roles that are "at the bottom" of this supposed totem pole, but if you can fill all the roles with solid engineers then you'll reap rewards from it.

by keyanp 11y ago

falsedan 11y ago

Release Engineer here too. FUNNY STORY: we make the developers act as release coordinators, because it distracts us from the work of improving the release process by replacing it with automated software systems. The top of his hierarchy should be PMs/executive team; betrayed by his own developer ego…

serge2k 11y ago
It's a hierarchy of skills. PM and exec skills are almost entirely orthogonal to tech skills. Putting them in this hierarchy makes zero sense as a result.
- lowmagnet 11y ago
  Because understanding the business's and customers' needs is somehow "beneath" developers in skill or status? Sounds like some people need to try the "less technical" parts of the stack like requirements gathering to appreciate their roles.
  - zaccus 11y ago
    "Orthogonal" means independent from, not inferior to.
- falsedan 11y ago
  I see you work for a PHB

serge2k 11y ago

not gonna watch, but developers who work on release tooling are just a category of developer. The article is inflammatory to a degree, but it does make sense applied to groups rather to individuals. Devs do have to learn a lot of the skills the other groups do, but it doesn't go the other way. There are still obviously valuable skills that a DBA or sysadmin will have and your average dev won't. It doesn't change the fact that, as groups, I'd rather have a group of devs be forced into DBA and Sysadmin tasks than the other way around.

timv 11y ago

As well as being inflammatory and belittling, his reasoning in this area also fails to question the status quo, and realise that maybe a form DevOps is a path to a better outcome. It is the case, that in many organisations, the roles down the bottom of his totem pole are less skilled than the top. There are point-and-click DBAs and Server Admins and release managers who don't have the base skills to write software. But they're rarely very good at the roles they're doing. I have a bunch of issues with what a lot of organisations do under the banner of "DevOps", but part of what it is trying to do is bring engineering solutions to those layers "down the totem pole". I want DBAs that invest in reliable, repeatable, automated processes. And that means I want them to be able to build working software. And similarly with the other roles he mentions. Now, generally speaking, you'll get more useful work from a system admin who just follows the procedure they were given, than you will for a developer who does likewise. But, if you can do it, you will get plenty of value from hiring people with some engineering skills/training into all those roles. The counter examples are the system admin who takes 2 weeks to setup a new server because it's all done by hand every time. Or the release team who buys fancy "automation software" to automate a broken process because they don't understand the process well enough to build a working solution. Or the operations team that just reboots the server when it's broken because they don't have access to people with skills to diagnose the problem. Or the QA team that builds automated testing tools that are completely unmaintainable because no one in the team has a background in software engineering. The totem pole hurts because - it (often) treats the people at the bottom quite poorly. - as a consequence it discourages good people from taking roles "at the bottom". - which leads those teams to produce far-from-optimal solutions. Not (necessarily) for lack of effort, just because they don't have the skills + training to build the optimal solutions. (Obviously, as your Mozilla example shows, some organisations manage to escape that trap) If you need to hire less qualified/skilled people, then you're probably better off putting them into the roles that are "at the bottom" of this supposed totem pole, but if you can fill all the roles with solid engineers then you'll reap rewards from it.