Scott Davis

Introducing Scott Davis

Scott Davis is a web architect and principal engineer with ThoughtWorks, where he focuses on innovative and non-traditional aspects of web development. He was also the founder of ThirstyHead, a Denver-based training and software development consultancy, where he became convinced that having the freedom to be honest about a product was the only way to speak about it with real enthusiasm. Scott has written a number of articles and books about web development and over the past 10 years has built a reputation as a hugely engaging keynote speaker on developer advocacy. Find Scott on Twitter: @scottdavis99

Geertjan Wielenga: To begin with, do you consider yourself to be a tech evangelist or a developer advocate, or something along those lines?

The advocacy versus evangelism debate

Scott Davis: We could spend our entire conversation simply unpacking the politics behind those two phrases. I prefer "advocacy" over "evangelism" because it implies a more measured, thoughtful, and nuanced discussion. But I can appreciate the passion behind evangelism, and my speaking style has been compared favorably to a "pastor in the pulpit" more than once.

For most of my professional career, as an author, teacher, and speaker at software conferences, I've tried to focus on advocating free and open-source tech.

I like lending my voice and passion to projects that may not have large corporations behind them.

Geertjan Wielenga: But wouldn't you say that in the term "evangelism" there is something about enthusiasm that "advocacy" might be missing?

Scott Davis: Since I'm not being paid by a corporation to talk about its products, I definitely have an honest, heartfelt fire in the belly for what I choose to talk about.

The first time I spoke at the Great Indian Developer Summit in Bangalore, India, one of the attendees went up to the conference organizer after my talk and said, "I don't remember his name, but be sure to invite back the speaker who has hair like a lion!" I love that! Admittedly, I do roar about standards-based development and open-source solutions quite a bit; it's an apt comparison.

On a related note, it's interesting that what works well on stage (having an outsized personality and a booming speaking voice) works less well for pair programming. You don't want someone who is boisterous and loud as a partner; you want the power dynamic to be far more balanced. Ideally, you want to pair up with someone who listens more than they talk.

Geertjan Wielenga: Would you consider the term "spin doctor" to be applicable to you at all?

Scott Davis: We're really drawing a fine line here. I think developers, generally speaking, tend to be averse to that kind of marketing spiel. "Marketecture" is the unflattering portmanteau of "marketing" and "architecture" that we use to describe disingenuous tech solutions.

We've all heard stories about key architectural decisions being made between a sales rep and a vice president or chief technology officer (CTO), out on the golf course. True or not, when a tech stack isn't the right solution for the problem at hand, it simply doesn't smell right, and no amount of persuasion will convince you otherwise. It's not the job of the sales rep to point out a product's shortcomings.

"Once you lose that authenticity, it's really hard to win it back."

—Scott Davis

I think that, for developers, authenticity is really crucial to the message. I'm a long-time Apple fan, but I'm not an apologist. There was a recent scandal where Apple was accused of intentionally slowing down older legacy phones. The technologist in me can say, "Oh, so Apple is slowing down phones to protect against aging battery issues? That sounds plausible." The suspicious skeptic in me says, "No, Apple is slowing down older phones to make the latest model seem more appealing." The truth is probably some combination of the two, but once you lose that authenticity, it's really hard to win it back.

Geertjan Wielenga: Have you ever actually worked for a company and promoted its tech?

Scott Davis: I haven't. I've interviewed a number of times with a number of different companies for roles like that. I've had lots of opportunities to be a "product evangelist," to use that phrase.

One of the things I bring up in those interviews is "hey, are you okay with me saying good things about the competition? Are you okay with me talking about rough spots in our API or our product?" I think those questions are crucial to my credibility as an advocate.

Mostly, the response is "are you kidding me? No, you can't say nice things about the competition! No, you can't point out the shortcomings of our product!"

Not being able to speak honestly about a product would mean that I was failing as an advocate. Here's a hypothetical example: if I was a product evangelist for MongoDB, I would want to be able to say, "I really like MongoDB. I've been through the training. The software is good. It has great professional services and support, but it's purely a server-side solution. There isn't a solution if I want to keep some or all of the data local, like in a browser, or if I want to synchronize between multiple instances. It doesn't seem to have an "offline" story. In that case, I'd look to something like PouchDB or CouchDB. Now, if you don't need local synchronization, then MongoDB is a solid option. Let me show you some of the cool things it can do."

That, to me, doesn't feel like I'm being hard on MongoDB. I mean, if it's a feature that the software simply doesn't have, I feel it's important to address it and offer alternatives.

Geertjan Wielenga: What would you say are the advantages or disadvantages of being a developer advocate working for a company versus working for yourself?

Scott Davis: I ran ThirstyHead—my own software consultancy—for a decade before joining ThoughtWorks. What I enjoyed about working for myself was the freedom to talk authentically about the tech that was really exciting to me.

Thankfully, ThoughtWorks encourages me to continue talking about what I'm most passionate about. It doesn't exert any editorial control at all over what I say on stage or in my writing.

"The upsides to working for a large organization in a product advocacy role are that you get a steady paycheck and deep insider knowledge."

—Scott Davis

The upsides to working for a large organization in a product advocacy role are that you get a steady paycheck and deep insider knowledge. You can talk about the cool, new, upcoming features that no one else knows about.

Geertjan Wielenga: How did this all begin for you? If you go right back to the very beginning, was there anything in your family life or in your past that led you to where you are now?

Scott's path to advocacy

Scott Davis: Yes, absolutely. My parents met at IBM in the 1960s. My dad was a software engineer and my mother was an IBM Selectric (an early programmable typewriter) consultant.

I literally grew up surrounded by tech in the house—the first IBM PC came out while I was still in elementary school. My dad taught me how to put together spreadsheets, and my mother showed me how to crack open the computer case to add more RAM. I'm not sure that I could've ended up anywhere else than where I am right now, given the parents that I had.

Geertjan Wielenga: Initially, were you purely into programming?

Scott Davis: I actually started out studying architecture at the University of Nebraska. I was doing fine except for all of my architecture classes, so I dropped out for a year to figure out what I wanted to study next.

I got a job answering phones at a call center for a long-distance phone company. On my own, I put together a spreadsheet that had the names of the operators down one column and the days of the week across the top. I used this magical @sum function to total up the number of calls each operator answered every day. I showed it to my boss and it blew her away. I got into software development very quickly after that.

What I was doing at work wasn't sophisticated, but it was a real game changer in terms of what my boss had to do. Having software take those mundane, repetitive tasks out of your life really adds value.

When I went back to school, I ended up with a degree in Information Systems and Quantitative Analysis (ISQA)—half statistics and half software development.

Geertjan Wielenga: How did your career progress from there?

Scott Davis: My first job out of college was teaching software classes to business professionals. I started out teaching DOS classes—things like Lotus 1-2-3, WordPerfect, dBase, and Harvard Graphics. Not too long afterward, I started teaching classes for brand new Microsoft products like Windows 3.1, Word, Excel, PowerPoint, and Access.

As we installed networking in the classrooms, I got certified in Novell NetWare 3.11 and began teaching those classes. Over the next couple of years, I ended up with 15 Microsoft certifications in Windows NT 3.51 and 4.0, Exchange, SQL, TCP/IP, and Internet Information Server (IIS), the web server included with the operating system. That was in the early- to mid-1990s, when the first web browsers like Mosaic, Netscape Navigator, and Internet Explorer were introduced to the general public.

What teaching allowed me to do was take a deep dive into different, competing software packages in the same category. Each of those applications was stronger in certain areas and weaker in others. It gave me a more democratic view of software in general—there isn't "one ring to rule them all" when it comes to software. There isn't one true way to do things. There isn't one true programming language, or one true web framework, or even one true operating system.

Tech really is a world of strengths and weaknesses. Advocacy, I think, is where you honestly say, "If we balance out the pluses and the minuses, I'm going to send you down the path where there are more strengths than weaknesses. But I also want to make sure that you are aware of the sharp, pointy edges that might nick you along the way."

I spent eight years in the classroom as a software instructor and that has really informed my entire career. It's one thing to sit down and kind of understand how something works when you're cowboy coding on your own. It's another thing altogether when you're standing up in front of an audience of tens, or hundreds, or thousands of people.

Geertjan Wielenga: How did you get from that classroom setting where you were teaching Windows and DOS to being on these public stages?

Scott Davis: My mother, in addition to working for IBM, was also in theater. Thanks to her, I've been on the stage since I was five or six years old, so I've always had that confidence that comes from being a performer.

"I know my lines and the audience doesn't; it's not a fair fight."

—Scott Davis

It boils down to this: I know my lines and the audience doesn't; it's not a fair fight. They aren't going to know when I make a mistake unless I stumble. The audience is there for the performance, not for a line check of every last word and syllable. Honestly, they want you to succeed—they want to be entertained and informed.

A great stepping stone on your way to presenting on the "big stage" at professional software conferences is giving a talk at a local meetup or user group. I've spent over 20 years in the user group community.

I was the president of the Denver Java Users Group in the early 2000s, and after that I ran the Boulder Java Users Group for years. I just wrapped up the HTML5 Denver Meetup after running it for over a decade.

If you don't feel ready to give a 60-minute talk on a topic, look for lightning talks. They are typically only 10 minutes and 10 (or so) slides. It is literally just long enough to say, "Hey, have you heard of this framework? Here's how you install it, and here's a quick 'Hello, World!' example." But in that quick 10 minutes, you still have the basic elements of an effective 60 minute talk: introduce the topic, pique the audience's curiosity, and give them enough to explore it further after the talk.

Geertjan Wielenga: How did you get to an international stage? What was that process?

Scott Davis: It was through the Denver Java Users Group. I started attending that and then thought, "There are a lot of really great advanced talks here, but could we have a series of talks that would be a gentler introduction to Java?"

Starting a "Basic Concepts" series of talks at the Denver Java Users Group led to a writing opportunity—my first book, JBoss at Work. Then, as an author, you start getting invited to local and regional software conferences. From there, it grew to national conferences within the U.S., and later, I was able to broaden out to the international stage.

Geertjan Wielenga: Developer advocacy isn't a common career path. Why is this?

Getting up on stage

Scott Davis: Public speaking continues to be one of the number one fears that many people have. There's that common nightmare where you're standing up in front of your classmates at school giving a report and, all of a sudden, you're naked or you've forgotten what you wanted to say next. It takes a real act of courage to stand up and present yourself as an authority, especially to a group of your peers.

On the flip side, I really try to be mindful about not appearing arrogant. I try to turn each presentation about software into a personal journey—a "hero's journey" if you're familiar with the literary concept. I don't want to stand up and say, "I know this and you don't, so why don't you sit back and listen to me talk about how much I know." I like standing up and saying, "Hey, I'm a Java developer and I just discovered this new language, Groovy. Let me show you what I've learned so far."

"No one can call you a liar for sharing your personal experience."

—Scott Davis

It's fantastic being able to come from a very personal place to say, "This appeals to me and let me tell you why." It's the best cure for imposter syndrome I know of because you're talking about your journey and your experience with the software. No one can call you a liar for sharing your personal experience.

Even if being on the stage holds no appeal for you, you can still contribute to the conversation through writing blog posts or an article series; starting a podcast or screencasts; or even posting code to a public Git repository. These are all low- or no-cost ways for you to find your voice and share it with the public. You don't need to ask permission—just do it!

Geertjan Wielenga: Would you say that you need to be a complete expert on a particular tech or on a topic before you can be a speaker or author in this developer advocacy domain?

Scott Davis: Getting back to that voice of authenticity, I tend to enjoy blog entries and articles where people are very honest about what they struggle with. In that way, the writer says, "This is a concept that really didn't make sense to me at first, but here was my breakthrough moment."

I had an experience like that most recently when dealing with RxJS, a reactive library for JavaScript. It wasn't the syntax that I was struggling with: it was the underlying concepts, the reactive/declarative mindset, and the worldview, if you will. I've been dipped in imperative programming my whole life, so I was really struggling to get into that reactive mindset. But once it happened, that lightbulb went on and I thought, "Oh, now I get it!" It was like staring at that duck/rabbit optical illusion and finally being able to see the rabbit.

Now when I'm giving presentations on RxJS (or reactive programming in general), I always tell that story. It humanizes me and more than a few people in the audience are probably fighting that very same battle.

I give an imperative example and then a declarative one right afterward: "See how the declarative example is doing the same thing in far less code? That's the rabbit I was telling you about!" That's the "hero's journey" in a nutshell right there. It's not the solution alone that's important: it's the journey leading up to the solution as well.

Geertjan Wielenga: What are some things that you wish you had known at the start of your career, especially as an advocate?

Scott Davis: My little brother also went into software as a career. Just as he was getting ready to graduate from college, one of his professors said, "There's a good chance that you're never going to use the programming languages that you learned here in class out in the real world."

It's true! I had two semesters of COBOL in school and never once got a paying gig writing COBOL after graduation. The idea that you can learn a single language that will carry you through to the end of your career is probably setting you up for a lot of heartache and disappointment. You have to be prepared to be constantly learning, constantly adjusting, and constantly evolving over time. You need to be prepared to be a polyglot programmer, which is Greek for "many tongues" or many languages.

When I call a plumber, they don't show up with a single wrench in hand and ask, "Okay, where's the leak?" They show up with a whole truck full of tools, some of which might only be used once or twice a year. But when the job calls for a specific tool, that plumber is prepared to use the best tool for the job.

Geertjan Wielenga: What have you been advocating recently? I've seen you talking about conversational user interfaces (UIs) and responsive progressive web apps. How do you choose which tech to advocate?

Scott's hot topics

Scott Davis: The iPhone is now over a decade old. I vividly remember when it came out thinking, "Wow, this is a game-changer: a full-fidelity web browser in my pocket!" That was before the App Store was even a glimmer in Apple's eye.

That was also the timeframe when Google Maps was first released. I was working on a pre-release version of Google Maps for a satellite imaging company, and I could viscerally feel how AJAX-based websites changed the whole user experience for the better. The iPhone and Google Maps forever changed the way we do web development.

"You can actually use your voice to communicate with the device in your hand in a meaningful way."

—Scott Davis

I'm feeling that same way right now about conversational UIs. We're hearing devices actually speak to us in realistic voices, not like the primitive chatbots of the past that used robotic speech synthesis like Stephen Hawking or in the movie WarGames. You can actually use your voice to communicate with the device in your hand in a meaningful way. We're seeing this show up on our smartphones, on our watches, and even on our television remote controls.

I used to laboriously tap out Breaking Bad one letter at a time on an onscreen keyboard using the left/right/up/down arrows on the remote. Now I hold up my remote control and say, "Breaking Bad."

I really feel that conversational UIs have got to the place now where the software, hardware, and bandwidth are all there. It's that perfect storm where it's all come together. This idea of talking to computers is really breaking down barriers once again. There's something very natural about walking in and talking to a computer. I'm really fascinated by that.

Where this really shines is when we start talking about accessibility. I walk into the kitchen in the morning and say, "Hey Alexa, play some Bob Marley." It's a novelty for me, but imagine if I had low vision or full blindness. All of a sudden, it's not a novelty—it's my whole user experience.

In both the U.S. and worldwide, the literacy rate is only about 85%. For 15% of the world, a conversational UI is their whole user experience. If you have dyslexia or another cognitive impairment that makes reading hard, conversational UIs can help. If English is your second language, perhaps it's easier to hear it than read it. Heck, if you're driving or have a baby in your arms, a conversational UI can make your life easier.

We're on the cusp of the "next big thing" with conversational UIs, and I'm having a blast exploring all of the possibilities.

Geertjan Wielenga: How do you stay up to date and in touch with the latest tech developments?

Scott Davis: I read incessantly. I think the biggest sources for me are my Twitter feed and going on websites like Ars Technica, A List Apart, Wired, TechCrunch, and the like.

When you visit those different sites and see the same story told from different perspectives, you really begin to see the trends emerge.

You have to have a love of learning. I get itchy and do everything I can to not get bored from a tech perspective. I'm like a shark that has to keep swimming to stay alive. Much of that motivation has to come from within.

"Find a job that lets you do what you love."

—Scott Davis

What can make that hard is when the tech that interests you is not what you're working with for your day job. So, in an ideal world, you have to find a tech that you love and then find a job that lets you do what you love. I think that's the perfect model.

Moving away from pure programming

Geertjan Wielenga: What would you say is the advantage of developer advocacy over spending your life being a pure computer programmer?

Scott Davis: Look, not everyone needs to be an advocate. I've got lots of friends whose real passion is rock climbing or snowboarding. For them, programming is an interesting, exciting, and innovative job, but more importantly, it's a well-paying job; it's something they do as a means to an end.

For me, I've got Alexa at home in several rooms. My family members all have iPads and iPhones. My advocacy, once again, comes from a place of authenticity—this is how we live; we live these digital lives.

My iPad is the first thing I see when I wake up in the morning and it's the last thing I see when I go to bed at night. A device, to me, is not just a computer that you sit down at and walk away from—it's something that you develop a kind of relationship with.

In terms of advocacy, it should be personal. You should be talking about something that you're passionate about. Advocacy is something that you feel compelled to do. You're almost not choosing the tech: the tech is choosing you and you can't help talking about it. If you can find something like that, then it's easy because you're doing what you love.

Geertjan Wielenga: You travel frequently and you come across developer advocates everywhere. What would you say are some commonalities among them?

Scott Davis: What I love most about going to software conferences is meeting the other speakers. I love sitting down at the end of the day and having a drink with them or waking up in the morning and having coffee and a masala dosa with them.

There is something about being a conference speaker that draws us all together, regardless of the language we speak, the company we're working for, or our platform of choice. I love hearing iPhone developers talk passionately about Objective-C and Swift, and I love hearing Android developers talk passionately about Java and Kotlin.

"I'm attracted to passion. Honestly, the particular focus of that passion is less important to me."

—Scott Davis

I'm attracted to passion. Honestly, the particular focus of that passion is less important to me. I just love hearing someone else be really passionate about something they love; it makes for great conversation.

Geertjan Wielenga: Have you been in situations where your audience or a client was more knowledgeable? How did you handle that?

Scott Davis: You just described the life of a consultant! I find myself in that situation all the time, whether it's in the classroom or on a new software project. I try to establish some ground rules early on to help to nip it in the bud.

For example, if I come into a pharmaceutical company, I say, "Hey, you know much more about pharmaceuticals than I do, but I know a thing or two about software development. Let's sit down together. You have an idea of what you want the app to do. I have the software skills to help translate your vision into running software and make it come to life." So, rather than setting up an adversarial relationship from the start, I try to respect and acknowledge their strengths. In turn, hopefully, I give them a way to respect my strengths as well.

Geertjan Wielenga: In the life of a conference speaker, technical glitches happen all the time up on stage. How can they be avoided and how do you react to these situations?

When technical glitches hit

Scott Davis: Resiliency is something we always talk about in software. I think resiliency is something you have to strive for as an instructor or as a conference speaker.

It's not avoiding technical glitches that makes you a pro: it's the grace and humor you use in reacting to the glitches when they inevitably happen. I've had a number of people come up to me after a talk that went badly and say, "I'm sorry that you had trouble up there on stage, but I probably learned more from watching you debug it in real time than if everything had gone right in the first place."

Nowadays, I take a screenshot of every website that I'm going to mention in my presentation and put it in my slides with a hyperlink. If I'm at a conference with good Wi-Fi, then I can click on the screenshot and seamlessly scroll around the live website as I talk about it.

If, on the other hand, I end up in a hotel conference room in the basement with crummy Wi-Fi, then I just discuss the static screenshots in my slide deck. I never apologize for not having a live Internet connection—that's part of the theater experience. You silently adapt to the presence or absence of good bandwidth, and the audience never knows the difference.

I love to give live coding examples in my presentations, but I always have a working, finished copy of the example saved in a parallel directory. If I get stage-blind and can't find the bug while I'm live coding, I don't spin my wheels for too long. I say, "Okay, let me show you what I was trying to demonstrate here." I then pull up the working code and make some trivial edit, like changing "Denver" to "Frankfurt" or "Oslo" (wherever I happen to be at the time), which gives the illusion of live coding.

I might then take that working code and purposely insert a syntax error to illustrate a point: "See how easy it is to miss a semicolon here? Let's look at the error message so that when you find yourself in a similar situation back at the office, it won't be nearly as scary."

Geertjan Wielenga: What about the laptop-not-connecting-to-the-projector scenario? What then?

Scott Davis: Years ago, I did all of my presentations in PowerPoint. Later, I graduated to Keynote. PowerPoint was, for better or worse, the least common denominator. It was something you could assume would be available if your personal laptop wouldn't work with the audio/visual setup at the conference.

Sadly, most of my legacy presentations are now trapped in an outdated, proprietary nut that is harder to crack than you might think. Apple and Microsoft are far less concerned about backward compatibility and legacy support than I am, apparently.

What I've started doing now is writing all of my slides in HTML and posting them on the web. I call it "Talk-o-Vision." It's pure HTML5, CSS, and JavaScript, with zero external dependencies. Just as every Jedi must build their own light saber, as a professional presenter, I take great pride in building my own slide decks from standards-based tech that should stand the test of time.

As a result, if I get into a conference situation where my laptop won't connect, I know that any device with a browser and an Internet connection will allow me to pull up my slides and proceed.

If the overhead projector isn't working, that's an entirely different kind of problem. You can laugh about it and offer to do an interpretive dance in lieu of your prepared slides!

Not having a projector is a more difficult challenge to overcome, but if your slides are publicly available on the web, everyone in the session could still potentially pull them up on their own device and you could proceed with the presentation.

Geertjan Wielenga: How do you deal with the whole area of jet lag, missed flights, and the typical problems of the world traveler?

Travel management tips

Scott Davis: I optimize less. I used to be really aggressive about it, saying, "Alright, my first talk is Monday morning at 9 a.m. I'm going to get in on Sunday at midnight because that is the least amount of time I need."

Unfortunately, that strategy doesn't leave any margin for error, as all professional travelers learn. Nowadays, I try to give myself a full 24 hour buffer coming in.

When traveling to India from the U.S., that 24 hour buffer is almost a requirement. There's a 12 and a half hour time difference between the two countries and around 18 hours of flight time depending on how many hops it takes to get there. At that point, night is day, left is right, and up is down. That kind of time shift can be brutal if you don't anticipate it and make accommodations.

"Trying to live in one time zone while being physically located in another is a recipe for disaster."

—Scott Davis

Whether I'm traveling across the world or just to one of the coasts in the U.S., what helps me best adjust to the new time zone is simply eating breakfast when the clock on the wall tells me I should, instead of when my internal clock tells me I should. Trying to live in one time zone while being physically located in another is a recipe for disaster. If I can get one solid "wake up when the sun comes up, go to bed when the sun goes down" cycle in, that's typically enough to get me through the next day of presentations.

Geertjan Wielenga: With these topics we're discussing now, coupled with the passion of this profession, do you think that there's a risk of burnout?

Scott Davis: Sustainability is a really important topic that we don't often talk about. Here's one way to think about it: an introvert is someone who can interact with other people—and maybe even enjoy it—but it drains their battery. It's crucial that they get some quiet/alone time to recharge.

I know a number of conference speakers who have this great, outgoing stage persona, but they self-identify as introverts. They are absolutely wrecked once they get off the stage and need time to recuperate.

I'm an extrovert, so I find that being on stage is what actually charges my battery. If I haven't been on stage in a while, if I'm not giving presentations, wildly gesticulating with my hands, or talking loudly and passionately about something, that drains my battery. I almost always come off the stage with more energy than when I started.

Whichever camp you fall into, be sure that you take care of yourself. It's far too easy to plan for your presentation and forget to plan for your recovery.

Geertjan Wielenga: When you're at a party or speaking to people who are not at all in the tech field, how do you explain what you do?

Scott Davis: Rather than saying, "I do responsive web design," "I write progressive web apps," or "I'm really into offline-first web development," I say, "I make sure that websites look good on your iPhone or Android."

I might also ask, "Have you heard of Alexa? Have you heard of Siri? Cortana? That's what I do: I do conversational UIs. I do my best to make sure that your devices make sense when they talk to you."

"Put yourself in the shoes of your end users."

—Scott Davis

I think that it's far too easy for us to focus on the tools we use rather than the people who use our apps. Step one in design thinking is "empathy"—put yourself in the shoes of your end users for a moment and view your app through their eyes. I'm fairly sure that if you ask a typical software developer what step one is, they'll say, "Download a framework or set up a code repository."

Mozart wrote symphonies. If you asked him what he did for a living, I doubt that he would have said, "I write notes on a musical staff with a quill pen."

Many times, when I'm talking to a customs agent or someone in passport control, saying that I'm an author helps. I'll say, "I'm speaking at a software conference about this book that I've written." It establishes what you do in a common language that everyone understands.

Geertjan Wielenga: What talks are you working on right now?

Scott Davis: I'm working on a keynote called "The Ship of Theseus." It's an ancient Greek paradox about a wooden ship that belonged to one of the first kings of Athens.

Theseus sailed over to the island of Crete and killed a vicious monster called the Minotaur. When he returned, the citizens of Athens preserved his ship out in the harbor as a memorial to this momentous victory. Every year, they'd take Theseus' ship out for a victory lap to commemorate the event. According to the story, this went on for centuries after Theseus' death.

Here's the paradox: as you'd expect, various wooden parts of the ship rotted away over years. The citizens of Athens dutifully kept the ship in working order, replacing all of the parts necessary to keep the vessel seaworthy. Therein lies the question: since the ship was no longer made up of the original wood from Theseus' time, was it still truly Theseus' ship? If not, when did it cease being Theseus' ship? Is there a specific percentage, threshold, or milestone that we can point to and say, "There! Right there! That's when this thing technically stopped being the Ship of Theseus."?

Isn't that a lovely thought experiment? It really forces you to consider what the true essence of something is versus the raw materials used to build it. What a perfect metaphor for web development!

If you did an archeological dig on my website, you'd find 30 years of then-current, now-abandoned web technologies: ASP pages; JSP pages; Prototype and Scriptaculous; Groovy and Grails; jQuery; Backbone; Angular; Node.js; and Express. And yet, despite all of that churn, not once have I ever considered it anything other than "my website."

When you ask a typical web developer what they do, they'll often say, "I'm a React developer. I'm an Angular developer. I'm a VueJS developer." As far as I'm concerned, that's like saying, "I'm a spoon chef," or "I'm a hammer carpenter."

These tools that feel so important to us right now—that define us—are, in fact, ephemeral. The average lifespan of a website's design is typically less than two or three years. So, all of our efforts are spent on the surface of the water, being buffeted by the waves and dodging the flotsam and jetsam of last year's "gotta-have-it" framework.

Did you know that the original web page that Tim Berners-Lee published is still available on the web today? It still renders in 100% of modern browsers. Talk about the Ship of Theseus, right?

This is why I'm really focusing my efforts these days on standards-based techs like HTML, CSS, and JavaScript. Their longevity is measured in decades, not years or months. The deeper you go into the water, the slower the currents run, and the longer you can reap the benefits of your return on investment.

Geertjan Wielenga: We've established that you're not a traditional developer advocate, but you do promote particular techs. There's a whole range of people who one year are promoting tech A and then a couple of years later are promoting tech B. How do you feel about that? Should we look kindly upon that and be forgiving or be harsh and questioning?

Changing your mind about tech

Scott Davis: I think that it's important to be able to change your mind professionally. You have to ensure that you never get so dug into a position that you can't back out or make an opposing argument later.

One thing that I try to do, whenever I'm advocating a tech, is point out its shortcomings as well as its strengths. That kind of balanced approach is what I look for in conference speakers too. If they aren't able to say one nice thing about another tech, or one bad thing about their own, that's when I get suspicious and my spidey senses start tingling.

Neal Ford popularized the "Suck/Rock Dichotomy." This is when people say, "This framework is the best thing ever! That framework is the worst thing ever! Mine rocks! Yours sucks!"

"Since we're programmers, it's easy to slip into a purely binary mindset: 1 or 0, true or false, black or white, good or bad, and so on."

—Scott Davis

Since we're programmers, it's easy to slip into a purely binary mindset: 1 or 0, true or false, black or white, good or bad, and so on.

The real world, of course, is a wee bit more nuanced than that. I like reminding developers who use the binary argument as a rhetorical crutch that it takes 8 bits to make a byte. Every single character that you type on the screen is a healthy mix of 1s and 0s.

Geertjan Wielenga: Thank you, Scott Davis.