Hacker News Reader

Comment by asdasdsddd | Hacker News Reader

Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.

View on HN

And this is one reason this industry can be so soul crushing.

You're asked to demonstrate "ownership", but at any moment some person above you can take all your work away and make you do something entirely different.

Somehow we're asked to care about our work and not care about it at the same time.

This is what bothered me so much about my last job. Thank you for saying it so succintly

I think it's one of the prime causes of burnout. Feeling like you have no real control over things, but having immense responsibility anyway. Fighting learned helplessness with an internal taskmaster.

It's not good for the psyche.

The prime cause of burnout is not saying “no” to being pushed to work extra hours.

You do that by being able to communicate about the trade offs between the holy trinity of projects - on time, on budget and meets requirements.

I disagree with this. You can burn out when working less than 40 hours. You can not burn out when working way more than 40. It has a lot more to do with other factors, it's just that those factors will burn you out even quicker if you're working too many hours.

I'm incredibly burnt out currently, and I'm consistently at under 40 hours at my job.

In that case you probably see your job as more than just a paycheck. I go to work for one reason - to exchange my labor for money. The company gets all of my skills and experience during work hours. But when off of work. I’m off of work

If either of us at anytime decides that the labor for money transaction is no longer needed. I get another job.

I've started to think the solution to burnout is to just up and quit your job wherever anyone tries to force you to do anything without a good explanation.

This is obviously not something everyone can do, but if you can, maybe it's worth it.

Well, make them fire you, so that you get severance. And keep a papertrail documenting how you were told over and over to do things that made no sense to the company’s bottom line.

A good phrase to remember is “outcomes over outputs”

"Drive this car with 3 wheels and if you crash it's all on you, if we get to the destination I'll be rich and DON'T even think about stopping to add a 4th wheel. DRIVE FASTER. STOP THINKING ABOUT THE WHEEL."

Really devs should exchange labor like authors with royalties, there's no incentive to ship good software for salary so you just end up with a series of "crushed tickets" aka future work for yourself as job security.

That's the nature of the job, we're not growing food to feed people. We tinker with with code in the hope that it helps someone else and sometimes it doesn't.

One of the soft skill tricks is building new allies out of subordinates. Almost nobody gets promoted to a level of influence until they’re a bus number in something important. And that often requires waiting for the project scope to grow enough horizontally for new domains to open up, or for someone senior to pass the torch.

If management is doing their jobs in growing the team then this all works out. But if they’re letting those with tenure get first pick of new problems, then you can play the game, carving out your share of the spoils, and then offloading other things before your head explodes. Every thing you offload is a ladder rung for someone else.

That way you end up with code that is no longer your baby but still not on the trash heap.

That’s not the takeaway. The author said work on “projects” not “tickets”. In other words, volunteer to be the single responsible individual for “work streams” or “Epics”. This is actually the behavior of a mid level developer at every tech company whose leveling guidelines I have seen either internally, talked to other people about or that’s publicly available - ie Drobox

https://www.levels.fyi/blog/swe-level-framework.html

https://dropbox.tech/culture/sharing-our-engineering-career-...

A senior developer should be over guiding an implementation and mentoring and coordinating mid level and junior developers.

I made it a point ny entire career not to be a “ticket taker” and be able to say I “lead” or “designed” a major feature or implementation.

Thanks for sharing

Reply on news.ycombinator.com