4 ms·

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 dumpste

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.

scarface_74 2y ago
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://www.levels.fyi/blog/swe-level-framework.html https://dropbox.tech/culture/sharing-our-engineering-career-framework-with-the-world 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.
- fanfanfly 2y ago
  Thanks for sharing
Trasmatta 2y ago
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.
- Ancalagon 2y ago
  This is what bothered me so much about my last job. Thank you for saying it so succintly
  - Trasmatta 2y ago
    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.
    - scarface_74 2y ago
      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.
      - Trasmatta 2y ago
        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.
        scarface_74 2y ago
        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.
    - strken 2y ago
      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.
      - 2y ago
- bckr 2y ago
  A good phrase to remember is “outcomes over outputs”
- intelVISA 2y ago
  "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.
- asdasdsddd 2y ago
  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.
hinkley 2y ago
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.

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.

scarface_74 2y ago

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://www.levels.fyi/blog/swe-level-framework.html https://dropbox.tech/culture/sharing-our-engineering-career-framework-with-the-world 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.

fanfanfly 2y ago
Thanks for sharing

Trasmatta 2y ago

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.

Ancalagon 2y ago
This is what bothered me so much about my last job. Thank you for saying it so succintly
- Trasmatta 2y ago
  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.
  - scarface_74 2y ago
    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.
    - Trasmatta 2y ago
      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.
      - scarface_74 2y ago
        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.
  - strken 2y ago
    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.
    - 2y ago
bckr 2y ago
A good phrase to remember is “outcomes over outputs”
intelVISA 2y ago
"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.
asdasdsddd 2y ago
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.

hinkley 2y ago

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.