Hacker News new | past | comments | ask | show | jobs | submit login

> If your company doesn't believe that burnout is an issue and ignores your "no's"

It's up to you to ensure that your "no's" can't be ignored. Really what shy programmers need is confidence and healthy boundaries.




While true, this doesn't have to actually mean being more assertive at your job. I worked at a place where I constantly had to be very up front about my boundaries and work limits. We would plan something, say some certain things can't be done for 2 weeks, and then two days later someone would come back and be like "So... about those tickets, could we actually squeeze them in this week? As well as all the other tickets?"

I did get better at saying no and establishing my boundaries. But that itself is still exhausting. The best move I made was recognizing the culture there had shit respect for developer boundaries and switching to a company that does.

There are places and people that will take advantage of the fact that many developers do not want to say no. Do get better at saying no. But also get away from those people.


Unfortunately for every one tech employee willing to set boundaries and say no, there are 10 in line outside the door, resume in hand, willing to say yes and burn themselves out. You can quit in protest but where are you going to go? You’re competing with dozens of talented people straight out of college willing to work 100 hour days for Mountain Dew and a dual screen workstation.

Unless you believe the “Shortage Of Engineers” meme, intense labor competition is a huge contributor to industry wide burnout.


I don't believe for a second that there is an endless supply of capable software engineers. The salaries available to folks of even modest experience simply don't support such an assertion.

This problem should be self-correcting. If it's as unproductive as it is unhealthy, then better companies will win by retaining talent for longer.


Even if you are correct, the problem often becomes an inability to identify such talented developers, and many companies don’t even bother.

Also, the best developers rarely come on the market, they go straight from job to job thru good relationships with previous managers and co-workers. Managers who abuse workers are not usually able to retain the best talent, they end up adversely selecting for the least productive talent.


I find this to be the perception of:

1. New engineers, and it's certainly valid. The net pros and cons of your abilities are equivalent to those coming straight out of college. You must set yourself apart from the competition by putting more time into your work or increasing the quality of your talent.

2. Experienced engineers who work for companies that devalue personal growth, and that is valid too. Our most challenging daily work will usually come from employers -- If that work isn't mentally stimulating, you're not learning anything, and nothing is being meaningfully done to separate you from those college level entries.

3. Experienced engineers who work in fields with a lower barrier to entry, and it seems valid to me. If your company's projects are more resilient to the mistakes novices will make, or there are less mistakes to make because it's easier to understand, it's difficult to increase the quality of your talent in a competitive way.

4. Experienced engineers who knowingly have poor talent quality, and it's valid. It's challenging for some people to critically think, to navigate the abstract nature of engineering, and to learn those deeper concepts that typically separate experts from novices -- And that is surely difficult to overcome.

5. Experienced engineers who believe they have poor talent quality but are indeed quite talented in meaningful ways, and it's invalid. It's imposter syndrome and it's absolutely rampant in our industry.

6. Experienced engineers with good talent quality but poor interpersonal skills, and its validity depends on your interpersonal growth. If you're not great at negotiating or you intensely value validation, you're certainly at risk to being taken advantage of, and not necessarily with malice on the company's part.

There is definitely a shortage of engineers with high talent quality in fields that require it. Many people believe weekly hours are the only competitive aspect of our industry and it simply isn't true in many cases.

While we will almost indefinitely feel pressure to stay busy, talented engineers have far more leverage to push back than they realize. Great engineers are hard to come by and many companies will work hard not to lose them.


Depending on your position this to me reads like paranoid behavior one would expect from someone without many social skills who gets manipulated into fearing for his job when he has realistically one of the most portable and in demand skill sets in the modern markets.


And if you're not a shy programmer who has shown schedules, estimates, timelines, and are also trying to prevent those you manage/mentor from being burntout? Or what if your direct manager actually agrees with you! But your combined arguments are being shot down for reasons of growth, culture, or they decide to change the metrics so when you do say no, your performance plummets and they now have more power in conversations? Yes, signs of a toxic culture. No, you cannot always just leave.

It's unsurprising to see comments that revert to pinning the blame back on the employee. That's how the narrative has been formed and controlled. It's also a product of the "self-made person" idea where you ultimately have all the control over where you end up in life.

As a side note - not everyone is speaking from the position of being a programmer. Burnout is affecting many other careers. This forum just happens to be tech centric, but I do hope that stereotypes and assumptions can be minimized.


Quoting my father-in-law (who is a senior civil estimator with experience on countless multi-million-dollar projects):

"Do you want someone who will tell you want you want to hear? Or do you want someone who will tell you how much it's gonna cost?"




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: