4 ms·
This article really bothered me. "An important decision had been made on behalf of the team." Their solution to that was to make everything in the company revo
by sqldba 9y ago
This article really bothered me. "An important decision had been made on behalf of the team."
Their solution to that was to make everything in the company revolve around the manager. After feeling personally hurt that they weren't included on every decision ever, now there's paperwork which can HOLD PEOPLE ACCOUNTABLE if they break "the documented rules".
Those darn workers better check those rules every time they're about to do something just in case, and if it's a new thing, ho boy, they better think twice because now they have to be prepared to wade through all that argumentation and red tape first.
This is awful and borderline mentally ill. It instills a fear culture into employees and ignores that developers want to write code. Instead it's trying to force them into the manager box of talking big and shouting each other down until an idea wins. Sick.
You know what the solution was? "Yeah, well they built it and it's pretty cool. If you want to do it in something else then make a better one." End of problem.
If this person was my manager I would be looking for a new job.
- CaveTech 9y agoAn RFC does not have to be hostile, or a debate. In it's simplest form you're explaining the changes you're about to make and gathering input. There is absolutely no fear here. It sounds like you're projecting a previous toxic environment onto this subject. A team where everyone is doing things "their way", and then rebuilding it if it wasn't up to par is an enormous waste of resources.
- deleted 9y ago[deleted]
- sidlls 9y agoI think there is a middle ground between cowboy developers just doing whatever they want and a tyrannical, cumbersome and hostile design process.
- ndh2 9y ago> If you want to do it in something else then make a better one. And what is the end result of that? The old code gets deleted, and the person that implemented it might get angry because it sucks to spend time on something only to have it deleted. How is that better?
- allengeorge 9y agoThis is over-the-top negative. An RFC is not intended to be "paperwork", about the manager, or about "shouting each other down until an idea wins" - it's way more about the engineer, and helping us create a good design that has broad buy-in. Specifically, writing RFCs asks an engineer to articulate a design, consider and list the tradeoffs involved, and evaluate it against a set of motivating use cases. It also invites feedback: other people may have legitimate concerns or find blind spots. As the writer you don't have to make changes to incorporate everyone's views: it's up to you to decide on a case-by-case basis if their feedback needs to be incorporated or not.
- johngalt 9y agoRFCs point both ways. Documenting decisions is a positive management trait. Otherwise you can easily end up with a mess that no one takes responsibility for. Management decisions and associated rules will happen regardless of documentation. It is better to have a paper trail.