Fog Creek

YOLO, So Don’t Just Code Solo*

Coding, Forever Alone?

Programming can be a lonely pursuit, and not just because 99% of the time we’re hacking away on our own. There’s a sense of loneliness that’s felt when you’re just learning to program and there’s no-one there to help you. It’s there when you’re struggling with a programming problem, regardless of how experienced you are. And it’s there when you’re reviewing your latest creation and you wonder if it’s really any good.

Yet working alone can be a big reason people got into development in the first place. Many are drawn to computers in general because they’re introverts, and that longing to work alone doesn’t necessarily fade even once you’ve joined the ranks of professional programmers. When you’re faced with incompetence, unfair expectations or general mismanagement of a software project, you often dream of being back in your room, coding alone. It’s easy to understand the appeal. Coding alone means complete control of the code you write. The architecture, code style, and technology choices are all in your own hands. And after all, hell is other people’s code. Or something like that.


“There’s no panopticon-like pressure to grind us programming rogues honest”


But, working alone is a double-edged sword. Have you ever reviewed the code of someone who had no expectation of someone else seeing it? When left to our own devices it’s all too easy to take shortcuts. Soon our code is a mess of unexplained choices and weird hacks around problems long-forgotten. Or, maybe we go the other way – gilding the lily with code optimizations that aren’t worth the time spent agonizing over them.

When we work alone there aren’t the healthy checks and balances that can keep us from making poor choices. There’s no panopticon-like pressure to grind us programming rogues honest. Or at the very least, there’s no one to bounce ideas off and point out our pending errors.

It’s a pipe dream for most anyway. Modern software development often demands multiple people. The size and complexity of products can be more than any one person could, or should, handle. And anyone with real programming experience will tell you that in order to master the craft, you need “to sit at the feet of great coders“. By doing this, you see other approaches, you’re exposed to different ways of tackling problems and other code solutions. It’s when you really learn the most.

Making Collaborative Editing ‘Heavenly’

That’s why collaboration was a launch feature in Gomix. It would be reasonable to ask why we would prioritize and spend all that time working on something that you’re only going to use occasionally. Well, it’s because when we reviewed existing solutions we became convinced that a big part of why even those sold on the merits of collaborating on code still end up working solo, was because of the lack of suitable tools.

There are plenty of options for working on code together, it’s just that they’re often specifically aimed at pair programming or code reviews. Beyond that, when you just want to program together, you’re back to more generic solutions. Like a clunky screen share where you always seem to spend your time finding how to select the right frickin’ screen to show. Or you’re squinting at some grainy, blocky mess. And DVCS is often accompanied by a lot of process and structure unnecessary in smaller projects.


“If hell really is other people’s code, then collaborative editing needs to be heavenly”


So, like with other product decisions, we established a number of product principles to guide our approach. For us, if hell really is other people’s code, then collaborative editing needs to be heavenly if anyone’s going to use it. To deliver that, we set out to create an experience that:

  • Is enjoyable – providing immediate feedback to the user in a low friction way, that makes working in a team seamless, and using Gomix engaging and fun.
  • ‘Just works’ – So for us, this meant that we didn’t try to reproduce every part of other collaborative coding products or solve every edge-case. We just focused on the parts we thought mattered, as determined by our own experience and a heavy dose of user feedback and data analysis.
  • Is a fluid experience – Specifically, when it came to real-time coding we wanted to allow you to develop ideas interactively, building momentum as a team, whilst reducing the need for upfront planning.
  • Is safe and reliable – So you’re reassured and actually welcome making changes, rather than left cowering at the prospect of dealing with dreaded merge conflicts.

Ultimately, what we want to encourage is a messier, but more fun, more human software development process. One where you’re always in control – so you can come together, break apart, and rapidly come back together again.

It starts with an Invite

So in Gomix you can collaborate on projects together, either in real-time, like in a Google Doc where you see other people’s edits as they make them. Or, you can work asynchronously – working on a project together, but not necessarily at the same time.

Regardless of the way you work, they’re both kicked-off in the same way: with the ‘Invite’ button. Click that, and share your join link with someone.

We’ve found this can be a great way to work with others, to help teach and mentor, to live code, or just hack on products in a group. We’d love for you to tell us how close we’ve gotten so far to our vision. Let us know on the forum.

*Thanks for the title inspiration Microsoft!