Re:Ask HN: Which companies have the best engineering culture?
by handbanana on Friday June 08, 2018 @01:38PM
(#17267828)
I did think they were pair programming oriented, how unfortunate.
Are you tied at the hip to your pair? Can you come into work, take lunch, leave work, vacation, and go to the bathroom on an entirely different schedule to your pair? Essentially, does pairing erode autonomy and freedom to a degree?
The rest doesn't sound that bad, but also nothing spectacular
Re:Ask HN: Which companies have the best engineering culture?
by sidcool on Friday June 08, 2018 @01:42PM
(#17267866)
Mostly yes, pairing is encouraged. But individual preference is respected. Pairing does tend to be highly collaborative, though I won't put it the way you have. Pairing obviates code reviews. It's not applicable everywhere, but wherever it is, the benefits are very obvious and apparent.
What would spectacular look like?
Re:Ask HN: Which companies have the best engineering culture?
by pc86 on Friday June 08, 2018 @02:27PM
(#17268367)
I'm sorry but you didn't actually answer handbanana's question.
Is your schedule dictated in any way by your pair? If your pair likes to take lunch at 11 and you like to take it at 1 is that a Big Deal in the sense that you'll be less productive than another pair? How much is the typical "one person talking/thinking, one person typing" and how much is just two people programming next to each other?
Re:Ask HN: Which companies have the best engineering culture?
by sidcool on Friday June 08, 2018 @03:20PM
(#17268828)
Let me try again. Schedule is influenced by the pair. There are times when schedules conflict. They are resolved between the pair. There are no rules around it. It's more two people thinking and programming. If necessary the pair separates for some thinking time and reconnect to discuss.
Most of the day goes into pair programming on the planned stories for the sprint. Usually TDD is preferred, but the pair decides their style of working. Tests are a must. Usually there's a build monitor to track test failures.
Tech huddles are called in case of important technical decisions or if there are hurdles. Stories start with a Kick-off to dissect all aspects of it in detail. These are attended by business analyst, quality analyst, tech lead and the pair.
Dev box testing helps catch defects early. So on and so forth. There are sometimes evening meetings with clients depending on time zones, availability etc. Features are demoed in this meeting to get feedback even before they are deployed to Dev or Staging.
Overall the org is unstructured but empowering. There's very little hierarchy.