Hacker News Reader

Comment by unoti | Hacker News Reader

This reminds me of a type of professional that I see far too often. The professional who specializes in not doing their job. It happens with programmers, as well as many other specialties. You've probably seen them:

- Software developers who as soon as you tell them what you need, they tell you why it's impossible.

- Network administrators who apparently specialize in making machines not talk to each other, because things worked better before their first day

- DBA's whose first priority is keeping you from accessing the data

- Engineers who think it's their job to make things more difficult

Saying NO to all the things is better than getting nothing done, sure. But having the skill to say yes to the things that are needed is better.

View on HN

It's all about what you say no to. For example, if it is something that will cause a lot of technical debt, as a developer, I push back until I get a concession where I have the opportunity to undo the damage afterwards. Otherwise the debt will increase stress, lower developer happiness, and potentially prevent the business from growing in the long term as developer retention becomes more difficult the longer it lasts.

If you're going to ask for something unreasonable from someone with domain expertise, expect to make a concession if you want it done since that person has a high likelihood of understanding the true costs of the request. It is all too common to see developers experience burnout from 60+ hour weeks in order to attempt to meet a deadline because managers were awful at planning.

I often take a more neutral stance through explaining that it would take [X] amount of time to build solid & tested pieces of functionality as designed, and then let the product managers assess the information to come to a decision to either scale back or if it is still pushed for, then push back for a concession. It doesn't have to be a Yes or No proposition, it is like bartering - you want to get to a mutual agreement so all parties are satisfied.

It is all too common to see developers experience burnout from 60+ hour weeks in order to attempt to meet a deadline because managers were awful at planning.

Another pattern I've seen is the dreaded "artificial deadline" from on high. A project is structured to meet a tight deadline, resources are reallocated, nights and weekends are worked, stress ripples through the team. At great emotional expense the deadline is met, and the team submits the project, victorious.

And then nothing is heard for several days. No feedback from the heavens. Inquiries are made, and it's discovered that, well, no, in fact there was no particular reason this project had to be finished by that particular date. Managers have moved on, checkboxes have been checked. Because the project was nominally successful, the episode is used to further confirm the management theory that "the dev team needs deadlines, even arbitrary ones, or things don't get done." The project size and time frame is now baked into management's institutional memory as the new baseline.

I agree, this is extremely common, and it completely baffles me....you are in charge of a resource, would it not be in your best interest if more people use that resource rather than less? For whatever reason, I find DBA's to commonly have this type of attitude, as well as having extremely unimaginative minds (Why would you want to do that?)

On the other hand is the manager with no grasp of the technical challenges who asks the expert with the intention of getting a rubber stamp and acts all shocked and offended at the slightest push-back.

Not that I've been the developer in that scenario...

Reply on news.ycombinator.com