I think most anyone who has been in some sort of development community for a fair amount of time has least heard of the idea of pair programming.
If not, Wikipedia defines it as:
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
The advantage to this is that you’ve got two people working on a single component of an application which should ideally result in more robust code because you’re actively having your code reviewed, you have a person able to think about the code being written within the larger context of the application in order to foresee problems, and you have a person that’s actively developing the solution for the given task (be it a bug, feature request, or something else).
And sure, we’ve all been told that it’s a good idea to find a person or a community that has more experience than us so that we may learn from them; however, I don’t think we hear – at least not often enough – that it’s also beneficial to find people of equivalent levels of experience who also think differently about problem solving.
It’s Not Pair Programming, But Peer Discussions (Or Something Like That)
I think it’s fair to say that developers are some of the most opinionated people on the planet (and I’m not saying I’m exempt from this!).
We know what we like, what we don’t like, and we’re not afraid to challenge or straight up argue with someone else’s opinion if it doesn’t jive with out own. I’m not saying that I necessarily agree with this behavior, but it’s something that’s definitely prominent within the software development community.
To be honest, this is the kind of stuff that often turns a lot of people off, and why shouldn’t it? Essentially, we’re prioritizing our own views over another person’s and not doing such a good job of hearing the other side.
But what if we were to flip that around? By that, I mean what if we were to actively pitch our opinion on something to a fellow developer – to invite a contrasting opinion – and then actually, truly weigh their opinion against our own.
I think this naturally happens on places like GitHub, but also inviting this from your peers in something that think is beneficial.
1. You Discover Other Tools
When it comes to my set of development tools, I’m often seeking out a handful of the best things to use – the ideal set of software for which I can get my stuff done – so that I can claim a definitive toolbox.
Despite the fact that I know software is an evolving industry, and I know that new things will be out to replace things I’m currently using, I’m still able to convince myself that I’ve got my golden set of tools.
But asking what other developers are finding useful and why (“okay, so convince me why I should be using [said tool].”) can be really beneficial.
Yeah, you may have to learn something new, but that’s the nature of the beast. Plus, if said knew thing ends up being better than what you’re currently using, you win.
2. You Find Better Techniques
Despite the fact that certain paradigms have been present and haven’t changed for decades – such as object-oriented programming – we’re constantly finding new ways or new approaches to leveraging said paradigm to build better software.
We’ve got things like unit testing, inversion of control, design patterns, dependency injection, and so on. Although some of these things have terms that are more complicated than the idea that they actually embody (I digress on that for now…), it’s always good to learn the new techniques that are coming out.
Personally speaking, do I always use them? No. But knowing that they exist and how to leverage them really comes in handy in future development when I stumble into a problem and think “Hey, maybe [said technique /pattern/strategy] would work well here.”
3. You Think Outside of Your Box
And I do mean that you learn to think outside of your box. After all, if I said the box, then that’d imply that there’s a single, definitive box – which there isn’t – that we all share – which we don’t – for how we solve our set of problems – which are often different.
Instead, what happens is that we get stuck in some sort of fixation of how we go about writing our code, approaching problem solving, and, as we mentioned, how we go about leveraging the tools that we find.
We create the box in which we work.
Hearing how other people approach problem solving, software development, and so on helps you to see the same thing from a different perspective, and this can go a long way in helping you to become a better developer.
But There’s a Gotcha…
At least, I think there’s a gotcha.
Specifically, actively seeking out the thoughts of others this presumes you have a certain level of experience. For example, a beginner, front-end developer isn’t likely to have an in-depth discussion about SCSS or LESS with someone who’s been working with those tools for a significant amount of time.
At least, not in this context. That’s more of a mentor/mentee relationship.
In this case, I’m talking about two (or more) people who are established in an area discussing the finer nuances of their preferred set of practices, and then challenging one another.
Of course, we need some sort of cool buzzword to name this since pair programming won’t do it.
But seriously, it can be challenging for those who are extremely opinionated, but in my experience the advantages far outweigh any other aspect of doing this. So why not?