Hacker News new | comments | show | ask | jobs | submit login

Dinosaur here. I think that these social programming ideas are nuts. At my first job writing production software, we did three things. We brainstormed. We wrote and critiqued designs. We coded (which includes writing unit tests and debugging).

There was basically no open source. If we needed something, we found it in libc, or wrote it, and if it was good, others in the company used it too.

It was incredibly productive and satisfying.

At my current company, I find much less up-front design. We don't do pair programming, so the collaboration tends to be at the end of the process, during code review. And good god, there is no end to the code reviews. I don't understand how anyone can do both good code reviews, and good software development. There isn't enough time or attention for both. I notice that when we're getting toward the end of a release, there is all sorts of shorthand in the code reviews. Reviews like "looks good to me", "nothing jumps out at me", "I only did a cursory scan", etc. This is shorthand for "our process requires code review, so I'm claiming that I've done a code review, but really I haven't." So we end up with no collaborative design at times. And of course, when code review does work, we're finding design flaws late.

There is far less NIH these days, and that's a good thing. There are high quality projects out there, and you can grab one, evaluate it, and save yourself a lot of time. This saves time on building things that are tangential to whatever it is you are trying to do.

But reuse can also go wrong in a few ways. You may spend a lot of time wading through crap. You may try something out, commit to it, and then discover the flaws only much later. You can spend a lot of time finding an open source solution to a problem, learn the API, tweak the internals to improve the fit, and then in hindsight realize that you would have been better off just writing the thing yourself. Frameworks are especially prone to this problem. Yes, they do a lot of things for you, but you have to drink so much kool aid to get the benefit. And then there is inertia, and you tend to fight the framework once you stray from the exact approved way in which it's supposed to be used. Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.

What I find is that with all this browsing, and downloading, and trying things out, and making things fit, and reading code, and fixing trivial things demanded by the process, and in general, just doing things in the modern way -- there is just no time for thinking about things hard, forming an idea, and taking the time to express it cleanly.

I won't even get into the latest, highly interactive project management cults. Daily scrums are the modern equivalent of TPS reports.

I haven't tried pair programming and I never will. I'll leave a job if asked to pair program. I'll leave the profession if necessary and program as a hobby. For me, the reason I put up with all the nonsense is those few hours a week when I can actually get a nice problem to work on, think about it, come up with a solution, make it simpler, simpler, simpler, code it, make it simpler some more, and make it fast. Put on the music, get into the zone, and think and hack. Seems much harder to do in recent years.

I wonder if the type of work you are doing has anything to do with it. Web projects are typically mostly about UX design, architecture, security, and scalability. Very few of these tasks are "unsolved" -- you can do pretty much anything you want to on the Web with some code reuse and good architecture. Therefore, the knowledge sharing of pair programming might work here, since the main goal of a web development project is to have everybody on the same page in terms of best practices, architecture, etc.

Now, if you're writing novel code, new algorithms, working with big data, or writing performance or security critical software, then I can see how the heads-down approach might be more effective. For these projects, maybe understanding the whole system is less critical than, say, programming your component to be 100% optimized.

I do work on writing novel code, that is multithreaded, and sensitive to performance. Maybe that is better suited to solo development. That's a separate issue from personality. Some people seem to thrive with more collaborative forms of development, some wither. I'm struck by that distinction every time there is an HN discussion of pair programming.

Yes, exactly. Unfortunately, every so often you get these companies that take on a process as "part of their core culture", when culture should be about principle, not process.

By taking a practice as a core value, they are implicitly stating that it is the One True Way to do things, which means that anyone NOT doing it the One True Way is doing it wrong (to the point that they refuse to hire anyone unwilling to toe the line). I wonder how these people would feel entering a company whose One True Way is waterfall development? Because up until a decade and a half ago, that WAS the One True Way.

OP here.

I think this is a good point. There's definitely a risk of dogmatism when we start defining ourselves through a certain process.

I wanted to use the post to explore how a process like pairing influences company culture. I don't mean to imply that the process IS the culture.

I think it's fine, and probably very helpful, for development teams to be opinionated about process. But opinionated is not the same thing as dogmatic.

I mentioned this in a reply to comment on our site, but we also worry a little bit about creating a monoculture and groupthink. We try to fight this by leaving room every week for people to spike things out on their own in open dev time: https://www.braintreepayments.com/braintrust/walking-the-tal...

One thing you should definitely be careful of (not sure if you do this or not) is requiring adherence to a process that demonstrably doesn't work for a sufficiently large percentage of the population. As another poster pointed out, they select against people who don't like to pair program, which cuts out a large percentage of the (good) developer population, thus fostering monoculture.

Agreed. The "open dev time" idea is attractive, and I can imagine developers getting excited about it, (or at least developers who enjoy doing side projects). But it doesn't seem to address kstenerud's point.

In our interview process, we want developers who like writing software, and want to improve. Asking about side projects, software topics they're researching on their own, languages they're playing with, seems to be a useful thing to focus on. Or at least, I tend to like candidates with good answers to those questions. That's a monoculture I think I'd actually like.

This hits on a latent suspicion of mine, which is that at its core pair programming is really just a way to make tedious programming jobs less tedious. Granted, I say that as someone who also spends most his time working on complex multithreaded performance-critical code and development of new algorithms, and I'm partial enough to that kind of work to have some uncharitable bias.

I tend to think that design by committee, even with a committee of two, reliably produces inferior results. So when really novel work is necessary a much better way to put two people on the same task is to have them both take a crack at it independently and then come back together to see what works best. Sometimes competition is the best form of collaboration.

Well, I'm glad that you find writing algorithms not tedious, because I surely don't want to be doing that! Architecture and good software tooling are what really tickle my fancy. It's good there are people with interests along the levels of abstraction.

I agree, I dislike "design by committee". However, sometimes you get to work with those magical, rare people who are both seasoned architecture gurus and have very good social and speaking skills. Working with these kinds of people is an absolute joy -- I will learn more in an hour of watching a skilled developer program than I will from a month of reading online material.

OP here. I strongly disagree with the assertion that pair programming isn't helpful in sensitive or mission critical applications.

Braintree's core product is a payment processing gateway. If we go down, get hacked, or introduce serious bugs, our customers can't run their businesses. As I said in the article, we pair for almost everything, and we find it helps us write great software that stays up and stays secure.

I didn't mean to actually lay out categories where one style is more effective than another -- I don't have that experience. I was simply proposing a framework to think about the differences between development teams and how that might affect the effectiveness of pair programming. Obviously, "web" projects have significant security and performance requirements, which could definitely benefit from pair programming in your context.

I should have focused on the distinction between the size of companies -- that seems like a more accurate framework. I suppose I meant "performance" in the sense of low-level algorithm efficiency rather than high-level scalability and reliability. A misuse of the term on my part.

Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.

Good grief, yes.

I've observed this not just in coding, but across the board. For example, the young accountant who accepted verbatim and as authoritative every number that came out of the system.

The point of a lot of those reports was really to raise questions, not to provide pat answers.

Writ large, a lot of this "social" endeavor seems, one way or another, to mask a shallow grasp of the material at hand.

And, personally, having experienced how distracting it is for me and counter-productive vis à vis deep thought, I can't but consider it also causative.

I do collaborate. Very well. But not "24/7" while trying to avoid spilling my ramen noodles on the other person's lap.

Thanks for writing this. Your post conveys my own take on this particular tech trend/fascination.

I love to collaborate - at the whiteboard or during design review. When it's time to code, however, I'd much prefer to be left to my own keyboard.

Most of your response seems to be an off-topic rant against frameworks and new technology, and you're certainly not wrong on those points. But what I find interesting is the on-topic portion, where you basically say this:

"Social programming ideas are nuts." and then you follow that with "My company does collaboration wrong by saving it all until the very end of a project where it's too late."

The piece directly addresses this by stating that pair programming is trading a short-term cost (doubling up programmer resources on the project) for a long-term gain (far fewer errors, fixes and less review and deeper developer knowledge).

If pair programming meant you didn't have such painful, never-ending code reviews, would you still think it's such a horrible idea?

Yes, collaboration is necessary, and yes, my company is doing it wrong. My preference would be to hash out a design earlier, before there is any code, rather than after the fact. Once you have code, you have wasted time, and it is often difficult to separate out ideas from implementation.

And yes, for me personally, pair programming is a horrible idea no matter what. Pair programming vs. code reviews is a false choice. Ideal for me is design up front, away from the keyboard, and then everyone goes off, by themselves, and does their thing. Or in pairs, if that works for both of them.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact