I’m on a plane, traveling back from RailsConf 2019 where I was one of the keynote speakers. My head is full of thoughts and reflections on my experiences before, during, and after the talk.
I’ve given a few talks before, including several at previous RailsConfs, but this time was… different, somehow.
I’d like to share my experiences with you, in the hope that you’ll learn something of value along the way.
For the last 2 years, I’ve run Dev Empathy Book Club, and the site hasn’t changed much. I’ve tried to keep it low-effort so I can focus on the community and the content we’re producing. One casualty of this was that the site, while simple, wasn’t very performant. (Google’s PageSpeed Insights gave it a very low score of 30/100 on mobile.)
I recently began working at Cloudinary, and I realized it’s pretty embarrassing that, as an employee of a company whose product is all about optimizing media on the web, I have a personal site that does a terrible job of it.
I was just a few months out of the Flatiron School, had gotten my bearings in the codebase at my first job, and was starting to take on more responsibility. I was sitting with a product manager—let’s call her Sierra—trying to explain the technical impact of a product idea she had proposed. And I was frustrated.
No matter which way I explained it, she just kept getting confused. Why couldn’t she understand that making these changes would drastically increase response time on a critical endpoint? It was a simple workflow involving 2 microservices and a NoSQL database, and she didn’t even have to understand the details, just how they were connected together on a high level.
At some point, I realized: No one had ever given Sierra any level of technical explanation of the system whose development she was supposed to guide every day. Instead of going further with the conversation, I asked, “Why don’t we set up a meeting just to describe the basic outline of the system? Nothing overly detailed, just enough to allow us to have a conversation about how product concepts will impact the real-life product when they’re translated into code.”
Why do software projects fail?
This question is difficult to answer precisely because there isn’t a single answer. Sometimes the blame falls to technical debt which hamstrings scalability, the ability to ship new features, or the ability to respond to market demands. Other times it’s the lack of business model, which sinks the entire company. In certain situations, various parts of the organization not seeing eye-to-eye is the culprit; the lack of shared vision causes sales to over-promise, engineering to develop the wrong things, or marketing to pursue the wrong strategy.
The causes are many and varied, yet somehow as engineers we focus a lot on “Good Code” (however we choose to define it), which fails to address most of these problems. Why?
I started the 8 Crazy Blog Posts Challenge as a way to stretch myself and get back in the habit of writing. As in writing software, blogging regularly is difficult when there’s no pressure to ship.
It certainly got me to release more material than has been my recent practice, but it’s worth analyzing the process, the outcomes, and the cost.
People come to tech conferences for many reasons. They want to hear about new ideas and technologies, to be inspired with the latest and greatest of what the programming community has to offer.
But once people are actually at a conference, especially a larger conference, the number of things to do and to absorb can be overwhelming. There are talks, maybe even multiple talks at once, there’s the hallway track, vendor booths, and of course the great big world outside where people escape when they want a break. Everyone competes for attention, offering excitement, swag, fun hacking activities, and/or the alluring prospect of job opportunities.
Then there’s the new practice of posting talks online. This opens up talks to new audiences who couldn’t make it, which is fantastic. It also means that if the community loves a talk, it could be see by thousands more people than were at the conference! The downside is that conference attendees may be more likely to skip talks because they’re all online later anyway, meaning that speakers lose the opportunity to build off the speaker-audience interaction.
What’s a speaker to do?
There’s a great Kent Beck quote which should be etched on the mind of every serious programmer:
for each desired change, make the change easy (warning: this may be hard), then make the easy change
— Kent Beck (@KentBeck) September 25, 2012
The immediate context of the quote is changing code. But truth be told, it actually applies to a whole host of problems on multiple levels. It can help us fundamentally alter our practices, our teams, and all elements of the quality of our software.
Let’s understand how and why.
As a programmer, I’m privileged to be part of a field where learning is thought of as part of my job. Many enlightened companies specifically dedicate time during the workweek for exploration and side projects. Companies pay for their employees to attend conferences, buy books, and sponsor subscriptions to online learning resources.
There’s a wealth of information I can access, and more is being created constantly than I could ever hope to consume. Prioritization is key. What should take precedence in my learning? What will contribute most to my professional development as a programmer?
There are many approaches, ranging from “Follow your heart and specialize,” all the way to “Learn a bit of everything.” Some emphasize learning a full stack of technologies, others think you should just get really good with the tools you use every day.
My approach falls somewhere in the middle, and I’d like to share it with you. It starts with a bit of wisdom imparted over 1,600 years ago.
There are plenty of ways to write a FizzBuzz program in any language, particularly Ruby with its TIMTOWTDI philosophy. Beyond the naive implementation, you can write it in one line, using only Procs, etc. Yet this still might be the oddest, most inscrutable implementation you’ll ever see:
1
| |
Go ahead, paste it into irb and check that it works. I’ll wait here.
Wait, how does that work? Welcome to the wonderful world of BrainRuby. Check out the explanatory video, or read on.
If you’re responsible for an API, you may have noticed that API documentation is painful to keep in sync with your code. A tremendous amount of cognitive overhead is added by having to remember everything you’ve documented and update it any time a change happens.
Also, you probably fail a lot. And you’re not alone! Most teams fail miserably at the task of documentation upkeep. It reaches the point where you have to wonder:
Most of the material you’ll find centers around practices that will help the team prioritize documentation, organize it better, etc. I think that’s a load of hooey (pardon my French). Documentation is really hard because we haven’t figured out how to automatically check that it’s accurate, and people can’t reasonably be expected to keep it all in our heads.
Until now.