3 ms·

My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system

by kirykl 8y ago

majormajor 8y ago
I agree completely with this, but getting back to the human factors: - It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus" - the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap." The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."
- compiler-guy 8y ago
  A lot of times if you say, "I'm having trouble understanding how module X does Y, and why it works that way." And the developer will say, "Yeah, I kind of hacked that together when the requirements changed. In a perfect world, it would get rewritten, but I've had a bunch of other things higher priority." So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.
  - majormajor 8y ago
    Yep. And then you understand that you weren't wrong, and the opportunity for improvement is there, when time is available, but you haven't risked alienating people by treating them as if they're idiots for writing imperfect code.
zelos 8y ago
For every story like this, though, there are probably 10 where the new hire didn’t know better than everyone else. I know I’ve dealt with plenty of people like that.

My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system

by kirykl 8y ago

My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system

majormajor 8y ago

I agree completely with this, but getting back to the human factors: - It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus" - the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap." The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."

compiler-guy 8y ago
A lot of times if you say, "I'm having trouble understanding how module X does Y, and why it works that way." And the developer will say, "Yeah, I kind of hacked that together when the requirements changed. In a perfect world, it would get rewritten, but I've had a bunch of other things higher priority." So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.
- majormajor 8y ago
  Yep. And then you understand that you weren't wrong, and the opportunity for improvement is there, when time is available, but you haven't risked alienating people by treating them as if they're idiots for writing imperfect code.

zelos 8y ago

For every story like this, though, there are probably 10 where the new hire didn’t know better than everyone else. I know I’ve dealt with plenty of people like that.