[auslegung]

XP: open office, promiscuous pairing, very little remote work, 4-6 teammates, 2-3 30-minute breaks throughout the day to do whatever, regular lunch n learns, honest retrospectives, continuous deployment, powerful tools (Haskell, Elm, postgresql), daily company-wise “standup” with 70 people that averages 5-10 minutes, bi-monthly team get-togethers to play games and watch movies, regular lunches together, good code review practices, entire team constantly striving to improve.

Software engineers somewhat involved with most relevant business decisions. We are empowered to respectfully question decisions.

[scarface74]

Some of that sounds like a nightmare to me.

- open office - impossible to concentrate.

- constant pair programming - ughhh

- I have a family and friends outside of work. I’ve gone out of my way not to mix my work life and personal life. I have no desire to “play games” and “watch movies” with my coworkers. I come to work to work. I have friends who are former coworkers.

- regular lunches together - again, my lunch time is my time to get away from the office and recharge.

[thoman23]

Seconded! You could be my work best friend and years after we've moved on we could still enjoy not talking to each other.

[Aeolun]

All of those things are perfectly fine as long as they are optional.

[321yawaworht]

Sounds like a nightmare. I'm very social but despise the constant efforts to add extra social fluff (team lunches, movies, etc.), much rather prefer learning on my own and don't like "startup culture". I want to work how I want to, where I want to, whenever I want to, no ridiculous team ceremonies, no useless meetings. I just want to do an excellent job and go home early.

It's just work.

[winrid]

You looking for a job? DM me :)

[ww520]

> daily company-wise “standup” with 70 people that averages 5-10 minutes.

That sounds horrible. Even if half of the people have something to say, that's about 15 seconds per person. Beyond saying, hi, I'm here, I'm not sure what else can be accomplished. It sounds more like a daily pep talk by the leaders to the whole company.

[Huggernaut]

Standup doesn't require everyone to speak, no matter the size.

[jacques_chester]

Office standups where I work are of the form: New faces, helps, interestings and events. It's not the same as a team standup. You can get through both in 20 minutes flat.

[HandsAtTheReady]

+1 to XP.

Pairing removes many barriers to development:

* built-in code review

* knowledge sharing: removes silos

* helps avoids overengineering (few pairs have the same overengineering idea, so you tend to settle on a decent un-overengineered solution)

TDD, which I'm not fully convinced on, acts a clock for pairs: one person writes a test, one person writes the implementation, flip roles, repeat.

Other XP practices: everyone works at HEAD, deploys from HEAD, retrospectives.

Small features went from discussing with customer, to writing the implementation, tests, monitoring, and deploying it in half a day.

The disadvantages of ~full pairing: remote is harder to support, I missed getting into flow, fixed working hours.

[auslegung]

I agree that full pairing does make remote working harder, and the hours should be fixed, but we've been doing promiscuous pairing for a few months now to achieve 'beginner's mind' and that has been just as effective as 'flow', and more consistent to achieve. https://engineering.itpro.tv/2018/12/07/our-first-experiment...

[scarface74]

Alternatively:

- code reviews as part of a pull request system

- knowledge sharing - design sessions for features to make sure nothing was missed and architectural overviews with wiki documentation.

- avoid overengineering - again architectural “previews”.

[HandsAtTheReady]

I've been at places that do those too. But they weren't the environment that has enabled my best work.

In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.

[scarface74]

And it isn’t a context switch to have someone right next to you hovering while you are trying to develop? What context switch? You do a high level design before you start. Do you really need someone over your shoulder to make sure you can turn requirements into code?

[HandsAtTheReady]

> someone right next to you hovering while you are trying to develop

The pair is a collaboration. They develop together.

> Do you really need someone over your shoulder to make sure you can turn requirements into code?

I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.

I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.

[scarface74]

Do you really need to “develop together” to do most features? Most work that developers do isn’t writing complex leetCode algorithms. Are you really saying you aren’t capable of turning requirements into software design by yourself?

[jacques_chester]

My experience is that PRs quickly turn into a chokepoint which breeds delays and rework. Genuine bugs are rarely found, almost all the feedback is idiom and clarity -- valuable, but I can get the same feedback synchronously from a pair.

Note the reference to frequently committing to HEAD. That's not an accident, it encourages everyone to rebase frequently, keep changes small and to surface problems almost immediately. Whereas PRs quickly go stale and it turns into a game to try and get your PR in first.

[scarface74]

And having two developers pair programming instead of them both working on separate releasable features is more efficient?

[jacques_chester]

In my experience of the past 5 years: yes. Substantially better idea-to-production latency, given a high minimum standard for releaseability.

Little's Law is instructive. There are two ways to increase throughput in a system. One is to reduce latency. The other is to increase in-process inventory. They have very different dynamics.

[scarface74]

Most software development like everything else is a combination of inspiration and perspiration. How much time is spent in average day coming up with “ideas” versus just doing the work?

Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.

[jtms]

I enjoyed this sort of thing when I was a bit younger, but all the forced social stuff sounds horrible now

[dagoat]

While I'm glad it works for you, this set up would definitely not work for me.

I prefer less ceremony, remote when I like, no open office, etc etc

[cbanek]

Wow, a company wide standup with 70 people in 10 minutes? As someone who loves quick standups, please tell me how this worked!

[auslegung]

We tend to keep it to important stuff only that the entire company needs to hear. But this past week we had a standup where everyone was supposed to answer a question (I forget what) and we did it in 10-12 minutes. We've been practicing for a long time, many of us come prepared. But even when everyone was expected to say what they were doing that day, we still averaged 10-15 minutes with 70 people. Just come prepared, don't dilly-dally.

[hn_throwaway_99]

Guessing it's not really a "standup" where 70 people give status, but just that you discuss blockers/issues relevant to a team that big.

[mustardo]

I hate standups that are just status updates, that's what the board (Kanban or scrum) is for, if you don't have anything interesting or blockers to raise just say "pass" and save us all

[hitekker]

> We are empowered...

Good!

> ...to respectfully...

Sure.

> ... question decisions.

Uh, that's empowerment? The right to ask "respectful" questions about decisions that are already made? As everyone else is already pointing out, what you know may be separate from what you (want to) believe.

[auslegung]

I did not mean 'decision' as in 'we began implementing this last week', I meant it as in 'we've been discussing this, we like it, what do you think?'

What do you mean, 'As everyone else is already pointing out, what you know may be separate from what you (want to) believe.'?

[purplezooey]

true dat