11 November 2014
What It’s Like to Be a New Gaslight Developer
by Tim Mecklem
I came on as Gaslight’s newest developer in mid-October, but I first became familiar with the company when I attended QCMerge back in April 2013. Throughout the two-day conference, my understanding of Cincinnati’s tech community was transformed.
At the time, I was an iOS developer working in a large enterprise Java environment. My interest was waning. Heavy processes and politics were crowding out the things that made software development fun for me, and the quality of my work suffered as a result.
QCMerge pulled off the blinders. I learned there were other people in Cincinnati solving problems and delivering great software. Most weren’t developing in Java. It’s not that I believed this group of people didn’t exist before; I just didn’t know they existed here.
I learned about Gaslight Coffee and began attending on Fridays. There I encountered kind, entrepreneurial people discussing everything from Hadoop to backpacking. During the conversations at Gaslight coffee, I built up an understanding of the company, so when a developer spot opened up, my interest was both spontaneous and a long time coming.
What I Expected
These are some of the things I believed occurred at Gaslight before I joined (in no particular order):
- An uncompromising focus on quality
- Constant pairing (as an introvert, this terrified me)
- Test-driven development
- Foosball
- Nerf battles
- Continuous delivery on everything
- Well-defined projects and well-defined stories
- A shared consistent system of iterating and delivering
- Autonomous teams operating from the same playbook
What I’ve Seen
Gaslight as an organization is genuinely committed to quality. Pairing happens: not universally, but it seems to be the default. There’s an obsession with testing the right things and building just enough to solve the problem at hand. My first experiences in pairing showed me that I work with super smart people. I have a long way to go in becoming one with my tools, especially my text editor.
Gaslight consistently ships software. Feature cards move across the project wall. In my first month, I have committed code across two client projects, the Gaslight website and an internal project. Each change moved to production within a day of the work. When a project seems to be stuck, people are empowered to ask uncomfortable questions. When there is pressure to cut corners and ship software faster, the entire Gaslight team holds each other accountable.
Gaslighters honor the value of time. When a standup goes off-topic or a meeting runs long, individuals tag conversations for follow-up or vote with their feet and leave. For me, this has been the most difficult change. The practice of protecting time is uncommon, and it can be mistaken for rudeness. The team has recently explored ways of respecting people’s time while minimizing hurt feelings.
Gaslight is open and transparent to its employees. Financials, sales, forecasts, successes and failures are among the topics discussed among the team. If there’s a problem I can solve or an insight I can provide, I have implicit permission (and an expectation) to contribute.
Teams are autonomous. Decisions are made by the teams and communicated outward. My expectation that the teams operate from a general playbook was incorrect. People come at a problem from different angles, and there is a resistance at Gaslight to pick a solution once and stick with it forever. We share experiences about approaches to typical problems like authentication and testing, but the team owns the solution.
Yes foosball, no nerf. Foosball is a common way to unwind from a difficult problem or take a break from writing a blog post. I thought I was good at foosball until I played my first game at Gaslight. I’m well below .500 at this point with little hope of saving the season. Recreation has a home here, but it’s not the same place as where the work happens. No nerf darts come flying my way when I’m in the middle of writing a blog post, and that’s a good thing.