I have no idea what you did at your job last week. I couldn't find out if I wanted to.
But if you were curious enough about it, you could find out exactly what I did, Monday through Friday.
For instance, on August 31, 2016, I made 3 commits to various branches on Reaction Commerce's main code repsository. Two of them passed their tests. One failed, and I had to go back and fix the error. A few months ago, I spent my day fixing linting issues for our upcoming release, and today, I fixed some i18n translation issues related to our platform.
You didn't need me to tell you that, though. That's because everything I do, every single day, is visible for the world to see on GitHub.
We do have a few private branches, which I work on occasionally, but other than that, the bulk of my work (along with the work of all the other developers at Reaction) is right there for you to see.
It's intimidating. It's gratifying. It's fun. It's terrifying.
This is the first time I've worked for an open organization. Prior to Reaction Commerce, I was at Media Temple and TTPM, both closed source software companies. It's been a challenge, but thanks to the transparent, connected, and collaborative nature of open source, I've become a better developer and communicator—and I'm learning a lot, each and every day.
Here are some of the unique lessons I've taken away from working in open source full-time.
Absolute transparency is absolute
You can tell a lot about me from my GitHub activity.
For example, given the times of my code commits, you might notice that I'm a night owl. You might also notice that, for two weeks, I made no contributions to the project because I was on vacation. You can see my biggest coding days, which I'm proud of, and you might think, "That's nothing!" My livelihood is yours to judge, all without my input.
It's a scary thought. It's also scary to think that any prospective employer down the line has a fully documented day-to-day rundown of everything I do.
In a closed environment, much of what happens goes under the radar. It's discussed in small teams, or not at all, and as long as it works, it's never questioned.
But in an open environment, I can't hot-fix code. If one line of code needs to be changed, it's my duty to inform the community and tell them what I'm doing. I make an issue, create a branch, make a pull request, then contact a team member to merge it. Everything we do affects thousands of people everyday. Every variable changed could break a store.
Learning to be completely transparent has been a challenge, but I believe it has made me a better developer in documenting our ideas and forcing myself to see what I'm doing. A couple months ago, I made a pull request from a branch I'd accidentally made off the wrong branch. It's a simple mistake every developer makes, yet my mistake will live on in the Reaction codebase for all to see. I had to explain, publicly, exactly why I was killing one branch to make the same changes in another. Oy vey!
There's also the matter of unrestrained—and at times, undefendable—visibility of my working habits and contributions. In a closed environment, my direct managers will usually be the only people who have a grasp on my day-to-day activities. If anyone else needs to know, I have a chance to explain what I'm doing. But in an open environment, it's all out there.
24/7 availability is rewarding and frustrating
In a closed environment, you'll rarely need to help anyone with your software's codebase, because they just don't have access to it. Issues get fixed internally during business hours.
But at Reaction, our codebase is accessible by everyone, everywhere, and so is our public chat room. Because we are open 24/7, the world can ask us a question at any time, and we need to answer. Some days, we help get a shop back online when something goes wrong. Other days, we spend a couple hours helping someone install Reaction for the first time.
Having someone around who you know is going to respond is awesome. But 24/7 connectivity can be disruptive when you're expected to answer inquiries quickly, especially when you're in the flow of things. Still, the product you're preoccupied with trying to build is ultimately for the same people you're helping, so you kind of have to interrupt yourself. Plus, I'd say our community has gotten to know our habits well enough that they know our availability, and so they curb their expectations accordingly.
It's just nice to see the number of times people say, "Thank you!" in our chatrooms. I've been on the other side of things, where someone hasn't always been there, so I can really relate with how our contributors feel.
Collaboration leads to discovery
In a closed environment, you have a team you work with, and that team rarely changes. Decisions, failures, triumphs are all shared between this team, and usually that's the end of it. I think often about this great quote from our very own Sara Hicks: "Open source development might just be the peak collaborative experience."
We have an amazing core team here at Reaction. But in reality, my coworkers are literally every single developer who has ever contributed to Reaction. Whether you fixed a typo (which, by the way, was my first ever contribution, long before I was hired) or contributed an entire dashboard feature, each single contribution has made Reaction what it is today.
Living outside your comfort zone and receiving constant feedback from users across hundreds of countries and backgrounds has been amazing. You learn ways of doing things that are completely different from how you usually work—but still lead to the same result. At the same time, having so many cooks in the kitchen causes great contemplation when we want to make changes to our product. It may seem like the wild west, but we spend a lot of time debating how we should be doing things best. Collaboration makes you think far ahead into the future, which is important for something as ever-changing as JavaScript.
We've changed programming languages and environments several times over the year. Now, we're converting our UI codebase from Blaze templates to React. I'm sure this is the case for thousands of our developers, but at the time, I didn't know React. I learned along the way, first making updates to a few of my colleague Mike Murray's existing components, and then, with each new release, I made a few of my own. Now that I have a few months experience under my belt, I feel comfortable helping other people outside of our codebase.
These are huge changes. Working on a closed source platform, they are choices that can be easily made and decided upon between a team of developers. But in an open organization, these are huge decisions that will affect thousands and thousands of people. It puts a pause on drastic decisions. Switching to React means we have to trust that our community will know and want to work with React. We have to explain why we chose React over Angular, LESS over SASS, Mocha over Jasmine, and two-space over four-space tabs. This can be challenging to productivity, especially when we're under a deadline, but once we do reach an agreement, we can feel confident that we have the buy-in of our entire community.
Conclusion
I'd never rule out going back to anything closed source (not that I plan on leaving Reaction!), but working full-time in open source has opened my eyes to a whole new side of things that I've truly enjoyed. Absolute transparency has made me a better planner and developer. Having to express my ideas to the world before, during, and after implementing them changes the way I do things. The 24/7 availability is both engrossing and also overwhelming. And finally, working with not just the core team, but our GitHub community, pushes me to make decisions together and grow as a developer.
I look forward to facing lots of new faces and contributors to our open source community, and lots more challenges as well.
1 Comment