Comment by ftmootnomoat
6 hours ago
This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better).
Meetings that increases sync between customer and coder are few and precious.
In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to appear relevant.
I personally am fond of meetings with customers, end-users, UX designers, and actual stakeholders.
I loathe meetings with corporate busybodies who consume bandwidth for corporate clout.
No, I don’t need another middle manager to interface themselves between me and my users.
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals.
Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.
I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749
For that matter, here's a thread from a few days ago recommending the practice of scheduling status meetings for the purpose of pressuring the attendees to work on your project in addition to their other work: https://news.ycombinator.com/item?id=47906942
What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!
Well said.
This matches perfectly my experience in working in many companies, where in most of them meetings were useless, but in a few places meetings were very useful, depending on how the companies were organized and how the attendance to meetings was selected.
I have seen projects that had to be abandoned without bringing any money, despite being executed perfectly according to the specifications. The reason was that the specifications were wrong because the customers have not thought about describing some requirements and the developers could not ask about those, because of lack of direct communication, while the middle men had no idea about both things, about what the customers might require and about what the developers might need to know.
Not a false dichotomy. I agree with OP and I can say for certain that if you are one of the few developers that is "fond of meetings with customers" you are not the the type of person OP is talking about, and you are more rare than you think.
I am a former Dev turned PO/PM and now CEO, I can tell you many a developers are not fond of those meetings you are fond of and people like myself don't insert our selves where we don't belong, we simply join the meeting and have the vital conversation with the customers/stakeholders whos payments make payroll possible, while the developers refused to.
My team have always commented and liked that I "shielded" them from the none technical meetings and distilled customer needs in our kanban, without them having to go to the meeting. While I agree this isn't the "best way" to do things, I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case!
Also for those who think I'm down talking the abilities of my team, we made a company together when we left a huge company we worked for, as Co owners and even now we use same setup is used :)
> you are more rare than you think.
Truth. I'm that person and didn't appreciate how rare I was until I became an EM and learned that most of my team would actively avoid conversations with the customer. Even though I have no way to quantify it, I'm sure it's benefitted my career.
Are those people in contact with the customer able to make decisions regarding the roadmap or feature design? It’s a miserable position to be in front of unhappy customers while having no power to solve anything (which is why I tend to be polite with customer support).
There's an in-between point that I think is better than either, but it can be more difficult to find the right balance: Direct contact with internal stakeholders (with the manager still somewhat involved to still have a good overall view and help prioritize / push back / act as a general buffer), while shielded from customers. That's the place I've always preferred.
> I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case!
I think a lot of HN truly believes that Software Developer is the only important role at their company. Software goes straight from the developer's brain, through his fingertips into the computer, and then on to the online store (run by nobody) for customers to buy. Engineering managers, program managers, product managers, marketers, MBAs, tech writers, QA, lawyers, process people, various admins and liaisons... they all exist to play pointless political games, have distracting meetings, and obstruct the One True Role. Design docs, planning, schedules, e-mails, JIRA, reviews, syncs, exec updates... all are useless parts of a scheme to torture the developer. It should just be "developers developing, and then money comes in from somewhere." This is an exaggeration, but you see these themes all over the comment section.
> I think a lot of HN truly believes that Software Developer is the only important role at their company.
I doubt that. A lot of HN might have believed that some 10 years ago, perhaps, but most of those people have either matured or been driven away by the shift in the discourse.
I was one of the people who used to believe that, but the years of experience have taught me several important lessons that changed my mind. That change in attitude came both from my own failures and from having the rare privilege to work with people who were actually good at those other roles you listed.
> This is an exaggeration, but you see these themes all over the comment section.
And you'll keep seeing those comments, just like you'll keep seeing the comments about how developers are hypocritical divas. Those comments come from people's bad experiences.
Workplace political games are a thing. Unnecessary meetings and documents are a thing. Problematic, unprofessional developers are a thing.
100%, majority of the posts here are based in fantasy of how the world should work. They're also highlighting why most Devs cant deal with customers effectively. Customers aren't showing up with a clear spec and handing it off while middle managers butt in and ruin the whole thing.
Though I agree, most managers are BSing way too much, but the reality is that most Devs cannot navigate conversations like they think they can, and like you said, nor do they want to. And that is exactly what the managers do.
I don't know how rare it is. I have always found it harder to write software when I don't know the people who will use it or get to see what they feel about it. It's part of the feedback loop.
When I get good feedback it's like winning a prize and when it's bad it lets me see where we should be spending our time rather than were we perhaps thought we should.
The solution is to work at small companies/startups.
That comes with real tradeoffs, but I've never regretted that path.