Yeah and by people like the person who wrote the article, which I find ironic, that the article complains about being "forced" to work efficiently robbing the work of it's social and human aspects, yet people in the comments here, and elsewhere, are complaining about literally the opposite thing: being forced to work inefficiently and suffer from these forced "human" aspects of socialisation with people they can't choose freely.
Gives me the feeling that the author really tries to misuse the workplace for lifestyle, meaning, socialising etc which they really are responsible for themselves in their free time.
People just want to get their work done and proceed with their own lives outside of work, I think maybe this individualism is actually what the article is complaining about.
> Gives me the feeling that the author really tries to misuse the workplace for lifestyle, meaning, socialising etc which they really are responsible for themselves in their free time.
This gives me the feeling that you really believe that pretending to not be human during work hours makes one more productive. As far as I know it doesn't work like that even for assembly line jobs.
Stop serving cake and having useless meetings, Karen, get a life and leave people alone.
I've worked on the assembly line, it was like being in the army, they screamed at us like drill sergeants to make us work faster. I'll leave it up to you to decide how humanising that environment is.
Where do you think all the nice things come from, getting shit done and not from grooming each other all day.
Don’t think so. These things are par for the course if your dev team is several hundred people and -above all- focused on keeping things running exactly as they were before. Communication and waiting becomes 90% of your job.
I agree. However, I would sincerely love to be wrong about this, and would sincerely love to hear counterexamples from folks who work on large engineering teams that have somehow not devolved into lots of non-productive stuff.
The engineer side of my brain says that yes, of course it's possible. You could run a very tight engineering ship with just the right level of autonomy between a number of exactly-right-sized teams. You would employ some percentage of your engineers to ensure that the other engineers were maximally productive. Etc. This stuff is all extremely possible in a vacuum.
The pragmatic side of my brain says that, while technically possible, any organization that has grown to include a medium-to-large engineering team has almost surely done so in ways that preclude the sort of "ideal" engineering environment mentioned above.
The typical failure mode here is, of course, a company that manages to defy the odds and experiences success, but takes on a large amount of technical debt during their early days of manic growth and then spends the next N years dealing with it.
Ask someone who has worked on a long-running project before CI and code reviews became common. If the choice is between slow and randomly failing CI and no CI or code review at all and mistakes getting noticed when the software is finally tested weeks or months later, I would always choose the CI. It would be nice if everyone in the team was omniscient genius who never makes mistakes, but sadly I am not one and I haven't met anyone who is yet.
Meetings, CI, etc. are all good things in moderation, but people could be more productive by applying more judgment to the question of when to do them.
If you're like a typical colleague of mine, you aren't needed at 80% of the meetings you attend, and you don't get any value out of those meetings either. Your attendance at these meetings is essentially a mindless way to run out the clock on the day.
