Talks
Keynote: What Happens to Everyone, When Everyone Learns to Code?
Summarized using AI
Keynote: What Happens to Everyone, When Everyone Learns to Code?
by Farrah BosticIn her keynote address at RailsConf 2014, Farrah Bostic explores the implications of coding becoming a universal skill and the transformative potential it holds for individuals and society. Bostic argues that if everyone learns to code, it will not only democratize the understanding of technology but also foster collaboration across various disciplines. She begins by reflecting on her own experiences with coding, describing it as a journey from being a novice to grappling with the complexities of coding practices.
Key Points:
- Coding as a Universal Skill: Bostic emphasizes that everyone should learn to code, regardless of their background, fostering a more inclusive tech environment.
- Learning to Code: She discusses traditional learning paths (e.g., obtaining a CS degree) versus more accessible options like coding bootcamps and online resources.
- Good Coding Practices: Bostic underscores the importance of writing practices in coding, comparing them to writing techniques. This includes writing, editing, and the necessity of seeking feedback.
- Community Support: She stresses the significance of community in learning to code, sharing her positive experiences with supportive coding communities.
- Structural Code Inequality: Bostic raises concerns about a potential divide where novices remain beginners, while experts continuously advance, creating barriers to entry in tech fields.
- Customer-Centric Coding: She advocates for coders to adopt a customer-centric approach, prioritizing the needs of end-users and engaging collaboratively with non-coders for better product outcomes.
- The Role of Documentation: Bostic highlights the critical need for clear documentation and communication in coding, as these practices help bridge gaps between novices and experts.
- Conclusions: She concludes that coding should be about problem-solving and creating value, encouraging programmers to embrace a more holistic and collaborative perspective.
Overall, Bostic's address promotes the idea that coding education should be pursued by everyone, fostering a collaborative mindset within diverse tech communities to advance innovation and inclusiveness.
00:00:16.380
Okay, so I think you guys sort of misunderstood. This is the entertainment portion of the afternoon. I'm going to embarrass myself in front of you. This is actually a chance to sneak off and go drinking early, but thanks for showing up for my public humiliation.
00:00:29.710
So, you know, I do a certain amount of coding. It is kind of like the way I play golf, which is slowly and not very well. But I spend a certain amount of time thinking about what it will be like one day when I'm actually a coder and not just someone who sometimes codes. So that's kind of the thought experiment and the world imagining that I am going to take you through with this particular talk.
00:00:50.530
First of all, that's my Twitter handle if you want to heckle me online. And Abby is right! I run a startup product strategy company called The Difference Engine in Brooklyn. It's a lot of fun, translating what people actually find valuable into actual products that they can then use. This process is a harder battle than it should be, but it is a worthy one, I think.
00:01:03.820
So, feel free to make fun of me online. This is the world I come from: it is a bloody business, advertising, and it is generally characterized by some conditions you might actually feel some empathy for. Clients come to you thinking they already know what they need and asking you to make that thing. So, it’s a lot of requests like 'I need a 30-second spot because, for some reason, everyone stopped buying my product.' But the reason they stopped buying your product is not only that you haven't done any advertising in a while, but also that your product might suck.
00:01:26.860
People kind of figured that out, but please just make me a 30-second spot because I don’t trust you to know anything about my actual business. So, that's the world that I come from. When I joined the world of advertising, I started out as a writer, which was an interesting choice. I was cynical enough as a teenager in my early 20s to think that it would be great to have a job as a writer.
00:01:46.570
I got a degree in advertising and went to work in advertising, only to find out that advertising agencies don't really have a lot of use for junior writers. So I went to work for a web design shop, and started making things out of the internet. That was back in '99, so it was mostly HTML. We were hand-coding every page. It was really awesome. So this morning when someone mentioned you are all software writers, I thought, 'Yes! Awesome!'
00:02:10.360
This is why I really like the idea of coding. I think it's an interesting construct for thinking about how we will be collaborating as technology evolves. The thing about being a writer, however, is that there's a line from an author which goes, 'Life is short; a craft is long to learn.' This encapsulates writing. Writing itself is about practice, much like Zen Buddhist meditation. You really just have to sit and do it. You have to do it every day, over and over again, and you have to get feedback on it.
00:02:35.900
That's painful; you don't want to do that, but you have to do it. Then, you have to do it again. This is a really great construct for thinking about some of the things I'm going to talk about for the rest of this talk. So, thanks, David, for teeing me up this morning. Good writing practice, like I said, means you just write and then leave it alone.
00:03:04.400
Stop fussing over it! Stop worrying about it. Stop revising it! Stop running four lines of tests for every one line of code. Leave it alone for a bit and read it aloud. Actually, it's a really useful exercise, and I find it's helpful for me as a terrible coder to try to read it aloud. Oh, yeah, I forgot the semicolon. Then, of course, there's the need to edit.
00:03:37.920
In editing, you must kill your darlings, which means that every once in a while, you need to blow up what you did, throw it out, and start over. A few years ago, I took a fiction writing class I've never done before. The very first story I turned in, I actually felt pretty good about it, even though it was quite painful to write.
00:04:07.260
My classmates were very sweet in their critique; they said the language was beautiful, but they asked, 'What is the story about?' Oops! There's a point where you can try to force a story into beautiful writing where there was no really a story to begin with, or you can just throw it away and start over. So, I just threw it away and started over, and the next story I wrote actually had a story that came from an entirely unexpected place.
00:04:43.860
It turned out that it really reflected how much detective fiction I grew up reading. Suddenly, instead of a sort of heavy, cerebral lifestyle piece, I was in a murder mystery in Grand Ronde, Oregon, which is a town that's about the size of a nickel. So, that was a weird choice, but this fundamentally is about good writing practices. This is how I was trained and taught, and I think it's a lot of what you all do as well.
00:05:07.830
However, as I said, it takes a long time to get any good at it, and you can spend a lot of time at your desk trying to avoid actually doing it. But what happens to everyone when everyone learns how to write this way? When everyone learns to be a software writer and produce code? It seems to be an accepted fact at the moment. I know it is a fact because President Michael Bloomberg said it: 'Everyone should learn to code.' But he actually said that everyone should learn to hack.
00:05:39.600
That was a really interesting provocation coming from him. But in the meantime, everybody should learn to code. My boyfriend joked about making a single-serving site with 'Has Bloomberg learned to code yet?' To which he quipped, 'No,' every day. He started in 2012, so we should check in with him. I was doing a Google search and got 129 million results for 'Everyone should learn to code' as a search term, so clearly, this is something we're talking about a lot.
00:06:05.090
There's my little friend Grant here, who was blogging at about two and a half years old on his blog, E-toy. So, he’s totally a hacker already! Everyone should learn to code—we all agree. Everybody's grandmother should learn to code; the kid down the street should learn to code; your janitor should learn to code. Everybody should be learning to code—it’s simply true!
00:06:36.150
So, this is what we know out in the world as novices about how to become a coder. The first way you become a coder is you go to school. You spend about a hundred thousand dollars, spend four years of your life, and you get a CS degree. Now you're a coder! Yeah, that’s how it works, and that's how we are going to get a million STEM graduates.
00:07:01.170
The other option is perhaps less formal but more traditional, which is you need like 10,000 hours or 10 years—whichever is longer—to really become a coder. So, dig in, everybody, because it’s going to be a while. Of course, we learn some uncomfortable facts. Half of tech workers don’t even have college degrees, at least in New York, where apparently it’s just a town full of dropouts.
00:07:23.670
And that’s great. The part of that is that we need all of these tech workers, but the ones with the CS degrees went and worked on Wall Street. To actually build useful products that generate value, we have to get the people who dropped out of college because those are who’s left.
00:07:38.520
Then, there are these other new ways of learning to code. I've dabbled in many of them. There are schools—code schools like Flatiron School (shout out to Avi!), whom I’ve taken a couple of classes from. He’s great! General Assembly is another place in New York where you can learn to code. Apparently, there are these online code schools like Codecademy, Skull Crush, Code Hour, where all kinds of people are learning to code right now.
00:08:04.080
And then there’s like the usual approach where you just crush it and throw yourself into this thing, and Google it, and you wind up on Stack Overflow, learning to code by looking at stuff. Sometimes it seems like, in about 12 weeks, you can become a coder and make $80,000, give or take.
00:08:30.510
I’ve been working on this. It started for me with my friend Noah Briar, who calls himself a liberal arts coder. He taught me a little PHP, and we made a silly web app together one afternoon called 'Boyfriend, Dog, or iPad,' where it basically throws up scenarios and you would decide which thing was most appropriate for the scenario: a boyfriend, a dog, or an iPad. This was a brilliant idea I had on a very long drive by myself!
00:09:06.240
So he taught me a bit about PHP and summarized that all you need to know are GET and POST functions. I said, 'All I need to know is cut and paste.' Then I went to a startup weekend where everybody was slinging code really fast, and I was really impressed. I had a great time, met a ton of very important people, and that’s where I first heard about Ruby on Rails.
00:09:36.920
People told me, 'That’s the thing you should start with because it’s really welcoming; it’s an open community. It’s a nice place to be. It’s a nice language to learn; it’s fairly intuitive as these things go.' That’s how you should get started. Then I met Stuer D'ans, who lives with me, and he started teaching me some Ruby on Rails.
00:10:11.900
So, I got myself a 'Hello World' localhost 3000 page going. It was pretty exciting! We went to South by Southwest in 2011, and I heard John Dag of this great talk that was kind of about the beautiful craft of code. The subtitle was something like 'Lessons from Or Weal and The Clash,' and I thought, 'That is the session I’m going to. That’s why I want to learn to code!'
00:10:43.600
Punk rock! I wanted to learn to program, and Chris Pine’s course took me back to high school calculus, which I loved because there were ways of solving problems, and there were ways to tell when the problem was solved, which the rest of my life no longer looks like. That particular set of exercises was really great fun.
00:11:00.890
Then, my good friend Rachel Sklar connected me to Avi through the list, which was her startup, and I took this to our info to Rails class from Avi through Skillshare. It made it all make a hell of a lot more sense. He had a really interesting metaphor around waiters, cooks, and busboys that had to do with models, views, and controllers.
00:11:25.260
I can’t repeat the metaphor, but it made a lot of sense at the time because I had waited tables. So, that’s kind of the path that got me started. I’m still on this path—it’s a slow road, one I'm not always on, but it's definitely been an interesting journey.
00:11:46.860
I’m part of this world where everybody should learn to code. But the truth is, what I’ve learned along this path is that you learn to code by coding! It’s the same way you learn everything else. And just because you’re doing the thing doesn’t mean you identify as that thing.
00:12:13.410
I learned to sew by sewing, but I’m not a seamstress. Believe me! I know how to fix non-hybrid vehicles, more or less, for basic day-to-day work, but I am not a mechanic. There comes a point where I’m like, 'The fan is making a funny noise' and that’s like the end of my knowledge base.
00:12:38.360
But there’s a way that you just sort of do stuff. You open the hood, you look under the chassis, and kind of point at something and say, 'I think that’s what’s broken.' That’s really useful because it can save a lot of time on the expert side. If I can point at the broken thing and say, 'That’s the broken thing,' they say, 'Oh, right, well replace that.' As opposed to figuring out what is actually broken.
00:13:04.500
I’m pretty good at the diagnostic side now, and that comes from just doing it a lot. Figuring out what’s the worst that can happen—which turns out to be not very bad things most of the time. But when you start out this process of learning to code, it feels a lot like this: it’s very frustrating, a bit confounding; it all seems a little bit mystical.
00:13:29.150
And it does not bring the best out of people. After a while, though, you find something that feels a little bit more like this—think of that initial training onboarding process in Call of Duty, where they're trying to teach you how to use your weapons so you don’t die quite as fast as you would on your own.
00:13:54.700
As an occasional gamer who really loves a shooter, I appreciate the effort the developers made in trying to make it easier for me to live just that much longer in the game. I think what they're trying to do is set you up to be successful instead of abject failure every time.
00:14:16.390
One pivotal moment for me was when I was at the New York Public Library listening to a really interesting interview with Chuck Palahniuk interviewing Douglas Coupland. He spoke about how when he first read something like Generation X or Microserfs, he thought, 'This is how I want to write.' It’s like punk rock—start fast, go hard, and stop kind of abruptly.
00:14:49.610
That’s how Chuck Palahniuk writes, and more or less, when I code at all, it’s how I write as well. It doesn’t come out like really good punk rock, but it comes out sounding like something. So how’s that working out? In the run-up to the 2012 election, I completed my first build of my website in Rails.
00:15:17.080
This is not this website; this is my WordPress blog. I wrote a blog post about it and started my company, The Difference Engine. I decided the way I’m going to learn how to code is by actually building the site from scratch. I wouldn’t do a WordPress site or a Squarespace site; I’m going to build this thing myself so I can actually understand the underpinnings and how the entire system works.
00:15:45.450
When I finished that, I was sort of reluctant to brag about it—not because it was bad; it wasn’t great—but because I felt like if I said I'd built that, it wasn’t genuinely representative of what happened. At the same time, Barack Obama was getting harangued in the press for saying, 'You didn’t build that' about business entrepreneurs and business owners. I think we all more or less know what he meant.
00:16:08.790
There’s this kind of underlying infrastructure in an economic system, a tax base, workers, education—all that kind of thing—that Steve Jobs didn’t build. Yes, he built Apple, but he did not build all this stuff that connects Apple to the rest of the world. So that made me start thinking about my experience in building the site.
00:16:32.190
I did a People.txt file as a blog post, writing about everything I had used that was free or cheap on the web to build my website and start my business. Somehow, it went up on Hacker News, and Tim O’Reilly called it, 'This is a great description of the startup stack.' It was kind of amazing.
00:16:56.970
All of the parts that came into building it were referred to by people I knew on the internet, people I still haven't met in person, and people in this community who built these things and made them available, wrote really good documentation that made it possible for me to figure out what the hell it was. That all went into building that first site.
00:17:27.530
Now, this was November 1st, 2012, that I posted this thing. Last summer, I threw it out and rebuilt it again. That’s the 'kill your darlings' thing. I started completely over. What I experienced at that moment was something I wasn’t really expecting from what struck me as being full of people not like me, for a variety of reasons—being a specialist expert community.
00:17:58.550
And that was down to one of the guys who developed Locomotive CMS responding to a tweet in the middle of the night and getting on Skype with me to explain how to install it! That was the level of assistance and support—and sort of confidence-building—that I was getting from this community.
00:18:31.580
I was over the moon about the experience and had to recognize it somewhere. One of the things I learned is there are two topics that are plentiful on the internet: how to create more internet and porn. I think more often than not, there's more content about creating internet than there is about porn, which might be surprising.
00:19:06.810
What comes with the internet is this teaching on how to create more internet in this sort of self-replication model, where you wind up with a situation where you’re not either just learning or teaching the code; you’re also learning or teaching the culture. And that can be good—my experience with it initially was incredibly good—but it can also be a little bit scary.
00:19:33.600
One way you start to realize it is scary was something that was said this morning: professionals obey the laws and amateurs break them. That’s great! It makes amateurs sound like rock stars, like we’re rebels, just sticking it to the man and breaking laws and stuff. But they’re still amateurs.
00:19:57.540
Then there are novices, and I’m obviously in the novice camp. So I would probably say that novices also break laws, but typically by accident and often without even realizing it. You realize this for the first time when you encounter a stack trace—this massive 'what the...' moment.
00:20:21.880
You want to cry, scream, hide under the desk, and rock back and forth. I did all those things. I was able to remind myself, because I grew up in a hardware and tech startup household with a dad who worked for companies like Intel, that the reminder in the house was 'You can't break that!' "Don't worry about breaking the computer; it is just a box made out of sand with an understanding of on and off.' That’s all it is.
00:20:48.430
So, I kept reminding myself of that. OK, I didn’t break the internet with this! If I had broken the internet, someone would have called the president! You know what you start to figure out relatively quickly is, 'Oh, there’s an error message here, and I can copy and paste the error message, and then I’ll end up on Stack Overflow.' And Stack Overflow is great!
00:21:14.400
It’s a really great place for amateurs and novices because you find you’re not alone in experiencing your problem and you do typically find a solution; you get an answer—and that’s fantastic! Right? Except then there’s this whole kind of onboarding process to the culture. The first time you ask your question, the response you get is something like, 'It's difficult to tell what is being asked here; this question is ambiguous, big, and complete, overly broad, or rhetorical and can’t be reasonably answered in its current form.'
00:21:41.890
I’d say, 'Traveling Sam Seaborn, those are a lot of words that mean the same thing!' But secondly, you have that initial response of, 'Oh my god! This is like the most polite flaming I’ve ever received on a discussion board, and clearly I am not wanted here.' I’m not even asking the question in the right way—I don’t belong here!
00:22:11.840
The flip side is you finally find the one person who has the same problem you have. No one has answered their question; it hasn’t been updated in five years, and that pit of despair that you fall into at that moment, realizing that five years ago you would not have been alone but now you are, is really, really upsetting.
00:22:36.420
So, that sucks about Stack Overflow. You start to think of Stack Overflow as a community—it’s like a sanctuary, and everything—but those who arrive survive, or maybe they get eaten. Sometimes you get eaten; sometimes you ask a question in the wrong way, and the response is 'chomp.' You’re dead now, and there’s no coming back from it, and you just kind of want to crawl away and die.
00:23:01.770
But what actually happens is that novices, the people who need help the most, don't ask for help here because we don’t want to piss you guys off, and we don’t want to embarrass ourselves more than we already are. So we lurk, and hopefully, we find somebody else who’s braver than we are—who’s asked this question in the right way, in the right place, at the right time, with the right reputation points.
00:23:28.250
Just when you think you know, just when you think you’ve kind of got a handle on things, you basically understand what Rails is, you understand JavaScript, you basically understand how to find a gem that does the JavaScript thing that you want to do because you don’t know what JavaScript is. You discover that 'coder' is a moving target.
00:23:53.910
You started to think you were out of novice territory, and you find out, 'Nope, actually, they’ve moved the ball.' The goalposts are a little farther down the field now, and being an expert just seemed that much further away than it was five minutes ago. That is pretty daunting: you will never close the gap; you will never actually be you guys.
00:24:18.650
Which is okay, but also kind of sad. That’s something that I think is daunting for those of us who are new. It starts to make me wonder: are we approaching something like structural code inequality? Where we actually have a situation where it’s no longer just individual inequality, where it’s good to be experts and me to be a novice?
00:24:43.860
The societal goal among the elites of the coding world is to make this a permanent and immutable truth that there are experts who just become more expert, and there are novices who might become amateurs and amateurs who never really reach expert status. Every time you layer in a new framework or a new language, you add a whole new set of things that I've got to learn, and it feels that much farther away.
00:25:06.990
Sometimes I wonder if you’re not doing it to get further away from us novices. But, anyway, if that’s what you’re aiming for, I just think that structural inequality is generally an economically bad thing—and in the universe of open source communities would also be a bad thing.
00:25:34.550
Much like crossing streams in Ghostbusters, I mean the problem of course is there are many of you who are going, 'Yes, so what? You may be asking, 'Who cares? Not my problem that you don't know how to code. If you wanted to learn how to code, you could have gotten on the Commodore 64 at 12 and started teaching yourself C++ or BASIC. Come on!'
00:26:01.540
Fair enough. Technology is awesome, and we’re in a moment again where it’s starting to feel a bit magical. This is one of my obligatory robot video GIFs, and this robot has figured out how to do something really, really hard—it’s figured out how to jump on one foot sideways. This is not easy, the physics of understanding all the rest of it.
00:26:24.800
So tech is amazing, and this is a universe we should be getting into because it does create value. It is a place where we can lead innovation, we can find great jobs, and we can do cool stuff. We can make beautiful lovely things, like this hilarious jumping robot!
00:26:49.830
Then you’ve got this other kind of robot called Big Dog, which looks like a horse and can throw concrete blocks. I don’t know what it’s going to do; I think it’s going to loot, actually. And you’ve got backscatter, you’ve got PRISM, hooray! Then you’ve got people who don't want glass holes in their establishments because of creep shots.
00:27:16.050
This is the other part of technology that people are worried about. So, in thinking about this, I was looking through MIT Technology Review, and they were writing about robots doing something awesome. Robots are so great; robots are the things that actually make me feel like technology is still in this place where it is sufficiently advanced to be indistinguishable from magic—great quote from Arthur Clarke.
00:27:45.310
After a while, you start to wonder: are we talking about good magic or the dark arts? Are we talking about death eaters or people who are willing to be tolerant of us muggles along the way? The question I guess I have is: for you who think 'So what? What do I owe you as a novice coder? Whose side are you on?'
00:28:05.630
But I think, a little bit, there is this question of what will be the role of technology and the people who create technology? How will you bring us into that fold? But let’s take deep breaths; let’s not get too worked up. I’m not calling you Voldemort—he who shall not be named.
00:28:30.550
But everyone should still learn to code, right? I mean despite all of this—like evil technology, and it’s really hard! Stack Overflow kind of sucks, and is probably a terminus! Despite all of that, we should still be learning to code! But then again, who’s everybody? How much do I really have to learn in order to be fluent or conversational in this new language?
00:28:53.590
I think the truth is that most of the code schools out there now are teaching the amateurs to be at most conversational coders. We don’t really stick with it. We do the 12-week program, and then we go back to our regular jobs. But now we know something about how the internet works, how the web gets built, what the difference is between JavaScript and HTML and what HTML5 is. All of those things matter!
00:29:25.200
And I think that’s good; we shouldn’t actually be thinking of that as a failure of these programs to turn out engineers. They are actually aimed at that! Just like what David was saying this morning, it’s not so much about creating engineers as it is about creating some level of coders, and that can exist along a spectrum of expertise.
00:29:52.590
So what does that mean for you? It means you have to be more than just devs; you’re not just coders anymore. It means you’re now writing for a much broader audience. It means people like me are going to open up the source code and take a look. I’m going to tap the chassis and see what’s underneath it!
00:30:20.370
It probably means that solving problems goes beyond just writing beautiful code. That’s not the only problem to be solved; maybe dirty code is good enough to solve a problem! First of all, maybe it’s the problems that are the really big deal. Then we also have this universe of strategy and equality.
00:30:51.840
I don’t know how many people saw the expert video that was being passed around. It implied that people are incredibly annoying, and I’m not playing the audio of this. The problem with that scenario is that we’ve all been there. Whatever our jobs are, if you’re an expert in something, you have been treated this way by a client or a teammate.
00:31:17.480
You’ve been expected to somehow figure out how to make seven red lines perfectly perpendicular and green or transparent. You can have the argument that red lines are, by definition, neither green nor transparent, and seven lines cannot all be perfectly perpendicular to one another. Those are the laws of light and geometry; I can’t do much about that!
00:31:41.080
The problem I had with that is that it’s not being an expert. If that guy were being an expert, he would have backed up that conversation, saying, 'Let's talk about why seven red lines that are green and transparent need to be perfectly perpendicular.' Why are you asking me about that? What problem are you genuinely trying to solve that has arrived at that strategic idea?
00:32:01.620
It's fine! Let's figure out how to solve your problem. It might involve red lines, and we might actually discover an amazing fluke of innovation of how to make red lines green! But we have to understand what we’re trying to achieve first. So, I had a little bit of a 'Yes, we’ve all been there!' big sigh, and then also that guy’s being a bit of a jerk! He should have just said, 'Wait, what’s the real problem?'
00:32:29.920
I think what I’m getting at is your opportunity is to become customer-centric coders. I’ll talk a little bit more about what that means. First of all, we're all in this together; this is now your product team. It's pretty exciting to have these folks behind you. But in a way, that’s what I’m talking about.
00:32:50.630
This is about being in it together as opposed to everybody having their job and protecting that job vehemently and zealously. All of these people have a different set of skills; they all bring something to it. They are all, to varying degrees, technical, and yet their job is much bigger than whatever their particular skill set is.
00:33:12.780
So, the first thing to think about is that this is the new product team: these conversational coders. People like me who are thinking about business needs and end users' needs, thinking about what the problem is we’re trying to solve. Customer-centric coders are equally concerned about those things and are a hell of a lot more fluent in the code that will implement the solutions than I am.
00:33:33.530
Because we can actually have a conversation with each other at the level of the technology will work faster and will work better, that’s my basic hypothesis, and I think there is some evidence to back up that this is true! My dad worked for Intel. His last job was the 'product champion.' I’m still not totally sure what the hell that job is, but it means he could speak engineer and speak customer.
00:34:01.590
He rolled up his sleeves and assembled servers whenever they needed to fill an order and that was a valuable person in that organization. This is accepted as true in hardware because it’s hardware; everybody can use a screwdriver, and you can assemble a server if you just know how to plug in tab A into slot B.
00:34:24.200
But that has been absent in the world of software. The code sits in your mind; it’s like that video of programmers who say, 'We’re not saying anything.' You sit by yourselves with your headphones on and just code, and then at the very end, that’s all you say at the end of the day!
00:34:48.930
So, that’s not working. In this universe where I am conversational in code, I can help you brainstorm and problem-solve conceptually, and I can tell you what I need in a different way. That’s with strategic level, as opposed to at the execute-this-now-codemonkey level, and we can actually be in dialogue working together to do better work.
00:35:12.140
How do we prepare for that? For starters, I would urge especially this community, the Rails community, to keep up the good intentions and match it with really good behavior. There were several things that attracted me early on to Rails, not just that people were saying, 'It’s like pseudo code that works.' That idea was attractive!
00:35:30.390
But there’s a basic idea that code should make us happy. The thing is, when you first see a stack trace, that happiness dwindles! When you hit Stack Overflow and get admonished for posting your question in the wrong place, your happiness declines rapidly! Code stops making you happy pretty quickly!
00:35:52.900
So, the question I guess I’m trying to pose is what can we do better? More guys like that Locomotive CMS guy who helped me that one night. More people on Twitter saying, 'You don’t need to build that from scratch! There’s something that’s already built for that, and there’s a gem for it right here; go do it.' Those were the moments that made me keep going!
00:36:22.710
Let’s stay on with that positivity! We are nice! And code should make you happy! Don’t code alone! I love you guys, but this is also true of writing, too! Every week, I go and sit with someone who is also writing. We don’t have the same project; we don’t really even talk much, but we sit next to each other and pair right. Occasionally, we help each other out with something.
00:36:51.270
'How do you say the past tense of that word?' Those moments happen. That’s where matching up more amateurs and pros, more novices and amateurs, and people of mixed experience is good. Pair programming should become more and more important and more part of the onboarding process for novices.
00:37:20.480
Clarity counts. I know he talked about that this morning. The whole assumption that I am going to be able to open up 'bundle open gem' and know what’s going on in there assumes a lot of things. It assumes you’re being clear in the code you’re writing. As soon as I know enough to be able to read a gem—which at the moment, I don’t; I don’t think I’ve ever tried that. It scares me just like the Walking Dead scares me!
00:37:50.240
But we need to get away from vague statements; we need to be really concrete and clear for people who are trying to implement what you’ve built.
00:38:15.010
I was thrilled to go to Ruby Toolbox—you know how popular it is! You look at it, and it’s popular because it’s really clear how to use. So, yeah, I’m going to use it! But then you start to worry, 'Is this the best practice? Is this the most recent thing, or is this just the most popular thing?' You start to question your own intentions there.
00:38:40.050
There are other ways to gain that clarity. More pseudocode! Not more pseudocode! I tried to learn the hard way! More sketching. This was something Avi taught me when I was struggling with a particular assignment in class: write it out in plain English. One of the things you discover quickly is just how much you assume when you write something in English.
00:39:00.480
Having to break things down into this molecular structure sadept to figure out, 'If I want the wheel to turn, I’ve actually—oh God, there’s an axle! I’ve got to make it, and the axle has to turn this way; turn how much?' All of those things require you to become really concrete and really clear. Pseudocode and sketching helped a lot, and it helps those of us less fluent in the language see what you mean just as much as we can read what you mean.
00:39:29.880
No more empty readmes! I saw this the other day from Sam Rose about people applying for dev roles with GitHub profiles that have empty readmes or just whatever is the default. My favorite comment: pretty color markdown readmes with comment essays are the whole point of GitHub! I agree!
00:39:53.300
There’s a company called Made by Many, where Stewart works. They built this great CMS called Sir Trevor and pushed it onto GitHub, and I thought, 'Wow, it’s pretty!' I wanted to use it on my site. But there was no documentation! There was some documentation that was like, 'You know, just run bundle install' and everything you know about JavaScript.' Well, that's not helpful because I know nothing about JavaScript.
00:40:21.020
One of the things they did over time was create better documentation. This allowed other people to pull on it and make it useful. But that’s also a metaphor—it’s not just literally writing something in the readme; it’s a way of life we should embrace.
00:40:48.420
So, no empty readmes really means being constructive with your criticism. It’s not just that code sucks; that’s not the metric; it’s about giving people something to work with as part of the critique. It’s also about providing context to your code. When you push something, commit something, or post something to GitHub, explain it! 'What is it that you have done here, and why did you do it?'
00:41:12.540
This is one of those things I didn’t take seriously for the first six months: the importance of commit messages, until I tried to roll something back and had no clue about what I’d done. That’s important for all of us—not just the beginners, and not just when you’re actively working on a project.
00:41:36.390
When you create something for the community, having good comments and good context matters. Again, I grew up in a technology-friendly household, so 'Read the manual' was my mom’s rule. If I asked her what a word meant, she’d say, 'Check the dictionary!' I’m not telling you to read the code but prefer reading the manual.
00:41:58.900
I’m not smart enough about the code yet. When I looked in the code, I'd cry. Please don’t make me cry over code! Having good documentation matters. All of those rules for good writing apply to coding, too! It includes when your project is no longer best practice, when it is outdated, and when it is not working on a new build of Rails.
00:42:20.500
When it's out there in the wild, it is just another way to attract those of us who don’t know the difference between predator and prey, quite frankly. So, please don’t do that! This allows us to optimize the right thing! Again, instead of the TDD conversation, focus on optimizing things—yes, your code, yes, your process, yes, your documentation.
00:42:43.450
That way, we can spend most of our effort and focus on optimizing the products we are building for people. That’s the actual objective most of the time: building things that are valuable to people. There’s a question about agile.
00:43:04.300
In agile, we’ve got this working software over comprehensive documentation. I posted this thing; it works. Always be shipping! Great! I don’t need to go back now and document anything I did! That’s not really what they mean when they say 'over comprehensive documentation.' It means focus on getting the software working first, and then do your documentation.
00:43:28.420
Don’t document first and then make bad code! Part of thinking about agile is how we use this word. I work in an industry that thinks it knows what agile means, and it really, really, really doesn’t. Agile doesn’t have a brain! It thinks lean means cheap.
00:43:53.830
It thinks lean is like, 'Oh yeah, we’re totally lean! We only have three people on this team. We’re agile! We got this done in only four weeks instead of 12!' That’s not what this is about! My friend Bill Scott was a senior engineer at PayPal. He talks about how agile doesn’t have a brain.
00:44:19.990
I know I’m saying 'Document, document, document!' I don’t mean to the nth degree, or the way we used to do it with business analysts who would do specs for software, and it would be killing a forest to capture requirements for the piece of software—most of which were excessive and didn’t work together.
00:44:43.780
But I’d just say—balance is necessary when it comes to agile. I think there's another part to this. We can optimize the code, we can optimize the documentation, we can optimize the process, we can optimize the products, but who are we optimizing for?
00:45:04.540
Who are you guys optimizing for? I would suggest you have three customers: you have your product team, you have your community who will reap the benefits of the code you ship, and you have your end user who has to find something of value in what you built.
00:45:33.830
This is actually a world where I spend a lot of time talking to clients about. So I’ll now move into the world of analogy and share a project I worked on a couple of years ago. Well, I didn’t even work on it; we pitched it, we lost, and we deserved to lose.
00:46:02.800
Nike wanted a tracking study, and the company I worked for was in the midst of a buyout, and they wanted to do their tracking study as well. They had a methodology for doing customer surveys to find out how the brand was doing, and they had a point of view.
00:46:29.680
Their point of view was that this guy with a lawnmower was the most important guy in Nike's universe because he represents people who spend the most on Nike. I said, 'Nike doesn’t care about him! They like him; thank you for your money, sir! But they don’t care about him! They design for the guy on the right!'
00:46:55.690
They’re designing for that guy, not for that guy. The company I worked for suggested to measure how people thought about that particular brand from the perspective of the wrong guy. That would be useful for understanding what guys who wear Nikes to mow the lawn want in a product, but probably wouldn’t maintain Nike's status as cutting-edge.
00:47:19.970
So, that brand will start to dissolve under the weight of caring a lot about the guy who is just going to wear Nikes to mow the lawn. We need to pause a moment and ask, 'Who are we designing for?' Who is the business designing its products for? Then how do we design processes and tools to help this brand team make decisions that are targeted at the right problem?
00:47:45.940
Another great example would be Axe. Axe is often in a funny situation because their media targets an audience of 18-34 year-olds, a wide swath of men, but the people who actually use Axe are 15-18 year-olds. That’s okay because those 15-18-year-olds read the same magazines that 18-34 year olds read for the most part.
00:48:15.290
If we test whether this ad is funny or appropriate, we test it against 18-34 year-olds. But after age 25, you’re no longer using Axe. Your dad will index his humor against the audience you're not selling to, anyway. Oh, by the way! The person spending the money on Axe isn't the 15-year-old boy—it’s his mom.
00:48:44.110
She’s the one going to the store to buy Axe body wash for the 15-year-old because he can't smell himself! She’s got to decide how racy and sexy we can be in the advertising when it’s mom who goes to buy it. There are a lot of people to keep in mind, and every one of them has a different need, a different interest.
00:49:13.020
Some people are just giving you money; some people are using the product; some people are trying to figure out how to market this to all these moving parts, which is chaotic, and that’s the brave new world of customer-centric coders.
00:49:39.410
I’m sorry to tell you, but you have to balance all these different customers to be customer-centric! It’s complicated, but it’s worthy. This allows you to elevate what an expert should aim to be: consultative, smart, and strategic.
00:50:01.450
Let’s solve this problem together as opposed to worrying about what the deliverable looks like up front. So then, what? I come from a world where people worry a lot about making things people want, and making people want things is basically marketing.
00:50:37.400
But I think we should focus on making things that are valuable—making things that people may not know they want, but once they see it, they’ll think, 'Wow! This is amazing!' I remember seeing the first ads when the iPad launched.
00:51:02.560
These ads were just a person or a silhouette shot from here down at their perspective, sitting in repose with the iPad on their lap. I thought, 'Oh, I want to sit that way and look at the internet!' and that was it! A $500 purchase, just like that! That was because they'd made a product that was genuinely valuable.
00:51:27.660
We could be doing that! We could be doing this a lot more by writing code that creates value instead of writing code that just tests well or looks pretty! When we are all coders, I think this means we can all be awesome!
00:51:56.210
Because we’ve got these conversational coders who understand what's going on at a conceptual level; they can talk about the code, even if they can’t actually produce it. Then you have these customer-centric coders who understand the business needs and actual user problems.
00:52:20.130
Now, we can all be agents of Shields, an awesome team doing awesome things! That, of course, is the ultimate goal; at least that’s my ultimate goal! So I think at the end of all this, what you’re looking at is more awesomeness! I would like us all to just say 'Challenge accepted!'
00:52:49.560
And that’s it for me!
Explore all talks recorded at RailsConf 2014
+129