4 ms·

You mentioned "shitty enterprise software, on one of the worst code bases I've ever seen" Do you realize that this is your fault too? Your job is to manage, m

You mentioned "shitty enterprise software, on one of the worst code bases I've ever seen" Do you realize that this is your fault too? Your job is to manage, maintain and improve the code-base but, instead, you choose to take advantage of the fact that you still get paid because people aren't micromanaging you and forcing you to do your job. You should realize that lousy codebases and micromanagers exist because of the people who act like you are acting -- without a sense of personal responsibility and accountability. Your lack of responsibility and commitment is a central reason why things are lousy for the rest of us.

EastSmith 9y ago
The tech-lead is responsible for the codebase.
FLUX-YOU 9y ago
The shitty code base existed before they got there. Dropping 'new, refactored code base' onto your managers lap can go a couple of ways. Doing it quietly is a recipe for disaster because then you have no support. Your manager could deny a rewrite altogether. Then what? If we had reasonable social safety nets, I would say quickly that he is irresponsible staying after finding out about the code base. But the problem is that employers upsell the stuff you're going to be working on. They don't tell you upfront that it's shit and you're the one to rewrite it. If you ask them about the quality of their code, they'd likely respond with "it has some painful points here and there" or some other non-answer. If they hired OP to rewrite it, then yes, they're not fulfilling their responsibilities. But it sounds like a place that just shovels JIRA issues at you and tells you to go fix them. An employer-employee relationship does not necessarily imply "I must do everything in my power to make sure this product is the best that it can be within my 40hrs/week". If you are leadership or a product owner, you have that burden, but not necessarily a LOB developer position. If they gave him that responsibility, they should immediately ask for a significant raise, because they've changed virtually the entire job which they were hired for.
- kweinber 9y ago
  The world in which everyone solely does the minimum of what they are explicitly asked to do would be a unkind, bleak, unproductive, and dysfunctional one. I am extremely grateful that not everyone espouses this philosophy.
  - FLUX-YOU 9y ago
    Dying for corporate is not a hill you want to die on. There are certainly companies which are worth putting in 100% effort, but this isn't one of them for OP. But the reality is that most of us need a job. Who can we blame for not being able to perfectly match employers with employees and giving everyone a fairy tale ending?
rjzzleep 9y ago
I assume you've never been in an enterprise environment. There are surely good ones, but a common theme is the following: People will outsource a lot of things. The people outsourcing are not generally knowledgeable people but managers. They buy crappy software against the advice of their own engineers and then ask the engineers to maintain it. What's worse is that a lot of young engineers will learn code from that crap. I have seen contractors in 2014 laughing at the enterprise for using something as silly as SVN or git. They sent a Whitepaper saying that file locking is the only right way of version control. Do you know how hard it is to correct a bad managers perception? I did, but I also lost my job. They also had if statements that were 2000 columns wide. Only reason I knew what because I installed a trial version of resharper and ran their code through it. You might think it's uncommon, but I've seen it in all sorts of places. The current place where it took me 2 years to convince senior management to buy resharper. They do the things I advise them to do, but it takes a shitload of convincing. An EE in the company just died of a heart attack. There's a massive load of cognitive dissonance in there, he tried to fix all sorts of stuff(which is good), but he never got around learning to objectively not care about it(i.e. if they screw up in the end it's their responsibility not yours, you advise them and they actively chose not to listen). But putting the blame on those people, is at the very least extremely disingenuous. The only fair question you can ask in this case is, why not just leave. For me it has strategic value, I generally advise people against doing so though.
reificator 9y ago
Not the OP, but there's often only so much you can do. Bad software is often a cultural problem, and I know first hand that you can't just go in and change the culture of a place with the snap of your fingers, especially when you're not in management. Sometimes you can't get authorization to work on things that would be a "waste of time", even if it means you sit there visibly doing nothing. That's just the way enterprises are sometimes.
amag 9y ago
For a new member of a team it's very hard to be committed and take responsibility of the code base if none of the old team members care.

EastSmith 9y ago

The tech-lead is responsible for the codebase.

FLUX-YOU 9y ago

The shitty code base existed before they got there. Dropping 'new, refactored code base' onto your managers lap can go a couple of ways. Doing it quietly is a recipe for disaster because then you have no support. Your manager could deny a rewrite altogether. Then what? If we had reasonable social safety nets, I would say quickly that he is irresponsible staying after finding out about the code base. But the problem is that employers upsell the stuff you're going to be working on. They don't tell you upfront that it's shit and you're the one to rewrite it. If you ask them about the quality of their code, they'd likely respond with "it has some painful points here and there" or some other non-answer. If they hired OP to rewrite it, then yes, they're not fulfilling their responsibilities. But it sounds like a place that just shovels JIRA issues at you and tells you to go fix them. An employer-employee relationship does not necessarily imply "I must do everything in my power to make sure this product is the best that it can be within my 40hrs/week". If you are leadership or a product owner, you have that burden, but not necessarily a LOB developer position. If they gave him that responsibility, they should immediately ask for a significant raise, because they've changed virtually the entire job which they were hired for.

kweinber 9y ago
The world in which everyone solely does the minimum of what they are explicitly asked to do would be a unkind, bleak, unproductive, and dysfunctional one. I am extremely grateful that not everyone espouses this philosophy.
- FLUX-YOU 9y ago
  Dying for corporate is not a hill you want to die on. There are certainly companies which are worth putting in 100% effort, but this isn't one of them for OP. But the reality is that most of us need a job. Who can we blame for not being able to perfectly match employers with employees and giving everyone a fairy tale ending?

rjzzleep 9y ago

I assume you've never been in an enterprise environment. There are surely good ones, but a common theme is the following: People will outsource a lot of things. The people outsourcing are not generally knowledgeable people but managers. They buy crappy software against the advice of their own engineers and then ask the engineers to maintain it. What's worse is that a lot of young engineers will learn code from that crap. I have seen contractors in 2014 laughing at the enterprise for using something as silly as SVN or git. They sent a Whitepaper saying that file locking is the only right way of version control. Do you know how hard it is to correct a bad managers perception? I did, but I also lost my job. They also had if statements that were 2000 columns wide. Only reason I knew what because I installed a trial version of resharper and ran their code through it. You might think it's uncommon, but I've seen it in all sorts of places. The current place where it took me 2 years to convince senior management to buy resharper. They do the things I advise them to do, but it takes a shitload of convincing. An EE in the company just died of a heart attack. There's a massive load of cognitive dissonance in there, he tried to fix all sorts of stuff(which is good), but he never got around learning to objectively not care about it(i.e. if they screw up in the end it's their responsibility not yours, you advise them and they actively chose not to listen). But putting the blame on those people, is at the very least extremely disingenuous. The only fair question you can ask in this case is, why not just leave. For me it has strategic value, I generally advise people against doing so though.

reificator 9y ago

Not the OP, but there's often only so much you can do. Bad software is often a cultural problem, and I know first hand that you can't just go in and change the culture of a place with the snap of your fingers, especially when you're not in management. Sometimes you can't get authorization to work on things that would be a "waste of time", even if it means you sit there visibly doing nothing. That's just the way enterprises are sometimes.

amag 9y ago

For a new member of a team it's very hard to be committed and take responsibility of the code base if none of the old team members care.