4 ms·

We don’t do code reviews anymore. We have a good quality gate (e2e tests) and pair programming. All development happens on main and gets directly deployed to pr

by javaunsafe2019 4y ago

We don’t do code reviews anymore. We have a good quality gate (e2e tests) and pair programming. All development happens on main and gets directly deployed to prod when the tests succeed … I hope I never have to use git flow or alike again in the future!

jagged-chisel 4y ago
What's the size of your team? Remote or on-site? How many timezones does it span? How senior are the team's members?
- sodapopcan 4y ago
  Not the OP but I've worked very successfully pair-programming full-time on a fully remote team of 6 devs, 1 tester, 1 designer, and 1 product manager. All devs were quite senior except for one junior (and that junior leveled up faaaaaasssssst). We usually rotated daily so if a story took three days, the two people who started it weren't the same two who finished it. We all developed a similar coding style for the particular project, everyone knew every part of the codebase to some degree, and we felt a collective ownership over it--there was none of that "Oh, I don't want to change this because Sam wrote it and they'll be mad if I change it" nonsense. However, our timezones only spanned three hours.
- jross225 4y ago
  I'm on a data team of 10, and after about 6 months of onboarding we have permissions to push directly to main pending passing tests. We generally do this for small changes, or changes where we are the context owner. With the caveat that reviews happen after the code is deployed, and usually within a few days. Personally, I like the process. It allows us to move quickly, and focus on blocking changes. We can still get reviews prior to pushing code if it is sensible (for large changes), but most (80%?) changes tend to be quite small.
  - rekahrv 4y ago
    That's an intriguing approach. It makes sense that not all changes are equal and they don't require the same review process. (And it certainly makes sense to encourage small changes.) What qualifies as a "small change"? Do you have some numbers to measure it? Or is it the developer's call?
krsrhe 4y ago
[dead]
throwawaaarrgh 4y ago
How long did it take to develop enough tests for that to work?
jpnc 4y ago
Who reviews tests then? Empty tests and assertEquals(1, 1) always show green.
- sodapopcan 4y ago
  Pair programming solves this.
nicoburns 4y ago
When you say you do pair programming, do you mean all of the time for everything? I'd argue you actually have a lot more code review in this case. You effectively have someone reviewing every line of code as it's written.
javaunsafe2019 4y ago
I’ll try to answer your questions: - the team size varied but in general we are quite small with around four developers - all within one time zone - all on senior level - not an answer but just for context: we didn’t had any prod incident within 3 years - we work fully remote - we do mob sessions most of the day - developing the e2e tests for the modules we wrote took not that much of time. Maybe 2-3 weeks for each product/module . Most of th me times it’s out something on s3 Herr and check API or DB there… most modules are trivial data transformations tbh but in the end most software i ever touched was…
- rekahrv 4y ago
  That sounds very interesting. Can you tell a bit more about those mob sessions? Do all 4 devs participate? Do you follow some structure?
  - javaunsafe2019 4y ago
    Yes of course: those sessions happen online using teams or slack. The start of the day in the team is the standup in the morning where we quickly socialise and make a plan for the day and discuss important topics like triggered monitors, security finding or alike. When we made the plan we decide who starts and just start working all in one session. Most of the time that’s 3 devs in one meeting. We switch active roles mostly 2 or 3 times a day but it can also happen that one dev is coding the whole day if he feels like or the others don’t feel like. It’s very opportunistic so to say.
    - rekahrv 4y ago
      Thanks a lot, that's very insightful. I've worked in various environments, but this is super different from all of them. :-) How often do the non-coding participants comment on sth? Is it more like a continuous conversation? Or rather one person coding and the others occasionally chiming in? How long is such a mob session? I'm also wondering what kind of team setup makes such a model feasible and successful... By the way, congrats :-) 3 years without a prod incident sounds impressing, indeed. How long has the team been working together? You've mentioned that all devs are on senior level. Do you have some kind of hierarchy within the team?

jagged-chisel 4y ago

What's the size of your team? Remote or on-site? How many timezones does it span? How senior are the team's members?

sodapopcan 4y ago
Not the OP but I've worked very successfully pair-programming full-time on a fully remote team of 6 devs, 1 tester, 1 designer, and 1 product manager. All devs were quite senior except for one junior (and that junior leveled up faaaaaasssssst). We usually rotated daily so if a story took three days, the two people who started it weren't the same two who finished it. We all developed a similar coding style for the particular project, everyone knew every part of the codebase to some degree, and we felt a collective ownership over it--there was none of that "Oh, I don't want to change this because Sam wrote it and they'll be mad if I change it" nonsense. However, our timezones only spanned three hours.
jross225 4y ago
I'm on a data team of 10, and after about 6 months of onboarding we have permissions to push directly to main pending passing tests. We generally do this for small changes, or changes where we are the context owner. With the caveat that reviews happen after the code is deployed, and usually within a few days. Personally, I like the process. It allows us to move quickly, and focus on blocking changes. We can still get reviews prior to pushing code if it is sensible (for large changes), but most (80%?) changes tend to be quite small.
- rekahrv 4y ago
  That's an intriguing approach. It makes sense that not all changes are equal and they don't require the same review process. (And it certainly makes sense to encourage small changes.) What qualifies as a "small change"? Do you have some numbers to measure it? Or is it the developer's call?

krsrhe 4y ago

[dead]

throwawaaarrgh 4y ago

How long did it take to develop enough tests for that to work?

jpnc 4y ago

Who reviews tests then? Empty tests and assertEquals(1, 1) always show green.

sodapopcan 4y ago
Pair programming solves this.

nicoburns 4y ago

When you say you do pair programming, do you mean all of the time for everything? I'd argue you actually have a lot more code review in this case. You effectively have someone reviewing every line of code as it's written.

javaunsafe2019 4y ago

I’ll try to answer your questions: - the team size varied but in general we are quite small with around four developers - all within one time zone - all on senior level - not an answer but just for context: we didn’t had any prod incident within 3 years - we work fully remote - we do mob sessions most of the day - developing the e2e tests for the modules we wrote took not that much of time. Maybe 2-3 weeks for each product/module . Most of th me times it’s out something on s3 Herr and check API or DB there… most modules are trivial data transformations tbh but in the end most software i ever touched was…

rekahrv 4y ago
That sounds very interesting. Can you tell a bit more about those mob sessions? Do all 4 devs participate? Do you follow some structure?
- javaunsafe2019 4y ago
  Yes of course: those sessions happen online using teams or slack. The start of the day in the team is the standup in the morning where we quickly socialise and make a plan for the day and discuss important topics like triggered monitors, security finding or alike. When we made the plan we decide who starts and just start working all in one session. Most of the time that’s 3 devs in one meeting. We switch active roles mostly 2 or 3 times a day but it can also happen that one dev is coding the whole day if he feels like or the others don’t feel like. It’s very opportunistic so to say.
  - rekahrv 4y ago
    Thanks a lot, that's very insightful. I've worked in various environments, but this is super different from all of them. :-) How often do the non-coding participants comment on sth? Is it more like a continuous conversation? Or rather one person coding and the others occasionally chiming in? How long is such a mob session? I'm also wondering what kind of team setup makes such a model feasible and successful... By the way, congrats :-) 3 years without a prod incident sounds impressing, indeed. How long has the team been working together? You've mentioned that all devs are on senior level. Do you have some kind of hierarchy within the team?