Hacker News Reader

Comment by javaunsafe2019 | Hacker News Reader

javaunsafe2019

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!

View on HN

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

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.

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.

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?

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…

That sounds very interesting.

Can you tell a bit more about those mob sessions? Do all 4 devs participate? Do you follow some structure?

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.

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?

Thanks.

Hm, the team is working together for maybe 2 years like this. Those sessions go the whole day with a few breaks (lunch, coffee, bathroom).

No hierarchy and we are all involved during the sessions but if you have a bad day it’s ok to be more passive…

We were told that we are quiet performant in comparison to other teams but that is maybe also due to the fact that we are all seniors and trying to be pragmatic with our decisions

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.

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

Pair programming solves this.

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

Reply on news.ycombinator.com