Working Together
In the book Time Enough for Love, Robert Heinlein wrote, "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." This quote embodies everyone who operates a small business or works at a startup. Work is a team sport, not an individual one. Ultimately, I believe we should never underestimate what the power of a handful of individuals can achieve when they work together with a common goal. There are three key areas I believe in when working with others: focus, quality, and empathy.
Quality
When I start a project, quality is not an afterthought, and I never view it as tech debt. This means that I start with implementing linters on the front and back end of the application. This includes Rubocop, ESLint, and Stylelint for Ruby on Rails. Coding with community standards is more important to me than working in isolation. As for databases, I believe in being overly critical on indexes, foreign keys, and column constraints beyond the ORM. I never trust ORM validators as the only line of defense for ensuring accurate data. Beyond these style standards I always write tests and I utilize coverage metrics from the start, including both unit and integration tests. If these metrics are not adhered to the build never passes. This is where automation comes in. I am a huge fan of tools like CodeClimate that provide an overall GPA for my code, and I work to stay on the honor roll. I have worked with both CircleCI and Travis and I am a fan of both GitLab and Heroku pipelines. The more the robots can do here the better. I have worked in a number of environments, but I will stand behind these simple principles and consistencies for organizations who desire to rapidly and regularly deploy to production.
Empathy
When I think of empathy I think of family and how this applies to my work. I want to work in an environment where feelings matter and everyone gets a chance to speak. Connections between co-workers don't stop at the cube farm walls or in Slack rooms because extended work families matter, too. Wives, husbands, children, and pets are all part of the melting pot, and each one matters. I don't care how much fancy shit like ping pong tables, arcade machines, and espresso makers you have scattered around the office. If you do not have connections, your culture has failed. Beyond the family unit, the days of sitting alone in the basement clinging to your red stapler and being afraid of management and your peers are dead. Coding and design are a collaborative team sport and each department should work together with a common goal. Think of water here: everything from client requirements to negotiating tech debt should be a fluid, effortless experience. All teams matter! Past team dynamics, successful cultures have friendly code reviews, mentoring, and most importantly a culture of learning. Knowledge is shared across every level and department, and silos are viewed as destructive to long-term success. Finally, learning never stops and sharing knowledge rises all boats. Together we win, divided we fall.
Focus
The "Agile Manifesto" states the following four ideals. First, individuals and interactions over processes and tools. Second, working software over comprehensive documentation. Third, customer collaboration over contract negotiation. Fourth, responding to change over following a plan. I would also like to add the following books in their entirety to this list, Remote and Rework from the folks who run Basecamp. Combining all of this information yields both a desirable culture and a work–life balance. It applies to what engineering processes are required to get the job done day in and day out. Over the course of my career, I have worked in Excel spreadsheets, Waterfall, Kanban, and Scrum. Each one has pros and cons, and trust me when I say processes are not black and white, and people must matter more than process. I tend to be a fan of less process, and the processes that are implemented should be constructive. If you want to have a job culture with Google-style Fridays, processes must be efficient and teams must have a consensus on design, coding style, and standards.
If you are still reading this, and you are not a stalker, please reach out to me to chat about working together. I am an open connector on LinkedIn and regularly help fellow engineers land the new gig of their dreams. I also work to help fellow entrepreneurs, and I am always working on a side hustle. If I had to add one more item to my life’s Venn diagram it would be the fact I am a remote working advocate and have been a digital nomad since 2011. When talking to fellow entrepreneurs I always recommend starting remote first and keeping it that way. Trust me when I say that if you only hire local and you complain about not finding anyone to hire you are causing your own resource problem. If you evolve to modern times, you will be able to tap into a wealth of diverse resources across our great nation without the big box expense. I have had hands on the keys for over a decade and there is nothing you do face to face that cannot be done remotely. Let me clarify: I am not advocating for lonely work islands. Whether you are bolting on remote resources to gain efficiencies, or you're remote first, or you are the only one on the remote island, the same logic of connection applies. The moral of this story is I find my success and the success of my peers, including their happiness, tied to Quality, Empathy, and Focus. Let's work together! How can I help you?