Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- It's not software; it's the fact that most managers/administrators are not software developers (although they may have some programming ability). so they stand in teh same relationto their development team as cusomers complaining to a manufacturer about the features on a physical product, and saying 'it should do this or that, it's an easy change to make' (because it's easy to imagine having it if you skip over the tedium of having to implement it).
Of course sometimes the ask is justified and addresses some failing of the original spec, either through lack of ambition or excess ambition that harnessed a cargo container to a lawnmower engine. But most of the conflict the article describe stems from a combination of imagining the benefits of change with the unspoken assumption that implementation is just a matter of pushing a few more buttons.
by anigbrowl - > Leaving things alone is an underrated engineering skill.
Truer words have never been spoken.
by iamcalledrob - When I read the title, my mind immediately jumped to something else: negativity.
I've noticed that my own mind always searches for corner cases, error conditions and failure modes. This can be super helpful when planning new features (or explaining to stakeholders that certain conditions must be met first, when they want some new features), but when it extends to other things besides software, it can be psychologically unhealthy.
by perlgeek - Reminds me of this 2014 post "Programming Sucks" [0], which touches on some similar issues of getting disconnected from reality in a microcosm that always "ought" to be better than it is.
> All programming teams are constructed by and of crazy people [...]
> The destructive impact on the brain is demonstrated by the programming languages people write. [...]
> All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad.
by Terr_ - OP has practically observed the effect of the Ego via software, but hasn't quite arrived at the ability to quantify it.
Read back through and apply every example given through that lens.
It is possible that we're in an industry that inordinately expresses this part of human nature, but I'm pretty sure it shows up everywhere though different anecdota. Apply a reductionist Zen Buddhist view to your professional creativity and all of this goes away.
Bob wants to refactor a subsystem because it will make him a hero, and if he positions it correctly to management, the technical merit and actual realized level of success will be irrelevant. Alice chooses to surface some obvious concerns and then sit back and watch the show. Jane chooses to throw her hands up in stand-up and try to emotionally convince everyone the sky will fall. Be like Alice and preserve your sanity.
by tcdent - My observation is simply that tech leaders misinterpret rewards from the market in conquering some abstract representation of a facet of a domain with conquering the domain itself. Then they become egomaniacal.
Did you conquer commercial real-estate ushering in the future of work and society, or did you build a handy scheduling app?
Did you have a neat idea for an online community or did you revolutionize human connection?
by randusername - I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here.
I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities.
I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.
by hliyan - Software development untethered from the practical realities of the customer / user is what drives people insane.
When developers are required to interact with the customer on a regular basis, the freewheeling effects described in this article are damped massively.
The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client occur via some prison guard known as "project manager" sliding notes under the door.
Working with the customer sometimes sucks. Just like exercise and eating vegetables sometimes suck. It's a temporary unhappiness that keeps us grounded in reality.
by bob1029