4 ms·

>All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion.

>All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion. There are processes in place to get things like this removed. If you are iterating and being “agile”, then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay. Based on this explanation the lead wanted a quick hack put into the code and the developer didn't want to write it (probably because it was a bad idea). So here's how you solve that. Get the developer to find a solution to whatever the problem the hack was solving. Give him a deadline. "If you feel this strongly about it, find a solution by tomorrow morning, or we need to put this hack in for this push." Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term.

finaliteration 9y ago
> Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term. The same could be said about questioning minor requests from someone who has more experience than you do and who has a greater responsibility to deliver on deadlines. Wasting hours of time over a single line is a great way to make people dislike you for being so inflexible, especially if it’s holding up the work of others on your team.
- Clubber 9y ago
  If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. If you force good developers to write bad code, you probably won't have good developers much longer. If I knew more about the circumstances, I could make a better judgement, but to me it sounds like the lead wanted the developer to put in shit code and he didn't want to. The thing about shit code is it costs 2x, 10x, 100x of technical debt later. Remember the article is written from someone biased towards the lead.
  - finaliteration 9y ago
    > If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. I’ve been on both sides, here, so I totally get the desire to write good code (and in my current role I’m working on best practices and good patterns with my team). That being said, good developers also realize that sometimes “hacks” are necessary to get something done, especially when deadlines are looming. Who among us hasn’t written something awful to get something finished or meet a deadline?
    - Clubber 9y ago
      I completely agree with you and because of that, I think it would warrant some sort of discussion, which wasn't allowed here. That's my main issue.
  - budman1 9y ago
    "can i have my paycheck?" "convince me."
    - Clubber 9y ago
      Explicit breach of contract.
      - abiox 9y ago
        insubordination may also be. it's well established as grounds for termination, and it could be a necessity in this situation.
  - ygaf 9y ago
    >Good developers don't like to write bad code. Good developers produce something. (and I'm condemning myself there)
    - deleted 9y ago
- msl09 9y ago
  "questioning minor requests from someone who has more experience than you do" I firmly believe that all authority should be questioned in the corporate environment. A good manager should have the wisdom to acknowledge that he can fail to see things that the developer did. If you go by what Clubber proposed then: * If the manager is right, the developer will notice the value of accepting the technical input of the manager and develop a keener sense of timing within the development process. * If the manager is wrong, the developer will understand that he shouldn't just accept orders handed down to him and remain mindful of the impact of the changes he makes to the code because his opinion will be respected by the rest of the team. Now the author mentioned that in his organization "There are processes in place to get things like this removed" so the issue might be more that the developer either doesn't know that the project exists or that it works. Only if it's the later and the manager is sure that refactoring is regularly performed the developer is wrong for his the insubordination.
  - finaliteration 9y ago
    I don’t disagree with you. I’ve certainly been known to push back and question things I didn’t like or agree with. I also agree with a few other comments that we’re missing a lot of context, so I’ve had to fill in with my own experience which is that A) Managing someone who questions every single decision is exhausting and leads to tension and the team being a lot less effective and B) Hacks made due to a time shortage can always be inserted into the next sprint to be resolved if it’s something important. I do think there’s a time and place to question authority, and maybe this could have been used as a better opportunity for mentoring, but I still think being rigid isn’t great for the team.
- tomjen3 9y ago
  That shouldn't be necessary: he should already have included what he was trying to accomplish and why, so that if you knew the code better (likely if you worked on it) you can catch issues before they happen.
paulgrimes1 9y ago
How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article. The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory. Anything else is an open conversation where humility is required on all sides.
- Clubber 9y ago
  >How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article. Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.) >The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory. I would be comfortable with that scenario.
  - paulgrimes1 9y ago
    > Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.) That’s a valid point. The article is not without flaws. Thanks for your reply!
tboyd47 9y ago
Or here's an even better solution: ask the developers for a solution, and then ask them how long it will take and why. Then go to your supervisor (or stakeholder or whoever) and tell them your engineers said it's going to take this long because of technical reason X, Y, and Z.
hashkb 9y ago
I've been a team lead and never had the "authority" to tell someone exactly how to write their code. I also would consider "convince me" a very appropriate response. If I fail to convince, I don't get what I want. That team member isn't insubordinate in my eyes, they are going places.
- tboyd47 9y ago
  Same here. On my last team, I took it as a point of pride that the developers had no hesitation to protest my suggestions for implementation and even flat out override them. We were also the only group in the larger team who met our objectives on time without working long hours. I don't see those as unrelated. It's a good thing when your developers come up with better solutions than you, and even better when they aren't afraid to choose them over yours. When the manager is the most well-informed person on the team about implementation, that's when you should worry.
goblin89 9y ago
> All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion. Sounds like the kind of environment I used to work in. Team lead would specify the exact changes he wanted to see in the code, sometimes literally attaching marked-up screenshots in JIRA. I would typically not argue, but I left to consult independently partly due to this experience. Knowing the diff to achieve the desired effect is literally what my job is about; if you have the solution, why not go ahead and commit the changes yourself? It gave an impression that my purpose was primarily to be… a teammate, justifying that guy’s title as a team lead. That said, I was getting paid for that work still—an hourly rate that would be generous for a glorified typist. I struggle to come up with a logical explanation of why it left such an unpleasant residue.
- Clubber 9y ago
  Probably because developers are first and foremost designers and problem solvers. Code is just a medium. It's like an author taking a job and it ends up being as a typist. She's probably capable, but she'll be miserable, because that's not what she does.

finaliteration 9y ago

> Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term. The same could be said about questioning minor requests from someone who has more experience than you do and who has a greater responsibility to deliver on deadlines. Wasting hours of time over a single line is a great way to make people dislike you for being so inflexible, especially if it’s holding up the work of others on your team.

Clubber 9y ago
If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. If you force good developers to write bad code, you probably won't have good developers much longer. If I knew more about the circumstances, I could make a better judgement, but to me it sounds like the lead wanted the developer to put in shit code and he didn't want to. The thing about shit code is it costs 2x, 10x, 100x of technical debt later. Remember the article is written from someone biased towards the lead.
- finaliteration 9y ago
  > If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. I’ve been on both sides, here, so I totally get the desire to write good code (and in my current role I’m working on best practices and good patterns with my team). That being said, good developers also realize that sometimes “hacks” are necessary to get something done, especially when deadlines are looming. Who among us hasn’t written something awful to get something finished or meet a deadline?
  - Clubber 9y ago
    I completely agree with you and because of that, I think it would warrant some sort of discussion, which wasn't allowed here. That's my main issue.
- budman1 9y ago
  "can i have my paycheck?" "convince me."
  - Clubber 9y ago
    Explicit breach of contract.
    - abiox 9y ago
      insubordination may also be. it's well established as grounds for termination, and it could be a necessity in this situation.
- ygaf 9y ago
  >Good developers don't like to write bad code. Good developers produce something. (and I'm condemning myself there)
  - deleted 9y ago
msl09 9y ago
"questioning minor requests from someone who has more experience than you do" I firmly believe that all authority should be questioned in the corporate environment. A good manager should have the wisdom to acknowledge that he can fail to see things that the developer did. If you go by what Clubber proposed then: * If the manager is right, the developer will notice the value of accepting the technical input of the manager and develop a keener sense of timing within the development process. * If the manager is wrong, the developer will understand that he shouldn't just accept orders handed down to him and remain mindful of the impact of the changes he makes to the code because his opinion will be respected by the rest of the team. Now the author mentioned that in his organization "There are processes in place to get things like this removed" so the issue might be more that the developer either doesn't know that the project exists or that it works. Only if it's the later and the manager is sure that refactoring is regularly performed the developer is wrong for his the insubordination.
- finaliteration 9y ago
  I don’t disagree with you. I’ve certainly been known to push back and question things I didn’t like or agree with. I also agree with a few other comments that we’re missing a lot of context, so I’ve had to fill in with my own experience which is that A) Managing someone who questions every single decision is exhausting and leads to tension and the team being a lot less effective and B) Hacks made due to a time shortage can always be inserted into the next sprint to be resolved if it’s something important. I do think there’s a time and place to question authority, and maybe this could have been used as a better opportunity for mentoring, but I still think being rigid isn’t great for the team.
tomjen3 9y ago
That shouldn't be necessary: he should already have included what he was trying to accomplish and why, so that if you knew the code better (likely if you worked on it) you can catch issues before they happen.

paulgrimes1 9y ago

How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article. The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory. Anything else is an open conversation where humility is required on all sides.

Clubber 9y ago
>How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article. Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.) >The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory. I would be comfortable with that scenario.
- paulgrimes1 9y ago
  > Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.) That’s a valid point. The article is not without flaws. Thanks for your reply!

tboyd47 9y ago

Or here's an even better solution: ask the developers for a solution, and then ask them how long it will take and why. Then go to your supervisor (or stakeholder or whoever) and tell them your engineers said it's going to take this long because of technical reason X, Y, and Z.

hashkb 9y ago

I've been a team lead and never had the "authority" to tell someone exactly how to write their code. I also would consider "convince me" a very appropriate response. If I fail to convince, I don't get what I want. That team member isn't insubordinate in my eyes, they are going places.

tboyd47 9y ago
Same here. On my last team, I took it as a point of pride that the developers had no hesitation to protest my suggestions for implementation and even flat out override them. We were also the only group in the larger team who met our objectives on time without working long hours. I don't see those as unrelated. It's a good thing when your developers come up with better solutions than you, and even better when they aren't afraid to choose them over yours. When the manager is the most well-informed person on the team about implementation, that's when you should worry.

goblin89 9y ago

> All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion. Sounds like the kind of environment I used to work in. Team lead would specify the exact changes he wanted to see in the code, sometimes literally attaching marked-up screenshots in JIRA. I would typically not argue, but I left to consult independently partly due to this experience. Knowing the diff to achieve the desired effect is literally what my job is about; if you have the solution, why not go ahead and commit the changes yourself? It gave an impression that my purpose was primarily to be… a teammate, justifying that guy’s title as a team lead. That said, I was getting paid for that work still—an hourly rate that would be generous for a glorified typist. I struggle to come up with a logical explanation of why it left such an unpleasant residue.

Clubber 9y ago
Probably because developers are first and foremost designers and problem solvers. Code is just a medium. It's like an author taking a job and it ends up being as a typist. She's probably capable, but she'll be miserable, because that's not what she does.