I like automations for inclusive development | Hacker News Reader

I like automations for inclusive development

blog.lmorchard.com

18 pointscoloneltcb11 comments

> But, there are usually other folks on the team who don't primarily code or fuss with servers for a living - e.g. product managers, designers, writers, researchers, et al. I'd like to empower these folks to help contribute to the development process just as easily as any coder.

This is a nice sounding goal until these non-devs feel so empowered that they want to make changes to your automations and ruin the integrity of the project (and blame you while they're at it). They will have more authority as a group than you as an individual yet none of the expertise. Not just yak shaving, but backseat yak shaving. What a nightmare.

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.

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.

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.

> 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.

Yeah, that sounds like fundamental team dysfunction that no amount of engineering tooling or gatekeeping will address in any positive way.

Even the best management and company culture cannot change that. In engineering terms, these "dysfunctions" are analogous to impedance mismatch.

Hire people who actually know what they're doing and only keep them for as long as they will work as hard as your devs. If they start burning out and shoveling their work onto devs you must protect your dev team. Let's not forget that non-devs are supporting staff. They're not essential and you're better off without them and their incompetence. Even the tiniest slack from them will be highly disruptive as errors accumulate and waste lots of time. Why not just make cuts and save your payroll while you're at it? If you have doubts look at any startup. A skeleton crew looks like almost all devs.

I have to say, this is an incredibly arrogant and unhealthy attitude. Based on your comments here it sounds like you might actually be the main problem at your organization.

I would recommend spending some time reflecting on your ability to form relationships with others and try to come to see the contributions that all the members of your organization can make.

> your ability to form relationships with others

Not sure where you're getting this from. I have worked with both competent and incompetent people regardless of their role.

The relationships between coworkers are built on their competence, not their personalities. Professionals focus on the work not self-expression. The most competent people I've worked with have always been straightforward and neutral in temperament and that's all anyone should expect.

> A lightweight tool I've used toward this end is Storybook.

Storybook is one of the least "lightweight" tools available.

I mean, not compared to having to stand up an entire server cluster of Docker containers and friends

Reply on news.ycombinator.com