5 ms·

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

by 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.
    - eropple 4y ago
      Yeah, totally. And in my experience (on both sides of things), a good junior developer is going to probably realize what sucks well before having a strong understanding of how to make it not suck. The first attempts are probably not going to be perfect (maybe not even good) - but that's the sort of thing folks don't really learn by being told. You have to walk into that screen door a couple times. Which is why hiring junior folks is such an investment.
  - jacobyoder 4y ago
    > 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. There's got to be a limit to this line of justification though. Lots of people have just plain wrong ideas about 'web development', so catering to their ideas doesn't serve anyone well (except, perhaps, those people, who in the short term don't have to learn anything correctly). A colleague shares stories of his team who don't grasp the difference between GET and POST, don't understand the term idempotency, believe that 'web dev' testing only means 1 thing, etc. There's... 5 of 6 of them, and only one of him, so... much stuff ends up staying 'wrong', and the 'wrongness' in each section of the code ends up compounding 'wrongness' in other systems/features as they're being added. This matches how this team thinks about web/software development. But it's not in any way beneficial.
    - eropple 4y ago
      Oh totally! I firmly agree that at some point you have to pull the ripcord. The question becomes--where? This company was incredibly successful up until COVID and is still ticking along, so it's hard to argue. I gather they've done significant work to rebuild the universe in that time, though. I might've just been early.
  - mwcampbell 4y ago
    Where do you think your understanding went wrong initially? You said you realized that doing anything in the old system was slow. Was it not actually slow? Was the slowness not relevant because there weren't actually that many routes? Were your coworkers resigned to having some minimum level of tedium in web development? Or something else?
    - eropple 4y ago
      Oh no, it was slow--but it was slow and they were used to it. (And there were plenty of routes--probably somewhere close to a thousand at the time, in 2011?) The problem I hadn't fully understood was a mix of the last point you suggested--tedium's just how it is--and a set of libraries built up as coping mechanisms that were intrinsically tied to the servlets process. Not really written to be able to be shimmed into a better world without dragging the whole thing there, and not enough appetite to try for it.
- solardev 4y ago
  Ideally with guidance/mentorship though. There's a lot of stuff I learned the hard way that I wish I didn't have to!
- deleted 4y ago
  [deleted]
- deathanatos 4y ago
  When I was a non-senior eng., I interacted with plenty of senior engineers, found that I easily possessed the skills to work at their level / do their job. My company at the time laid off my entire division. I decided it was time, needed a job of course, and so applied for and landed a job as a "senior SWE".
xur17 4y ago
I've worked at companies that tried to have explicit 20% policies, and it worked okay for some period of time, but then became difficult to prioritize. That said, I've typically been pretty successful at casually using 10 - 20% of my time to work on random low hanging fruit (dev ergonomics, performance, etc). For some reason using a quiet Friday afternoon, or time between tickets seemed to work better than an explicit "work on whatever you want every Friday".
- popotamonga 4y ago
  At my old place they just overestimated my tasks complexity by 200-300%. I wasnt going to be the one saying no... So i had plenty of time to fix whatever.
  - Frost1x 4y ago
    I've always been a fan of the under promise and over deliver paradigm in tech. Overestimating gives you nice fat error margins should something unplanned come up, you're not slaving evenings and weekends away trying to meet a rough estimate that someone turned into a deadline for scheduling. Once you finish meeting minimum requirements, should you have that margin padding, you can then refine what's been created. Fix issues or shortcuts you may have taken, improve or optimize some portion that'll give significant improvement in experience, add some additional functionality you think would be nice to have where permitted (while the context of everything is fresh in your mind). Ultimately what's delivered will more often than not meet minimum requirements so whomever requested the work will be satisfied. They may even be incredibly pleased and consider you a wizard for some of the improvements (they also may not want the improvements so be sure to keep those modular you can very easily slice them off if they're undesired). This keeps everyone happy really. When you start trying to optimize on the estimates so they reach actual time or a little under actual time to pressure developers to do OT, that's when you get into toxic environments. If you give a little error margin developers will likely reinvest it in your application where it sparks joy in them meaning you're about to get the highest quality work, the stuff the engineer wants to do.
  - rolisz 4y ago
onion2k 4y ago
I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. Where I work we have 1 'maintenance day' each sprint where the devs choose what to work on. That can be fixing annoying issues, improving the code, learning something, trying something out, etc. It works well when other things aren't taking priority (which is far too often tbh).

by wes-k 4y ago

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.
  - eropple 4y ago
    Yeah, totally. And in my experience (on both sides of things), a good junior developer is going to probably realize what sucks well before having a strong understanding of how to make it not suck. The first attempts are probably not going to be perfect (maybe not even good) - but that's the sort of thing folks don't really learn by being told. You have to walk into that screen door a couple times. Which is why hiring junior folks is such an investment.
- jacobyoder 4y ago
  > 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. There's got to be a limit to this line of justification though. Lots of people have just plain wrong ideas about 'web development', so catering to their ideas doesn't serve anyone well (except, perhaps, those people, who in the short term don't have to learn anything correctly). A colleague shares stories of his team who don't grasp the difference between GET and POST, don't understand the term idempotency, believe that 'web dev' testing only means 1 thing, etc. There's... 5 of 6 of them, and only one of him, so... much stuff ends up staying 'wrong', and the 'wrongness' in each section of the code ends up compounding 'wrongness' in other systems/features as they're being added. This matches how this team thinks about web/software development. But it's not in any way beneficial.
  - eropple 4y ago
    Oh totally! I firmly agree that at some point you have to pull the ripcord. The question becomes--where? This company was incredibly successful up until COVID and is still ticking along, so it's hard to argue. I gather they've done significant work to rebuild the universe in that time, though. I might've just been early.
- mwcampbell 4y ago
  Where do you think your understanding went wrong initially? You said you realized that doing anything in the old system was slow. Was it not actually slow? Was the slowness not relevant because there weren't actually that many routes? Were your coworkers resigned to having some minimum level of tedium in web development? Or something else?
  - eropple 4y ago
    Oh no, it was slow--but it was slow and they were used to it. (And there were plenty of routes--probably somewhere close to a thousand at the time, in 2011?) The problem I hadn't fully understood was a mix of the last point you suggested--tedium's just how it is--and a set of libraries built up as coping mechanisms that were intrinsically tied to the servlets process. Not really written to be able to be shimmed into a better world without dragging the whole thing there, and not enough appetite to try for it.
solardev 4y ago
Ideally with guidance/mentorship though. There's a lot of stuff I learned the hard way that I wish I didn't have to!
deleted 4y ago
[deleted]
deathanatos 4y ago
When I was a non-senior eng., I interacted with plenty of senior engineers, found that I easily possessed the skills to work at their level / do their job. My company at the time laid off my entire division. I decided it was time, needed a job of course, and so applied for and landed a job as a "senior SWE".

xur17 4y ago

I've worked at companies that tried to have explicit 20% policies, and it worked okay for some period of time, but then became difficult to prioritize. That said, I've typically been pretty successful at casually using 10 - 20% of my time to work on random low hanging fruit (dev ergonomics, performance, etc). For some reason using a quiet Friday afternoon, or time between tickets seemed to work better than an explicit "work on whatever you want every Friday".

popotamonga 4y ago
At my old place they just overestimated my tasks complexity by 200-300%. I wasnt going to be the one saying no... So i had plenty of time to fix whatever.
- Frost1x 4y ago
  I've always been a fan of the under promise and over deliver paradigm in tech. Overestimating gives you nice fat error margins should something unplanned come up, you're not slaving evenings and weekends away trying to meet a rough estimate that someone turned into a deadline for scheduling. Once you finish meeting minimum requirements, should you have that margin padding, you can then refine what's been created. Fix issues or shortcuts you may have taken, improve or optimize some portion that'll give significant improvement in experience, add some additional functionality you think would be nice to have where permitted (while the context of everything is fresh in your mind). Ultimately what's delivered will more often than not meet minimum requirements so whomever requested the work will be satisfied. They may even be incredibly pleased and consider you a wizard for some of the improvements (they also may not want the improvements so be sure to keep those modular you can very easily slice them off if they're undesired). This keeps everyone happy really. When you start trying to optimize on the estimates so they reach actual time or a little under actual time to pressure developers to do OT, that's when you get into toxic environments. If you give a little error margin developers will likely reinvest it in your application where it sparks joy in them meaning you're about to get the highest quality work, the stuff the engineer wants to do.
- rolisz 4y ago

onion2k 4y ago

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. Where I work we have 1 'maintenance day' each sprint where the devs choose what to work on. That can be fixing annoying issues, improving the code, learning something, trying something out, etc. It works well when other things aren't taking priority (which is far too often tbh).