201–210 of 308 posts
I think pair programming is nice when cracking a tough nut of a problem or doing something highly safety-critical, but it's very taxing and there's no way I could do it all day long.
Earlier quoted context omitted.
Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtl…
Another helpful technique to good code reviews is to keep individual PRs small. Once a PR is over a few hundred lines, my eyes start to glaze over and by the end I'm just skimming. I've had great success with breaking larger changes into smaller PRs that get code-review-merged into an integration branch. Then the integration branch gets merged to your main branch once everything's done and verified.
Earlier quoted context omitted.
> Having multiple perspectives on design. Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design. If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from. If the solution isn't well-u…
Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
Earlier quoted context omitted.
In many organisations pairing is encouraged, but not mandated - it means that if developer is stuck with something they ask if someone is available to pair to unblock them. Usually they'll find a person who loves pairing and get things done. In rare cases the PM would tell a developer experienced in the domain, to stop what they are doing and help. That's not too bad provided the interrupted developer gets an extra t…
I think in every company, it is encouraged to help someone who is stuck. By "pairing", I mean that a ticket is assigned to a pair, who complete it as a pair. I've never seen a place where some tickets are done by pairs but others, solo. In my experience, if management isn't fully committed to the process of pairing, then they have a hard time understanding how pairing isn't wasting labor.
Earlier quoted context omitted.
It's good for a number of things: * Having multiple perspectives on design. * Having an extra pair of eyes to catch things one person might miss. * Being able to bounce ideas off each other. * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) * Onboarding (it works better at getting me up to speed than any docs ever have) * Motivation (i find it's kind of like having a gym buddy). *…
> Having multiple perspectives on design. Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.
1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
Earlier quoted context omitted.
If the code requires such a substantial rewrite after review, that would be indicative of serious communication problems on the team. In 20-odd years of reviewing code, I can't think of many instances where a review led to a substantial rewrite.
I don't know what "substantial" means but, say, in a 3 day long ticket, surely all sorts of issues found in review can easily force another day or so of work.
As I alluded to earlier, I've never encountered these sorts of problems in the healthy companies I've worked at (but I HAVE encountered them at unhealthy companies).
I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate. If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out. The biggest thing is you need a team that can trust and support each other.
> unless someone can convince me that specifically pairing is causing the burn out. For many people, socialising is energy-draining. Thus pair programming is extra tiring. While I do enjoy pair programming in some circumstances - for particularly tricky problems, or for mentoring - I would struggle (to the point that I would no longer like or be effective at my job) if I had to do it all-day every day. I can believe…
And another thing that's super important to talk about is the metric you mention:
> can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.
Productivity is an interesting thing in software. What is productivity? Is it writing code fast? Is that the most important thing you can do for your company/client?
Pairing and mobbing aren't necessarily performance-oriented, but more on transfer of knowledge. If you work in a company that just wants pure churn of new code without a large amount of knowledge transfer between members, then pairing is just a gimmick and not useful to that company. This is really a case of "use the right tool for the job" - pairing and mobbing won't always make sense if it conflicts with the goals and values of the company.
Earlier quoted context omitted.
Catching problems before things are written is definitely better and that's why it's often a good idea to mention how you intend to approach problems in your daily sync. If someone has concerns, they can bring it up. But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. In my experience the vast majority of tasks are…
> But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. Yes, without a doubt. > Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) Having paired for years, and soloed for years, I have found that t…
In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either
1) one person tapping out simple code which practically writes itself while the other lazily nods along.
2) One person solving something tricky which happens to be their area of expertise while the other stares blankly. Maybe at that point it would be useful to explain things in detail, but that can make development take much longer and if something like this requires rethinking halfway it can be quite taxing. In that case, I would prefer waiting until it's done and compiling the result as an annotated review. Which can be a great forum for asking questions.
Earlier quoted context omitted.
Pairing works great; as long as everyone is on the same "wavelength." That's absolutely vital , and has both good and bad sides. The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Mar…
Just a word about the Marine analogy in case some manager sees this and gets all excited: Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature. It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enorm…