12 ms·

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most peo

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.

mattgreenrocks 4y ago
> If you remove people from the grind for 1-2 days a week The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels. So I respond by easing up on advancing my career, because it gives back to me the least.
- shagie 4y ago
  > The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. There's a book to hunt up... Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency It's written by Tom DeMarco of Peopleware fame.
- Frost1x 4y ago
  Pretty much. I often wonder where people find positions claimed on the internet where they're working 2-3 hours a day. I've increasingly throughout my career saw more and more slack evaporate to a point it's almost nonexistent. I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work. I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels. If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.
  - namaria 4y ago
    I think the low hour anecdotes come overwhelmingly from Europe, where 45K is considered a high salary
    - eertami 4y ago
      Europe is a big place, 45k might be a lot of money in Romania, and it is below minimum wage in Switzerland. Software Engineers will still be pulling 100k+ in Europe with those 2 hour days.
      - namaria 4y ago
        Got any sources? I'd love to work for a place where that is possible (I'm EU located, poorly paid and working my ass off)
  - ozim 4y ago
    I think you write about people who mention that they can get 2-3 hours of actual work, which in turn they count as "actually writing code in editor". I can easily imagine how it goes - because pushing tickets over takes time, bunch of meetings during the day takes time, explaining stuff to junior devs takes time, reviewing pull requests and answering to comments takes time, clarifying things with QA/BA/PO, figuring out which libraries to use by googling takes time. I saw devs that think these things that I have listed don't feel like "real work" but it is. There is also no way to automate meetings or discussions over PRs.
- namaria 4y ago
  >I have significant doubts that it is possible to continue to advance [as a worker under capitalism] (...), be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. It's heartbreaking how much human suffering is entirely avoidable in a post scarcity society where it is still artificially enforced to avoid the "moral hazard" of commoners daring not to toil or worry every waking hour
commandlinefan 4y ago
> has to be planned and approved It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this: 1. Management demands that every bit of work be associated with a ticket 2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system 3. management complains about devs opening "their own" tickets and prohibits self-opened tickets 4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board) 1. management demands that every bit of work be associated with a ticket...
- sobren 4y ago
  It feels bad too have a ton of structure, but the opposite is worse IMO. Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them." It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.
  - goodpoint 4y ago
    You just gave a bunch of examples of problems that are in no way fixed by ticket bureaucracy, only hidden.
    - namaria 4y ago
      A lot of this thread boils down to "bad engineering is bad" and "bad management is bad". Not a lot of insight to be found IMO...
- 4y ago
mysterydip 4y ago
> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.
heretogetout 4y ago
We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more. And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev. * the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.
- politician 4y ago
  I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.
kilroy123 4y ago
I could not agree more. My current gig is the opposite and after a year I'm ready to leave.
deleted 4y ago
[deleted]
_yasmeen 4y ago
That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!" This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.
Chris2048 4y ago
> Everything has to have some immediate business impact. Or more specifically, explainable business impact. But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.
dt3ft 4y ago
We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.
- dubswithus 4y ago
  What happens if you do it anyway and don't put it on the board?
  - bendbro 4y ago
    You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.
    - dubswithus 4y ago
      I'm not trying to get a higher salary or promotion. I make enough money. I can't say for certain since it has never happened but I would probably quit on the spot if PIP'd.
  - voxic11 4y ago
    In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.
    - nso 4y ago
      This made me laugh out loud because it was so unexpected but also makes perfect sense.
    - dfsegoat 4y ago
      Ouch. Out of curiosity, are those local or federal regulations?
adrianN 4y ago
Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.
- jimbokun 4y ago
  Shit that bugged them for a long time can multiply overall productivity going forward, and add far more value than slowly banging out the next user facing feature in a low productivity environment.
- bruce343434 4y ago
  So you'd rather have bugged out people which decreases morale which decreases productivity? See it as an investment. Yes, motor oil is more expensive than no motor oil, but it makes the engine run a lot better.
  - treis 4y ago
    I see this a lot at my current job. The tech stack is ridiculously complicated and I think a lot of it is due to this sort of motivation. They let developers run wild and build using whatever tools or new hotness that they wanted. But ultimately we sell Widgets. And the 3rd refactoring of an application to use some immutable data library doesn't do anything to help us sell more Widgets. So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".
  - grvdrm 4y ago
    You're both right, unfortunately - which makes it hard to ever consistently choose a path. Many people are stuck in the middle of the two sides in lots of orgs. Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable. To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received. Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.
wes-k 4y ago
I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase. One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.
- dgb23 4y ago
  How does a junior become a senior? By trying stuff that cannot do well yet and making mistakes.
  - eropple 4y ago
    This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best. Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.
    - xwolfi 4y ago
      That s the problen with juniors yes, you have to drive them towards productivity while not killing their enthusiasm.
      - 4y ago

mattgreenrocks 4y ago

> If you remove people from the grind for 1-2 days a week The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels. So I respond by easing up on advancing my career, because it gives back to me the least.

shagie 4y ago
> The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. There's a book to hunt up... Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency It's written by Tom DeMarco of Peopleware fame.
Frost1x 4y ago
Pretty much. I often wonder where people find positions claimed on the internet where they're working 2-3 hours a day. I've increasingly throughout my career saw more and more slack evaporate to a point it's almost nonexistent. I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work. I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels. If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.
- namaria 4y ago
  I think the low hour anecdotes come overwhelmingly from Europe, where 45K is considered a high salary
  - eertami 4y ago
    Europe is a big place, 45k might be a lot of money in Romania, and it is below minimum wage in Switzerland. Software Engineers will still be pulling 100k+ in Europe with those 2 hour days.
    - namaria 4y ago
      Got any sources? I'd love to work for a place where that is possible (I'm EU located, poorly paid and working my ass off)
- ozim 4y ago
  I think you write about people who mention that they can get 2-3 hours of actual work, which in turn they count as "actually writing code in editor". I can easily imagine how it goes - because pushing tickets over takes time, bunch of meetings during the day takes time, explaining stuff to junior devs takes time, reviewing pull requests and answering to comments takes time, clarifying things with QA/BA/PO, figuring out which libraries to use by googling takes time. I saw devs that think these things that I have listed don't feel like "real work" but it is. There is also no way to automate meetings or discussions over PRs.
namaria 4y ago
>I have significant doubts that it is possible to continue to advance [as a worker under capitalism] (...), be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. It's heartbreaking how much human suffering is entirely avoidable in a post scarcity society where it is still artificially enforced to avoid the "moral hazard" of commoners daring not to toil or worry every waking hour

commandlinefan 4y ago

> has to be planned and approved It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this: 1. Management demands that every bit of work be associated with a ticket 2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system 3. management complains about devs opening "their own" tickets and prohibits self-opened tickets 4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board) 1. management demands that every bit of work be associated with a ticket...

sobren 4y ago
It feels bad too have a ton of structure, but the opposite is worse IMO. Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them." It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.
- goodpoint 4y ago
  You just gave a bunch of examples of problems that are in no way fixed by ticket bureaucracy, only hidden.
  - namaria 4y ago
    A lot of this thread boils down to "bad engineering is bad" and "bad management is bad". Not a lot of insight to be found IMO...
4y ago

mysterydip 4y ago

> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.

heretogetout 4y ago

We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more. And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev. * the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.

politician 4y ago
I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.

kilroy123 4y ago

I could not agree more. My current gig is the opposite and after a year I'm ready to leave.

deleted 4y ago

[deleted]

_yasmeen 4y ago

That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!" This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.

Chris2048 4y ago

> Everything has to have some immediate business impact. Or more specifically, explainable business impact. But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.

dt3ft 4y ago

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

dubswithus 4y ago
What happens if you do it anyway and don't put it on the board?
- bendbro 4y ago
  You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.
  - dubswithus 4y ago
    I'm not trying to get a higher salary or promotion. I make enough money. I can't say for certain since it has never happened but I would probably quit on the spot if PIP'd.
- voxic11 4y ago
  In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.
  - nso 4y ago
    This made me laugh out loud because it was so unexpected but also makes perfect sense.
  - dfsegoat 4y ago
    Ouch. Out of curiosity, are those local or federal regulations?

adrianN 4y ago

Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.

jimbokun 4y ago
Shit that bugged them for a long time can multiply overall productivity going forward, and add far more value than slowly banging out the next user facing feature in a low productivity environment.
bruce343434 4y ago
So you'd rather have bugged out people which decreases morale which decreases productivity? See it as an investment. Yes, motor oil is more expensive than no motor oil, but it makes the engine run a lot better.
- treis 4y ago
  I see this a lot at my current job. The tech stack is ridiculously complicated and I think a lot of it is due to this sort of motivation. They let developers run wild and build using whatever tools or new hotness that they wanted. But ultimately we sell Widgets. And the 3rd refactoring of an application to use some immutable data library doesn't do anything to help us sell more Widgets. So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".
- grvdrm 4y ago
  You're both right, unfortunately - which makes it hard to ever consistently choose a path. Many people are stuck in the middle of the two sides in lots of orgs. Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable. To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received. Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.

wes-k 4y ago

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase. One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.

dgb23 4y ago
How does a junior become a senior? By trying stuff that cannot do well yet and making mistakes.
- eropple 4y ago
  This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best. Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.
  - xwolfi 4y ago
    That s the problen with juniors yes, you have to drive them towards productivity while not killing their enthusiasm.
    - 4y ago