3 ms·

Here's a hard earned tip. The first few months, nobody's going to expect much from you anyway. Try to stretch the time you're 'getting up to speed with the code

by roel_v 8y ago

Here's a hard earned tip. The first few months, nobody's going to expect much from you anyway. Try to stretch the time you're 'getting up to speed with the code' as long as possible. But in that time, write as many tests as possible. Don't tell anyone unless they ask; if there is no testing culture, they'll think you're just wasting your time on it. Then at some point you will be expected to start delivering value. At that point, you can start making changes (refactoring where necessary) without fear. This will let you grow your status in the organisation until you have a reputation of being the guy that can get things done and doesn't complain about how bad everything is and how everything is someone else's fault when he's assigned a task. At that point, you can start making others write and maintain tests while you take control of keeping oversight of improving the code base quality. Do not be tempted into 'rewrites' because you're setting yourself up for failure. It's a long play, yes. If you're feeling the way you describe just from the current state, you're probably not senior enough to do it. It requires much more than just technical skills - those are abundant, it's not what you can build a career on. It's a bit Machiavellan, I guess, but in the end, everyone wins - but you need to have the Vision that others are not able to understand, so you have to find ways to make it happen anyway, in adversarial circumstances. Good luck.

vjandrea 8y ago
> write as many tests as possible Definitely: this will help you to better understand what the code does and the dependencies involved. Climb up the dependencies tree and add tests there as well.
no7hing 8y ago
If there's no testing culture it's pretty hard to introduce it into a team that doesn't have it (either by choice or omission). It gets even worse if your teammates don't update tests (thus break CI) on code changes or just comment the tests out. I've seen both happening way too often and would recommend getting at least some sort of team buy-in - as the alternative will surely burn you out sooner or later.
- arcticbull 8y ago
  I've actually seen it done within a large organization. It takes one boyscout who's respected and can clearly demonstrate the value provided by testing and designing for testability, and people will fall in line. Nobody likes building on quicksand, so show them what concrete looks like.
  - eric-hu 8y ago
    > Nobody likes building on quicksand, so show them what concrete looks like. Damn that's motivating. I'll be quoting you on this one.
- roel_v 8y ago
  If you're the new hire and the first you you're doing is pester everyone with extra work they don't see the advantage of - that'll just get you the reputation of a know it all, in my experience. That's why I suggested to start chipping at it on his own, so that he can show the value a few months down the line, rather than telling everyone how great it's going to be when he's not respected yet or hasn't proven himself yet. But that's also what I meant by 'it's not a technical issue'. It's a matter of positioning himself as a reliable person whose opinion on technical matters needs to be considered. New hires generally aren't, unless they have an impressive resume or reputation before they started at the company. But someone like that doesn't ask this question to a bunch of strangers on the internet. Of course it depends on the circumstances. If you're on your own trying to maintain a test suite on the code of 50 other people, none of whom work on these tests and think you're just trying to slow them down for no good reason, there's no way that will work. But if there's only a few people working on the code and you can maintain tests for a more or less well defined part of it - it's possible (if you're experienced enough; if you have to spend 2 weeks reading up on how to do unit testing, it's not a viable strategy of course.)
mleonhard 8y ago
If you have the choice, change teams or companies as soon as possible. Life is too short to spend it paying off someone else's debt. If moving is not an option, then follow the parent's advice. Add all the missing tests as fast as you can. Explain what you are doing to your manager. And set up CI to email your team whenever anyone checks in breaking changes. This will motivate your teammate to start running your tests. If they are particularly narrow-minded, they will be unhappy about this. If this happens, reconsider your decision to stay. Even after you write a lot of tests, coverage will be low. You will likely code some bugs that negatively impact the business. I urge you to find a mentor inside the company, a senior engineer or engineering manager, and show them code and explain the technical debt to them. Try not to blame your teammate for the situation, just explain to your mentor that you are concerned about introducing bugs. Ask them to keep your discussion confidential. Your mentor can back you up when your bugs negatively impact the business.

by roel_v 8y ago

vjandrea 8y ago

> write as many tests as possible Definitely: this will help you to better understand what the code does and the dependencies involved. Climb up the dependencies tree and add tests there as well.

no7hing 8y ago

If there's no testing culture it's pretty hard to introduce it into a team that doesn't have it (either by choice or omission). It gets even worse if your teammates don't update tests (thus break CI) on code changes or just comment the tests out. I've seen both happening way too often and would recommend getting at least some sort of team buy-in - as the alternative will surely burn you out sooner or later.

arcticbull 8y ago
I've actually seen it done within a large organization. It takes one boyscout who's respected and can clearly demonstrate the value provided by testing and designing for testability, and people will fall in line. Nobody likes building on quicksand, so show them what concrete looks like.
- eric-hu 8y ago
  > Nobody likes building on quicksand, so show them what concrete looks like. Damn that's motivating. I'll be quoting you on this one.
roel_v 8y ago
If you're the new hire and the first you you're doing is pester everyone with extra work they don't see the advantage of - that'll just get you the reputation of a know it all, in my experience. That's why I suggested to start chipping at it on his own, so that he can show the value a few months down the line, rather than telling everyone how great it's going to be when he's not respected yet or hasn't proven himself yet. But that's also what I meant by 'it's not a technical issue'. It's a matter of positioning himself as a reliable person whose opinion on technical matters needs to be considered. New hires generally aren't, unless they have an impressive resume or reputation before they started at the company. But someone like that doesn't ask this question to a bunch of strangers on the internet. Of course it depends on the circumstances. If you're on your own trying to maintain a test suite on the code of 50 other people, none of whom work on these tests and think you're just trying to slow them down for no good reason, there's no way that will work. But if there's only a few people working on the code and you can maintain tests for a more or less well defined part of it - it's possible (if you're experienced enough; if you have to spend 2 weeks reading up on how to do unit testing, it's not a viable strategy of course.)

mleonhard 8y ago

If you have the choice, change teams or companies as soon as possible. Life is too short to spend it paying off someone else's debt. If moving is not an option, then follow the parent's advice. Add all the missing tests as fast as you can. Explain what you are doing to your manager. And set up CI to email your team whenever anyone checks in breaking changes. This will motivate your teammate to start running your tests. If they are particularly narrow-minded, they will be unhappy about this. If this happens, reconsider your decision to stay. Even after you write a lot of tests, coverage will be low. You will likely code some bugs that negatively impact the business. I urge you to find a mentor inside the company, a senior engineer or engineering manager, and show them code and explain the technical debt to them. Try not to blame your teammate for the situation, just explain to your mentor that you are concerned about introducing bugs. Ask them to keep your discussion confidential. Your mentor can back you up when your bugs negatively impact the business.