I agree with a lot of what you’re saying. Certainly about measuring yourself by your delivery rate and your bug rate.
BUT I think you’re taking quite a binary view to say that TDD skills don’t matter. Because one way to improve your delivery rate would surely be to ”improve” your TDD, for some definition of TDD.
Just based on my own experience, it took me many years (close to a decade?) of unit testing to get to the point where I could confidently say that I was testing well. Even though I’d read a bunch of books about testing and software design, it wasn’t until I joined a TDD consultancy that I worked with people who actively showed me how to improve my code. An example would have been number of lines in a test, and keeping tests DRY: before that my average test might have been 7 lines; for them it was 4 lines or less. As soon as someone pointed it out to me as I was instantly able to improve. That kind of little thing.
Now that I work with juniors a lot, I know they get TDD but there’s a whole bunch of software design they still don’t get, like how to spot opportunities to create abstractions. Pairing with them helps me point out patterns in their code that aren’t directly visible, and then convince them that pulling out the abstraction is worthwhile.
The other reason I like pairing and mobbing is because, as someone who is very easily distracted, it actually makes me more productive, since I'm not just checking the news every 5 minutes. I appreciate not every developer suffers from this problem, and I do think that proponents of mobbing underplay this psychological benefit, but it’s certainly a major benefit for me.
Wrt JIRA, I’m completely with you on that one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with a lot of what you’re saying. Certainly about measuring yourself by your delivery rate and your bug rate.
BUT I think you’re taking quite a binary view to say that TDD skills don’t matter. Because one way to improve your delivery rate would surely be to ”improve” your TDD, for some definition of TDD.
Just based on my own experience, it took me many years (close to a decade?) of unit testing to get to the point where I could confidently say that I was testing well. Even though I’d read a bunch of books about testing and software design, it wasn’t until I joined a TDD consultancy that I worked with people who actively showed me how to improve my code. An example would have been number of lines in a test, and keeping tests DRY: before that my average test might have been 7 lines; for them it was 4 lines or less. As soon as someone pointed it out to me as I was instantly able to improve. That kind of little thing.
Now that I work with juniors a lot, I know they get TDD but there’s a whole bunch of software design they still don’t get, like how to spot opportunities to create abstractions. Pairing with them helps me point out patterns in their code that aren’t directly visible, and then convince them that pulling out the abstraction is worthwhile.
The other reason I like pairing and mobbing is because, as someone who is very easily distracted, it actually makes me more productive, since I'm not just checking the news every 5 minutes. I appreciate not every developer suffers from this problem, and I do think that proponents of mobbing underplay this psychological benefit, but it’s certainly a major benefit for me.
Wrt JIRA, I’m completely with you on that one.