Conversely I would prefer to work in a place like that. Professionalism at scale isn’t achievable by tolerating idiotic behaviour and being nice to everyone no matter how dangerously stupid they are being.
There is a point where someone has to put their foot down and demand things be done properly, otherwise the inevitable consequence is a giant mess leading to disaster.
You might be used to small startup teams with responsible, experienced developers.
Out there in larger industry you get people doing absolutely crazy things that break huge, expensive systems.
There’s a difference between “oops I didn’t realise this library doesn’t scale the way I assumed it did” and “rewriting language symbols because I’m too stupid to use more than one syntax forever and ever.”
The standard you walk past is the standard you accept.
Are you saying you would walk past C code with DO…OD instead of {…}?
Would you accept that standard just to be “nice” all the time?
There was a time when I would have agreed with that.
What I've learned since then is that, with a healthy company culture, you can give frank feedback -- even about stupid mistakes -- without it being a rebuke.
It's also important that you target the right problem. It's only human for smart people do stupid things sometimes. In the specific DO...OD example, I'd be more interested in how it got through a code review than the mistake itself. (Funny enough, early versions of the C source for Bash itself had macros like that.)
Now, if someone exhibits a pattern of ignoring good, constructive feedback, that's a problem. The folks I've seen like that both gave terrible feedback and took feedback terribly. That's a behavioral problem, and you only get so many chances to correct that before it's time for them to find other employment.
> There is a point where someone has to put their foot down and demand things be done properly, otherwise the inevitable consequence is a giant mess leading to disaster.
This is what management is for, too bad tech companies are too cool for that and prefer to live out lord of the flies.
I would just like to know exactly how are the engineers going to make the decisions, and the key point here being that they are in plural.
They all have different opinions, preferences, levels of ambition etc, how does this spontaneously merge into a cohesive team that pulls into the same direction?
It doesn't, in any other type of group in all of society. Every group needs a leader, so how is this spontaneously going to "just work" in software engineering?
If you don't want to have a manager, you have to have something else. Democracy? Plutocracy? Gerontocracy?
I think it's pretty obvious that just leaving it to chance is not going to be efficient or any type of healthy environment, and will probably quickly start to resemble something pretty nasty, especially because their livelihood is on the line.
There is a point where someone has to put their foot down and demand things be done properly, otherwise the inevitable consequence is a giant mess leading to disaster.
You might be used to small startup teams with responsible, experienced developers.
Out there in larger industry you get people doing absolutely crazy things that break huge, expensive systems.
There’s a difference between “oops I didn’t realise this library doesn’t scale the way I assumed it did” and “rewriting language symbols because I’m too stupid to use more than one syntax forever and ever.”
The standard you walk past is the standard you accept.
Are you saying you would walk past C code with DO…OD instead of {…}?
Would you accept that standard just to be “nice” all the time?