How do you measure your TDD skills? You don't. Fundamentally, TDD skills don't mater, as they aren't the end goal. You should measure your skills on how much working software you deliver to your product owner and how many defects are raised against it as well as the severity of them. The aim isn't TDD, or coverage; that's purely a way of working for an engineer to deliver work with a high bar for quality.
About mobbing; I'll be open and honest - I dislike mob programming.
If you are constantly getting stuck then read the docs, speak to people about specific problems, or go on training. I really don't agree that holding up another 2+ engineers in the team to work at the pace of the slowest engineer is the right approach. I get fed up at the idealism that seems to imply that it's OK for 3+ people to not be able to do their jobs and instead all sit around one computer in the name of collaberation. No. Collaberation is working together to achieve a common goal without artifical limitations such as using 1 machine. How about we do a few playbacks or show-and-tell style sessions to run through how the tools we use are actually working? How about we sit at a desk next to each other and make sure that it's entirely safe and OK to ask questions whenever you need? That's real collaberation. Individuals and interactions... that's where it's at; and it doesn't require 3 people to watch one screen.
Am I saying I don't make mistakes? No - I do quite often. I write tests as I go that find a lot of them, and I do this because I care about my work, not because I've got some person sat with me muttering "should we test that?". We also have a QE function that I'll work closely with whilst developing a feature or fixing a bug. We define scenarios together, and either of us can write the steps for any test. 3 people is half the capacity of most teams. Does it make sense to have half the team watch whilst one modifies some json file, messes with some properties and waits to watch something deploy? The only thing worse is watching a full team sat around whislt one person creates stories in jira.
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.
How do you measure your TDD skills? You don't. Fundamentally, TDD skills don't mater, as they aren't the end goal. You should measure your skills on how much working software you deliver to your product owner and how many defects are raised against it as well as the severity of them. The aim isn't TDD, or coverage; that's purely a way of working for an engineer to deliver work with a high bar for quality.
About mobbing; I'll be open and honest - I dislike mob programming.
The general idea being, "I spend more time programming, because I spend less time stuck.".
If you are constantly getting stuck then read the docs, speak to people about specific problems, or go on training. I really don't agree that holding up another 2+ engineers in the team to work at the pace of the slowest engineer is the right approach. I get fed up at the idealism that seems to imply that it's OK for 3+ people to not be able to do their jobs and instead all sit around one computer in the name of collaberation. No. Collaberation is working together to achieve a common goal without artifical limitations such as using 1 machine. How about we do a few playbacks or show-and-tell style sessions to run through how the tools we use are actually working? How about we sit at a desk next to each other and make sure that it's entirely safe and OK to ask questions whenever you need? That's real collaberation. Individuals and interactions... that's where it's at; and it doesn't require 3 people to watch one screen.
Am I saying I don't make mistakes? No - I do quite often. I write tests as I go that find a lot of them, and I do this because I care about my work, not because I've got some person sat with me muttering "should we test that?". We also have a QE function that I'll work closely with whilst developing a feature or fixing a bug. We define scenarios together, and either of us can write the steps for any test. 3 people is half the capacity of most teams. Does it make sense to have half the team watch whilst one modifies some json file, messes with some properties and waits to watch something deploy? The only thing worse is watching a full team sat around whislt one person creates stories in jira.
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.