5 ms·

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and

by teeray 3y ago

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

jasmer 3y ago
[dead]
dhbanes 3y ago
I always immediately approve implementation of any good idea regardless of roadmap or resource availability.
- AceJohnny2 3y ago
  Ah, the luxury of no deadlines...
  - marcosdumay 3y ago
    Looks like good long-term project stewardship. If somebody just improved all future deadlines at the expense of a delay in one, isn't it great? (Yeah, there are a few times when it isn't; but if those are not few enough to be clearly communicated, your management is a bunch of dummies.)
Swizec 3y ago
My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well
- bombela 3y ago
  Or they were actually asking for time to officially work on it. Thinking their superior must have a good view of the big picture. Waiting confirmation that their idea made sense in the grand scheme of things.
  - Swizec 3y ago
    In that case giving them permission does the trick and the improvements happen. Huzzah! The other side is making sure to always plan for enough slack in the system so people have time for these things, if they choose to use it.
- ianmcgowan 3y ago
  AKA "The Wally Reflector" from Dilbert :_)
  - Swizec 3y ago
    Looked that up thinking I'll disagree, but actually yes. As you grow in your role, you get to a point where the number of incoming "quick requests" outpaces your ability to keep up. To most people they're just asking for a quick 10 minutes of your time, what's the big deal. But they don't see the other 20 people doing the same thing. If you devote 200min+ of every day to fulfilling others' requests, when will you have time to do your own work? The problem grows only worse the higher in the org chart (formal or informal) you get. Someone like a VPofEng may have 100 people asking "quick questions" all the time. Without the Wally Deflector, there's literally not enough time in the day to even have all these conversations, let alone do anything about 'em.
pydry 3y ago
The non dysfunctional way to deal with this is to allocate between 20% of dev time to process improvements and vote on large scale changes.
- CoastalCoder 3y ago
  Ensure you use the dysfunctional version of that, where some individuals are always outvoted. Over time, they'll become some of your favorite object lessons about employee engagement!
- seattle_spring 3y ago
  Every place I’ve worked has had a “20% tech debt” time. Universally, it’s used as a reason to not fix technical debt as opposed to enabling engineers to fix long-standing problems. “Oh you need to re-write such and such? Well that’ll take 40% of your time for 3 weeks and the max time we can allocate is 20% so…”
dxdenton 3y ago
If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the better, as this guy is no longer my manager. For the record, my super-great-idea was upgrading some 5+ year old software that was giving us and the devs a lot of headaches. I was told it could not be done, and it would be replaced by The Next Great Thing, which would take 6-8 months of engineering. I upgraded the thing in a day (in dev) just to prove that it could be done. Despite praises from my teammates (and devs) I had undermined The Manager. Although I know he wanted to, he could not berate or yell or force me to rollback —- imagine telling dev we are rolling back to a five year old version. In any case, ten years in and I’ve learned that the manager is a hard cap on the productivity of a team. The most productive team I’ve been on did not have a manager. We didn’t need a JIRA board or a roadmap or someone to help us plan or prioritize. We simply got our work done. Imagine that.
- jcon321 3y ago
  In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.
  - peteradio 3y ago
    It was in dev environment which I doubt in his world required any sort of management approval.
  - dxdenton 3y ago
    I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.” > There’s always a way to get housekeeping items approved… Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).
nineplay 3y ago
I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.
- opportune 3y ago
  Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more. I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
LargeTomato 3y ago
YES. Fake praise and empty, kind words will get you far. Unfortunately I learned this far too late. To me it feels gross and manipulative but that's what people want.
j45 3y ago
There should absolutely be separate meetings for new idea separate status updates, and ideally status update meetings should only be for chatting about what digital updates can’t handle. Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.
opportune 3y ago
If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem. But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case). If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.

by teeray 3y ago

jasmer 3y ago

[dead]

dhbanes 3y ago

I always immediately approve implementation of any good idea regardless of roadmap or resource availability.

AceJohnny2 3y ago
Ah, the luxury of no deadlines...
- marcosdumay 3y ago
  Looks like good long-term project stewardship. If somebody just improved all future deadlines at the expense of a delay in one, isn't it great? (Yeah, there are a few times when it isn't; but if those are not few enough to be clearly communicated, your management is a bunch of dummies.)

Swizec 3y ago

My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well

bombela 3y ago
Or they were actually asking for time to officially work on it. Thinking their superior must have a good view of the big picture. Waiting confirmation that their idea made sense in the grand scheme of things.
- Swizec 3y ago
  In that case giving them permission does the trick and the improvements happen. Huzzah! The other side is making sure to always plan for enough slack in the system so people have time for these things, if they choose to use it.
ianmcgowan 3y ago
AKA "The Wally Reflector" from Dilbert :_)
- Swizec 3y ago
  Looked that up thinking I'll disagree, but actually yes. As you grow in your role, you get to a point where the number of incoming "quick requests" outpaces your ability to keep up. To most people they're just asking for a quick 10 minutes of your time, what's the big deal. But they don't see the other 20 people doing the same thing. If you devote 200min+ of every day to fulfilling others' requests, when will you have time to do your own work? The problem grows only worse the higher in the org chart (formal or informal) you get. Someone like a VPofEng may have 100 people asking "quick questions" all the time. Without the Wally Deflector, there's literally not enough time in the day to even have all these conversations, let alone do anything about 'em.

pydry 3y ago

The non dysfunctional way to deal with this is to allocate between 20% of dev time to process improvements and vote on large scale changes.

CoastalCoder 3y ago
Ensure you use the dysfunctional version of that, where some individuals are always outvoted. Over time, they'll become some of your favorite object lessons about employee engagement!
seattle_spring 3y ago
Every place I’ve worked has had a “20% tech debt” time. Universally, it’s used as a reason to not fix technical debt as opposed to enabling engineers to fix long-standing problems. “Oh you need to re-write such and such? Well that’ll take 40% of your time for 3 weeks and the max time we can allocate is 20% so…”

dxdenton 3y ago

If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the better, as this guy is no longer my manager. For the record, my super-great-idea was upgrading some 5+ year old software that was giving us and the devs a lot of headaches. I was told it could not be done, and it would be replaced by The Next Great Thing, which would take 6-8 months of engineering. I upgraded the thing in a day (in dev) just to prove that it could be done. Despite praises from my teammates (and devs) I had undermined The Manager. Although I know he wanted to, he could not berate or yell or force me to rollback —- imagine telling dev we are rolling back to a five year old version. In any case, ten years in and I’ve learned that the manager is a hard cap on the productivity of a team. The most productive team I’ve been on did not have a manager. We didn’t need a JIRA board or a roadmap or someone to help us plan or prioritize. We simply got our work done. Imagine that.

jcon321 3y ago
In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.
- peteradio 3y ago
  It was in dev environment which I doubt in his world required any sort of management approval.
- dxdenton 3y ago
  I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.” > There’s always a way to get housekeeping items approved… Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).

nineplay 3y ago

I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.

opportune 3y ago
Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more. I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.

LargeTomato 3y ago

YES. Fake praise and empty, kind words will get you far. Unfortunately I learned this far too late. To me it feels gross and manipulative but that's what people want.

j45 3y ago

There should absolutely be separate meetings for new idea separate status updates, and ideally status update meetings should only be for chatting about what digital updates can’t handle. Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.

opportune 3y ago

If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem. But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case). If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.