4 ms·

> 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 qu

> 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
    [deleted]
- wolco 9y ago
  Senior developers know that wasting two days fighting would be better spent elsewhere. This is an example of a midlevel programmer who can program but doesn't understand the big picture. Probably the type of person to follow one way of doing somethig and freakout on anyone who suggests something different. This developer doesn't get it... they need a few more years of seasoning. The lead is in charge of making those decisions. Having a working feature in time for the sales demo is more important than some code purity. They do not understand the difference between getting paid to do a task vs creating a personal hobby project.
  - Clubber 9y ago
    >Senior developers know that wasting two days fighting would be better spent elsewhere. I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects. But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.
    - wolco 9y ago
      You are not stuck with those things. Converting dates or adding references or changing the customer model or even migrating to a different type of database are things you would normally do when you start scaling anyways. The code doesn't have to be perfect aligned to some doctrine. If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.
      - Clubber 9y ago
        >are things you would normally do when you start scaling anyways. It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad. >The code doesn't have to be perfect aligned to some doctrine. If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine. >If you feel the need to fight back over a single private member variable delay some important release I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.
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.

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
  [deleted]
wolco 9y ago
Senior developers know that wasting two days fighting would be better spent elsewhere. This is an example of a midlevel programmer who can program but doesn't understand the big picture. Probably the type of person to follow one way of doing somethig and freakout on anyone who suggests something different. This developer doesn't get it... they need a few more years of seasoning. The lead is in charge of making those decisions. Having a working feature in time for the sales demo is more important than some code purity. They do not understand the difference between getting paid to do a task vs creating a personal hobby project.
- Clubber 9y ago
  >Senior developers know that wasting two days fighting would be better spent elsewhere. I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects. But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.
  - wolco 9y ago
    You are not stuck with those things. Converting dates or adding references or changing the customer model or even migrating to a different type of database are things you would normally do when you start scaling anyways. The code doesn't have to be perfect aligned to some doctrine. If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.
    - Clubber 9y ago
      >are things you would normally do when you start scaling anyways. It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad. >The code doesn't have to be perfect aligned to some doctrine. If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine. >If you feel the need to fight back over a single private member variable delay some important release I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.

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.