Changing the language

The other day I tweeted this:

Tweet by @vmbrasseur: "If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers."
Tweet by @vmbrasseur: “If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers.”

This tweet is a necessarily brief exclamation of something which has been on my mind a lot lately and warrants a larger post. In summary: The words we use matter.

It’s probably safe to assume that nearly everyone reading this is involved with creating software. Even if you’re not, you’re undoubtedly aware that software development is a complex process composed of many moving parts. While it’s possible to create software on your own, it usually works much better when we collaborate to build each of the parts.

Despite recent “full stack” trends, none of us can be specialists in every facet of the software development and creation process (nor should we try). Many different skills are required for the process to work smoothly:

  • Before writing a single line of code, product management, user experience, and user interface design are necessary to make sure you’re creating software which is valuable and useful to the end user.
  • The crafting of the deliverable software product involves front end coders, back end coders, security analysts, database administrators, and documentarians. It may also require more specialised roles such as mobile coder or data scientist.
  • Before the software can be delivered, quality assurance and product management must confirm that the software not only meets the needs of the end user but also that it works as expected (or at all).
  • The actual delivery of the software is the responsibility of system administrators, operations, and devops. They, along with DBAs and customer service representatives, also help to ensure the software remains available.
  • As the software progresses through its life cycle, customer service receives additional support and outreach assistance from marketing, sales, and community management.

This is the software development process. This is what it requires. A true “full stack” software developer would be skilled in all of these roles (which is why the very concept of “full stack” is laughable). Yet lately when we speak of software developer we mean only those who create the code. As we see above, programming is only a portion of the process, just one of those many moving parts. The term as currently used disregards the myriad other roles required to develop a successful piece of software.

It’s unclear what nudged our language to shift such that “software developer” has come to exclude the majority of roles responsible for successful software development. It’s not as though there is any shame in the title of “programmer.” It’s a descriptive title but more importantly it’s one with decades of rich history behind it. By using “software developer” instead we’re not only excluding people, we’re turning our back on this history and everything which it affords us.

Why is this important?

Words matter. How you talk about things affects how you think about them. To discuss “software development” as though it were a purely programmatic act excludes a large percentage of the people who participate in the process and encourages a “cult of the coder” mentality such that programmers are lifted up to near aristocratic levels.

This programming-centric view does software development no favours. By excluding other roles from the language we use, we also exclude them from how we think about the process. The piles of startup corpses strewn along the road to business success are a testiment to how ignoring things like user needs, market fit, and usability will scuttle even the best coded piece of software. Recent findings by GitHub show that excluding documentation from the process has negative effects on the adoption of and contributions to free and open source software projects, no matter how well architected their APIs.

The biggest loser in this “cult of the coder,” though, is the end user. The poor unfortunate souls who struggle to use a UI created by someone inexperienced in the skill, who growl in frustration as yet again a software service updates without a much requested feature, who are astounded by Internet of Things products with no concept of security, who puzzle out and reverse engineer undocumented installation steps. So much productivity, opportunity, and customer good will lost because software companies often focus more on programming than on the entire software development process.

Don’t get me wrong: I love programmers. I’ve spent most of the last ten years of my life leading programming teams and departments. Programming is a highly specialised and ever changing part of the industry. It’s populated by some of the most clever, most inspiring, and kindest people with whom I have ever had the honour to work. It is not the fault of programmers that the language shifted around them. It is the fault of our industry, our community, and our culture.

We can do better. We can do better for the end user, for programmers, and for everyone involved with or impacted by software development. It all starts with changing our perceptions through language.

Let’s start to shift the language back and reclaim the term “developer” for all who participate in this complex process rather than just the programmers. Let’s evolve the mindset back toward one where we recognise the contributions of all of the roles which contribute to delivering and supporting a successful software project. Let’s call a spade a spade and a programmer a programmer and just get back to work creating software which changes peoples’ lives in valuable ways.

Public Speaking Resources

Had you told me 10 years ago that not only would I be on the open source/tech conference speaking circuit but that I would love it, I would’ve looked at you like you had three heads but only two eyes between them all.

And yet, here we are. In 2016 I presented 18 talks at 15 events all over the world. So far in 2017 I’ve either presented or organised 9 talks or events. I advise people on their conference proposals, bios, and on the talks themselves. I provide training for those who wish to get started in conference speaking. This is not at all the life I envisioned for myself; it’s So Much Better and I’m grateful for the opportunities I’ve had so far. Thank you, all.

In 2016, in collaboration with Josh Berkus, I presented my first ever speaker training workshop. Since then both Josh & I have presented the material separately and each made it their own. We’re covering more ground this way, training far more people than we would if we had to coordinate between our very hectic schedules.

During the writing process of that workshop, we created a bibliography of public speaking links. In the year and a half which followed, I kept adding to that bibliography whenever I discovered a link which we hadn’t included the first time around. It was turning into a really great resource for those wanting to learn more about presenting at tech conferences, but it was impossible to find. Who drills down into the repo of a workshop which was presented only once? No one, that’s who. So the valuable bibliography was lying dormant. Well. It ain’t sleeping anymore…

🎉 Please welcome the Public Speaking Resources repo into the world! 🎉

Currently weighing in at 50 different public speaking and conference presenting links, this is one of the best resources you’ll find for improving your conference speaking experience.

One of the advantages of pulling the bibliography out into its own repository is that it’s now very easy for anyone to contribute a new link or resource for the benefit of everyone. We ❤️ contributions and contributors!

Even if you don’t have a link to contribute to the collection, the repo also serves as a focal point for a community which can answer your tech conference presenting questions and help support you on your path to becoming an amazing conference speaker. There are two ways to get this support:

  1. Open an issue with your question or suggestion and we’ll do our best to guide you.
  2. Join in the real-time conversation on the #public_speaking IRC channel on Freenode. Yeah, we know that Slack is the new hotness, but this project still kicks it old school. But fear not! The IRC channel is covered by the project code of conduct, so you needn’t worry about dealing with the less savory elements of the internet. You also don’t need to jump through a lot of hoops to join in the conversation. Just hop on the webchat, pick a nickname, and you’re good to go! If you’d like to learn more about how to use IRC, there’s an article for that.

There ya go! Please share this public speaking resource with everyone who might be interested and please contribute. Together, we’ll help a lot of people improve their public speaking, their self confidence, and their careers.