The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.
I’m not sure it’s naive to view the world like the author does. I’ve worked both sides of the fence, and while I’m now back in software development I do see the appreciation for my experience with creating the most business value out of your resources that managers come with. The thing is, though, if I don’t have to work in a place with too much bureaucracy or too many constraints then I’m not going to do so. I obviously try not to be an asshole about it. I don’t follow the company dress code in the basement troll factory where they placed IT, but I do have a suit at work that I can change into whenever I leave the “cave”. Those sort of things, so naturally I’ll play a long way in regards to what management want, but I’m never going to do estimates by the hour until the job market actively forces me to do so. Which likely won’t be in our lifetime. So when/if management go down the route of treating Software Development like they treat any other department (which like you state also are under significant constraint) then the company is just very likely to lose their most talented developers very quickly. I suspect that it would be (and probably is) exactly like that in any department, it’s just easier to get away with in engineering because we’re privileged enough to be able to leave our jobs today and have another good job by tomorrow.
Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop.
Also if engineers think we don't check references and backgrounds anymore – including reputation – those days are long past. It's too much of a liability to have the 'talented asshole' as part of a team anymore.
> Especially if you introduce boundaries and restraints.
Boundaries and restraints are a professional reality.
> So when/if management go down the route of treating Software Development like they treat any other department.
It's this exceptionalism that earns engineers the reputation of being jerks, and creates a negative feedback loop. Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.
Also assuming that someone who isn't going to tolerate fuck-fuck games with assholes when they don't have to is themselves an asshole. It's entirely possible to amicably end a relationship with someone (a business) you can't stand, with them none the wiser that it was ever about something other than compensation.
> Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.
This is pure hopium. Bureaucracy is installed in anticipation of growth/security/safety gains, and existing success of the team can be completely ignored by someone who thinks the good of bureaucracy will outweigh the harm.
Confidently incorrect! It's the iron law of the market; I don't make the rules.
Fwiw, bureaucracy used to not be such a pejorative term; it implies coordination at scale, with internal checks and balances. Engineering doesn't happen without talent, talent needs money, money comes from good sales and marketing, etc.
To be efficient, these things have to be centrally coordinated by an entity that typically has an eye on the market, which behaves beyond anyone's control.
How do you check reputation?
One of the reasons I have a lot of job offers isn’t that I’m the best technical engineer you’re going to meet, it’s that I have a large network and is generally seen as a nice person to work with. Obviously my ability also plays into this, but you can be both good at your job and a decent person at the same time. In my experience most people are.
> Play the cooperation game.
Like I said in my original post, I do this, and in my personal opinion experience so so most people. The thing is though, I have a lot of experience (and education) with/in the “MBA” side of things, and a lot of the things you see some companies do, that this article also touches on, like putting up a needless bureaucracy around estimates and time tracking, don’t actually work as intended. Time tracking tends to lead to cultures where the speed of delivery becomes more important than the quality, and estimating things by the hour is frankly just impossible in a field where you can spend an hour on something incredibly stupid and then 10 minutes on some brilliant solution to an issue marked as complex. I mean, maybe my anecdotal experience is from a mediocre perspective, but even after decades of programming I still do the equivalent of talking to a rubber duck, or at least asking my very good friend and coworker to come and spend 5 seconds spotting where I’ve made the obvious mistake (and the other way around), which we have time to do because we’re not on the clock to deliver as fast as possible by the way.
In a world of a lot of shitty business practices, people who can, will take their cooperation game to the place it makes the most sense for them. Including when they are also very personable people.
(and let's face it, there are many many business owners who care way less about business problems being solved than they care about "being the boss")
A business owner decides what the purpose of the business is, and what constitutes useful "work" within that context. If I'm hired to do x,y and z and I decide my motivation is rather to surf the web all day or spend all my time on personal projects, that doesn't change the purpose of work, it just means I'm not working.
I'm a technical lead which does have a little bit of people management responsibilities. Turnover on my team is probably well below average, we had two developers leave for other jobs in the last year out of 15 developers and one fired for poor performance. I can't remember anyone leaving the year before.
To be clear, I don't think this article is wrong per se, just obnoxiously naive and doesn't have any empathy for the real world constraints that people have to work with. It's just... uhhh... rubs me the wrong way.