When John worked as a developer on his own, he was responsible for quality - he had complete freedom and could choose to write clean code and run tests.
Firstly, by recognizing the pitfalls of being a bottleneck (overcoming ego issues).
Secondly, by putting in place processes thst enable the team to get fast automated feedback without relying on the Tech Lead - this is where Continuous Delivery comes in.
It depends on the company your working for and how much time and freedom you have. Coding standards, CI/CD, regular commits and branch merges all help a bottleneck down the track.
Based on your experiences, what kind of company types did you work in, and what factors affected whether there was support for technical best practices?
Left my last job because of exactly that. They were dead against writing tests during development. They let the juniors and intermediates bang away at it without bothering to teach them how to write and use tests. Then I would have to plaster it up at the end fixing bugs and refactoring just enough to get it into production with minimal as possible testing capability. I couldn't handle working like that for very long.
"Then I would have to plaster it up at the end fixing bugs and refactoring just enough to get it into production with minimal as possible testing capability."
Was was the company's process like? Was it Development phase, then Manual QA Testing phase, then bug-fixing phase? What was your role in the team? Did anyone else take ownership of the bugs?
That’s a great question. I’ve experienced teammates going as far as not wanting to do it using the excuse of it prolonging releases / they know what the code should do , how it works so tests are unnecessary. Then bringing the Product owner, scrum master, manager/lead into it during standups, plannings, refinements to support their cases.
My solution as a senior engineer was/is to immediately lead by example and not only do tdd / automated testing but do it exceptionally well giving the teammates/po’s pm’s, any person that has title with a P no excuse to not do it or not support it or risk looking seriously incompetent/ unprofessional and myself looking exceedingly ahead of the team.
It’s a poker game much of the time on a software team.
I don’t play poker though, I play blackjack and count cards while doing it because I like to have the advantage in any situation regardless of who it is against or if they will try to get rid of me ( including team members here along with casino staff ) . In this case you have the opportunity to stack the deck then lay your bet down knowing you have it all but won before the cards come out. When they do. Your team, po’s and manager ( happily ) will have no choice but to write tests. Begrudgingly, angry, jealous as they may be, it’s for the greater good.
What is your approach regarding leading by example in a legacy codebase. Let's say you're the senior in this example, no one else on the team is writing tests at all (so the code has tangled up dependencies). How would you approach this, what would you do?
Great question and I get some strange satisfaction out of adding tests to a codebase that was thought of to be un- testable. I get that not everyone has this trait.
For legacy code I have a similar approach as my first comment but with more care /understanding for the team and code. My goal is to leave the codebase better than we found it. That could be adding tests for at least new code or setting a team goal to increase total branch coverage by 5%. Another option is to have a team goal to increase the file coverage each team member is working in to have 90 or 100% if possible. Again stressing good tests that have value your team can see as opposed to just #’s. Those % can be whatever amount you determine would be of value. If there’s not even a testing framework setup, getting it setup as soon as possible would be where to start. I’m in that situation now in a php drupal codebase I don’t have much prior experience in so I need to really motivate myself and remind myself of the value in the long term as opposed to me just shooting for speed and quick ( undeserved ) promotion as many do. Not my style and I don’t want to be fixing expensive prod bugs a year from now when that code is a distant memory at best. Plus I do not want anyone doing the same knowing I didn’t have at least unit testing added.
It never made me the most popular with product but my boss was always happy behind closed doors at least and teammates were always appreciative eventually especially if testing became a division/company initiative. Can’t please everyone. You can just deliver the best software you can given the circumstances. You of course know that automated testing is a large part of that.
How can Tech Leads prevent becoming bottlenecks before it's too late?
Firstly, by recognizing the pitfalls of being a bottleneck (overcoming ego issues).
Secondly, by putting in place processes thst enable the team to get fast automated feedback without relying on the Tech Lead - this is where Continuous Delivery comes in.
It depends on the company your working for and how much time and freedom you have. Coding standards, CI/CD, regular commits and branch merges all help a bottleneck down the track.
Based on your experiences, what kind of company types did you work in, and what factors affected whether there was support for technical best practices?
Left my last job because of exactly that. They were dead against writing tests during development. They let the juniors and intermediates bang away at it without bothering to teach them how to write and use tests. Then I would have to plaster it up at the end fixing bugs and refactoring just enough to get it into production with minimal as possible testing capability. I couldn't handle working like that for very long.
"Then I would have to plaster it up at the end fixing bugs and refactoring just enough to get it into production with minimal as possible testing capability."
Was was the company's process like? Was it Development phase, then Manual QA Testing phase, then bug-fixing phase? What was your role in the team? Did anyone else take ownership of the bugs?
"They were dead against writing tests during development."
What reasons did they give as why *not* to write tests during development?
That’s a great question. I’ve experienced teammates going as far as not wanting to do it using the excuse of it prolonging releases / they know what the code should do , how it works so tests are unnecessary. Then bringing the Product owner, scrum master, manager/lead into it during standups, plannings, refinements to support their cases.
My solution as a senior engineer was/is to immediately lead by example and not only do tdd / automated testing but do it exceptionally well giving the teammates/po’s pm’s, any person that has title with a P no excuse to not do it or not support it or risk looking seriously incompetent/ unprofessional and myself looking exceedingly ahead of the team.
It’s a poker game much of the time on a software team.
I don’t play poker though, I play blackjack and count cards while doing it because I like to have the advantage in any situation regardless of who it is against or if they will try to get rid of me ( including team members here along with casino staff ) . In this case you have the opportunity to stack the deck then lay your bet down knowing you have it all but won before the cards come out. When they do. Your team, po’s and manager ( happily ) will have no choice but to write tests. Begrudgingly, angry, jealous as they may be, it’s for the greater good.
What is your approach regarding leading by example in a legacy codebase. Let's say you're the senior in this example, no one else on the team is writing tests at all (so the code has tangled up dependencies). How would you approach this, what would you do?
Great question and I get some strange satisfaction out of adding tests to a codebase that was thought of to be un- testable. I get that not everyone has this trait.
For legacy code I have a similar approach as my first comment but with more care /understanding for the team and code. My goal is to leave the codebase better than we found it. That could be adding tests for at least new code or setting a team goal to increase total branch coverage by 5%. Another option is to have a team goal to increase the file coverage each team member is working in to have 90 or 100% if possible. Again stressing good tests that have value your team can see as opposed to just #’s. Those % can be whatever amount you determine would be of value. If there’s not even a testing framework setup, getting it setup as soon as possible would be where to start. I’m in that situation now in a php drupal codebase I don’t have much prior experience in so I need to really motivate myself and remind myself of the value in the long term as opposed to me just shooting for speed and quick ( undeserved ) promotion as many do. Not my style and I don’t want to be fixing expensive prod bugs a year from now when that code is a distant memory at best. Plus I do not want anyone doing the same knowing I didn’t have at least unit testing added.
It never made me the most popular with product but my boss was always happy behind closed doors at least and teammates were always appreciative eventually especially if testing became a division/company initiative. Can’t please everyone. You can just deliver the best software you can given the circumstances. You of course know that automated testing is a large part of that.
Which test types do you start with, on Legacy Code?
How did your team react when you set the team goals to add coverage?