3 ms·

My own experience is that those non-devs feel as much attached to the success of the project as anyone, and the changes they want to make to automations are tak

My own experience is that those non-devs feel as much attached to the success of the project as anyone, and the changes they want to make to automations are taking a broader view of consistency across multiple domains of the project.

sublinear 3y ago
I don't entirely disagree, but the limitation is still a lack of attention to detail from non-devs. Experience and passion aren't substitutes for that. I agree with the spirit of the article, just not the suggested solution. My experience has been that even the most competent non-devs are far less consistent with details than even a half decent developer. This is because developers have much better tools at their disposal to ensure consistency and immediately obvious consequences for not being consistent. There are no such consequences for non-devs other than hearing devs whine "I told you so" after being ignored before a prod release. All a developer needs is more rigorous requirements that are on the same level as compilers, linters, diffs, etc. This is, of course, not a reasonable ask if the project is complex enough. Luckily many projects aren't that complex and non-devs don't really need automation. In fact automation will ensure a lazy and foolish consistency getting in the way of better decisions. It should not be about making non-devs' lives easier, but making the product better. I shouldn't have to convince anyone that my suspicions of automation being a "silver bullet" are valid. Bad management is everywhere and notorious for these tactics to avoid difficult discussions with non-dev teams. The solution I've seen work very well is fewer meetings with clients and other stakeholders and more meetings with developers. Sadly so many non-devs are deeply intimidated by that. Let's not mince words it really is just a blame game once non-devs are easily overwhelmed. Expect non-devs to writhe in pain and maybe even create HR incidents when they're pushed to work harder... or just live with a mediocre product. Your choice.
- couchand 3y ago
  If we're going to arbitrarily categorize groups and order them by attention to detail, the canonical listing is: - docs - tester - dba - project manager - dev - manager But given the state of the industry it's possible you've never worked with anyone in the first several groups. All kidding aside, your problem sounds like it's rooted in a lack of trust leading to breakdown of communication. The proposal to talk LESS to the people that you already don't see as "on your team" will inevitably perpetuate the cycle. > All a developer needs is more rigorous requirements You may be under the impression that your job is to talk to machines, but it's really not. Your job is to talk to people and develop that rigorous specification collaboratively.
  - sublinear 3y ago
    > But given the state of the industry it's possible you've never worked with anyone in the first several groups. I have. I don't agree with your list and am taking it as a joke. DBAs, "managers", and "project managers" typically have plenty of dev experience. Everyone should be in the loop as much as possible. It's more often than not non-devs will miss tons of detail and oversimplify to the detriment of the project. > You may be under the impression that your job is to talk to machines, but it's really not. Your job is to talk to people and develop that rigorous specification collaboratively. >> The solution I've seen work very well is fewer meetings with clients and other stakeholders and more meetings with developers I think you might have missed something I wrote. :) I don't think we disagree and love collaborating with diligent non-devs who will trust the expertise of their dev team while giving their own feedback when compromises need to be made. The question is simply who they need to spend more time with to get that good result. Every project is a little different, but more time with devs is usually the answer in my experience.

sublinear 3y ago

I don't entirely disagree, but the limitation is still a lack of attention to detail from non-devs. Experience and passion aren't substitutes for that. I agree with the spirit of the article, just not the suggested solution. My experience has been that even the most competent non-devs are far less consistent with details than even a half decent developer. This is because developers have much better tools at their disposal to ensure consistency and immediately obvious consequences for not being consistent. There are no such consequences for non-devs other than hearing devs whine "I told you so" after being ignored before a prod release. All a developer needs is more rigorous requirements that are on the same level as compilers, linters, diffs, etc. This is, of course, not a reasonable ask if the project is complex enough. Luckily many projects aren't that complex and non-devs don't really need automation. In fact automation will ensure a lazy and foolish consistency getting in the way of better decisions. It should not be about making non-devs' lives easier, but making the product better. I shouldn't have to convince anyone that my suspicions of automation being a "silver bullet" are valid. Bad management is everywhere and notorious for these tactics to avoid difficult discussions with non-dev teams. The solution I've seen work very well is fewer meetings with clients and other stakeholders and more meetings with developers. Sadly so many non-devs are deeply intimidated by that. Let's not mince words it really is just a blame game once non-devs are easily overwhelmed. Expect non-devs to writhe in pain and maybe even create HR incidents when they're pushed to work harder... or just live with a mediocre product. Your choice.

couchand 3y ago
If we're going to arbitrarily categorize groups and order them by attention to detail, the canonical listing is: - docs - tester - dba - project manager - dev - manager But given the state of the industry it's possible you've never worked with anyone in the first several groups. All kidding aside, your problem sounds like it's rooted in a lack of trust leading to breakdown of communication. The proposal to talk LESS to the people that you already don't see as "on your team" will inevitably perpetuate the cycle. > All a developer needs is more rigorous requirements You may be under the impression that your job is to talk to machines, but it's really not. Your job is to talk to people and develop that rigorous specification collaboratively.
- sublinear 3y ago
  > But given the state of the industry it's possible you've never worked with anyone in the first several groups. I have. I don't agree with your list and am taking it as a joke. DBAs, "managers", and "project managers" typically have plenty of dev experience. Everyone should be in the loop as much as possible. It's more often than not non-devs will miss tons of detail and oversimplify to the detriment of the project. > You may be under the impression that your job is to talk to machines, but it's really not. Your job is to talk to people and develop that rigorous specification collaboratively. >> The solution I've seen work very well is fewer meetings with clients and other stakeholders and more meetings with developers I think you might have missed something I wrote. :) I don't think we disagree and love collaborating with diligent non-devs who will trust the expertise of their dev team while giving their own feedback when compromises need to be made. The question is simply who they need to spend more time with to get that good result. Every project is a little different, but more time with devs is usually the answer in my experience.