Read all of our show notes and find more information about us at podcastinit.com
Brief Introduction
- Date of recording – May 18th, 2015
- Hosts – Tobias Macey and Chris Patti
- Follow us on iTunes, Stitcher or TuneIn
- Give us feedback! (iTunes, Twitter, email, Disqus comments)
- Overview – Interview with Jacob Kaplan-Moss
Interview with Jacob Kaplan-Moss
- Introductions
- How were you first introduced to Python?
- So, we wanted to invite you on the show to discuss the keynote that you gave at this years PyCon. Can you tell us what you mean when you say that you’re a mediocre programmer and why that is such an important admission to make?
- What are some ways that we can change the tone of the conversation around programming skill?
- What do we gain by admitting to ourselves and others that we are not all phenomenal engineers?
- Where does the myth of exceptional vs terrible programmers come from? Can you provide some examples of times that you came in contact with this narrative?
- How do you think hiring tactics in technology companies contribute to this misconception and how can they be more accepting of average programmers?
- What are some ways that we can work toward eradicating the myth of the 10x programmer?
- Thinking about our industry’s problems retaining women and other undervalued groups, do you think the way many managers do performance reviews play a role? If so, how can we do better?
- Can you tell us about some other ongoing narratives in the technology industry that you find equally as damaging as our misconceptions around skills and knowledge? – Tobias
Picks
- Tobias
- Chris
- Jacob Kaplan-Moss
Keep In Touch
[00:00:14]
Unknown:
Hello, and welcome to podcast.init. We're recording today on May 14th 2015. Your hosts as usual are Tobias Macy and Chris Patti. And don't forget, you can follow us on iTunes, Stitcher, or TuneIn Radio. And please give us feedback. Leave a review on iTunes or Stitcher, contact us by Twitter, send us an email at hosts@podcastanditdot com, or leave a comment in our show notes. Today, we're interviewing Jacob Kaplan Maas about his keynote at PyCon 2015. Jacob, could you please introduce yourself?
[00:00:49] Unknown:
Yeah. Hi. I'm Jacob. I helped create Django about 10 years ago. I founded the Django Software Foundation. Today, I'm the director of security at Heroku.
[00:01:01] Unknown:
So, Jacob, how were you first introduced to Python?
[00:01:06] Unknown:
Let's see. I was working for I was working for a data storage company. It's quite a while ago, maybe 15 years ago. I was an intern, and I was in the QA department there. And we had this massive test suite written in Well, the whole the whole thing was written in Java. And for reasons I don't fully remember, it took it took ages to recompile and to rerun the test suite. And I I remember taking, like, an hour and and needing to go play, we would go play foosball while while we waited for the test suite to recompile and rerun again. I got really good at foosball.
Not so good at Java. And I, and I got really frustrated 1 afternoon with just how long it took to do anything, and I started casting around for, a faster way. I had sort of this vague notion that there must be some sort of way that type code interactively and get and get a response back. And I and I stumbled across, I stumbled across across Python, the Java implementation of Python. The first thing that attracted to me was was exact that was the the REPL being able to load up the compiled classes and interact with them dynamically and and fool around there, and I got really inspired. I rewrote our test suite in Python over the course of just a couple of days.
This was something that other, you know, it it had taken this the QA staff maybe 6 months to to write up all of these test suites and mostly because of just how how terrible and slow it was writing it in in Java at the time. And I was able to rewrite it in Python in about 2 days and ran faster. It was easier to contribute to. It was easier to maintain. Just kind of all around better, and I was I was pretty hooked from that moment forward.
[00:02:47] Unknown:
Very cool. I have to admit that when I worked in Java quite a number of years ago at this point, that was always 1 of my big frustrations was the fact that there is no REPL. You know, like, I I'm so used to learning languages by by REPL, by playing with things that, it was a great frustration.
[00:03:04] Unknown:
So that's interesting.
[00:03:06] Unknown:
You know, it was it was it was weird because I, you know, I don't have a a formal background in CS, and I don't think I knew what a REPL was at the time. I'm I'm trying to remember, but I think at that point, the only languages I knew were c and Java, and I don't think I'd been exposed to anything with a REPL, but I had this notion that I just had this idea that it couldn't it didn't have to be this way. Like, it was too this was too clunky. There's no way that this is just how it's done. And, you know, I I stumbled across Python. Later that I sort of, I think, learned that word, repl, and, like, you know, the background and the history of that idea.
[00:03:37] Unknown:
So we wanted to invite you on the show to discuss the keynote you gave at this year's PyCon. Can you tell us what you mean when you say that you're a mediocre programmer and why that's such an important admission to make?
[00:03:48] Unknown:
Yeah. I mean, so there's this thing that happens when you when you get known for something like Django. I mean, most people in the open source world who who know me know me because of Django. And and Django's been, you know, successful beyond our our wildest expectations. Today, you know, 10 years after open sourcing it, it's it's quite good. And there's this assumption that people make that the reason that Django is so fantastic is because I'm this really badass programmer. And people always talk about, you know, they'd always say things to me like, oh man, like I can't even imagine making something as awesome as Django, you know. You must be you must be super great at what you do and it's a weird feeling because I'm getting credit for I'm getting credit for something that I don't feel like I deserve. And this is different from impostor syndrome in that there are things that I'm that I am very good at, and there are things that I'm very proud of. And I I can attribute some of the success of Django to some of some of those things, but not my programming ability. When it comes to just writing code, I'm I'm at best average. I mean, I can do a fine job. I'm not I'm not bad. I'm not gonna I'm not gonna screw up horribly, but I'm also not this exceptional developer that most people think I am. My skills lie elsewhere.
And it was sort of that that was the germ of the idea that led into led into this talk is is about the assumptions that people make about me based on these couple of data points they have and how incorrect they are and casting about and talking to most of the other people that I know in in the software industry, the majority of us are not particularly exceptional when it comes to software skill. You you can do you can do a lot with a little bit of skill, and we have exceptional tooling and exceptional practices available to us that can help really help people with average skills produce exceptional products. And that was really that, you know, the idea that I was trying to reach for is this idea that software development is a whole suite and range of skills and that you don't have to be quote unquote ninja to be able to be, you know, really valuable and to be able to do good work.
[00:05:57] Unknown:
Absolutely. 1 of the things I really enjoyed about your talk was where you talked about how your strength was not in going really deep with something, but in understanding having a really good all around view and also understanding lots of different things and how they fit together and how that how, you know, how that made you successful.
[00:06:17] Unknown:
Yeah. I've always been kind of a, I've always been kind of a dilettante when it comes to learning skills. I love to learn new things but I don't particularly like to, practice them very deeply. So as a consequence, I have a lot of basic exposure to a lot of a lot of things. I know I know a little bit about a lot of things.
[00:06:35] Unknown:
Right? Yeah. Well, it's funny in our industry there used to actually be a title for that it was called the generalist but it's kinda fallen by the wayside, and everybody wants hyper specialists now. Although, it's moving in the other direction again, so who knows?
[00:06:48] Unknown:
Well, it seems like people want hyper specialists in all skill areas is the thing. They they they want people who are specialists at general skills, which is kind of an oxymoron and impossible to achieve.
[00:07:01] Unknown:
Indeed. Well, that's the thing is when we talk about, you know, when you see a job ad, you know, saying that it's looking for a ninja programmer, like and then you look at that company's product and, you know, if it's a typical if it's a typical web app, there's, like, at least a dozen things that you need to know from, you know, HTML, CSS, JavaScript to whatever back end language to the framework to SQL or other data stores, you know, operation skills. There's there's this entire, you know, suite of skills there and and this idea that 1 person is going to be exceptionally good at all of them is
[00:07:47] Unknown:
going back to what you were saying earlier about people saying to you that, oh, I can't imagine building something like Django is another misconception people have thinking that they need to be able to create this magnificent piece of software fully formed at the first go rather than really approaching it in the way that it always is and being an iterative building of things over time. You have to start with the core kernel of functionality. Just add to it and add to it over time until eventually you get to something, the scale and capability level of Django.
So it's just just another misconception that we have in our industry.
[00:08:28] Unknown:
Yeah. I mean, if you look at, you know, if you look at Django's contribution data, there's something around a 1000 people who have contributed something to Django. You know? And I'm I'm nowhere close to in the top 10 on that on that list. Might be in I might be well, I might be in the top 10 but barely. You know? And and and yet we sort of we tend to credit we tend to credit that to 1 to 1 person. We we have this we have this idea really deeply embedded into sort of our our psyche about this sort of genius inventor, and it doesn't release it doesn't mesh with the collaborative way that software, both open source and commercial, is produced these days, but it tends to we tend to still we tend to still believe it. You know, we're much we're much more invested in the sort of, you know, Steve Jobs, Elon Musk, you know, billionaire brilliant inventor inventor myth than we are with the idea of someone with a spare couple of minutes fixing a typo and multiplying that effort across thousands of people.
[00:09:32] Unknown:
You know, it's it's really interesting that you say that because I think that myth is is is equally mythic in other areas as well. Right? I mean, like, you mentioned Steve Jobs or Elon Musk. You know, they had I forget who it was who said, we build upon the backs of giants. I mean, each each 1 of those inventors, I mean, even Albert Einstein or Thomas Edison, you know, they built on generations of scientists or whatever or whatever field they were working in before them who paved the way for them to make these great discoveries. And I feel like software is exactly the same way. Right? Like, I mean, even if you really are the lone hacker working till 2 o'clock in the morning in your garage, creating something amazing, you're using tools that were created by other people who that, you know, you're leading on this ecosystem that was created by a cast of 1, 000 probably.
[00:10:27] Unknown:
Exactly.
[00:10:30] Unknown:
So what are some of the ways we can change the tone of the conversation around programming skill?
[00:10:37] Unknown:
I was talking about this with a colleague of mine at Heroku, Crystal, who runs our, our our support team. And he was talking about he made a really good point which was that 1 way we can get at this is by changing the types of stories that we tell. So we so we tell these stories about we tell stories about about, you know, about Steve Jobs, about Linus Toribalds, about about the the the genius, the the the lone wolf, you know, we tell these stories about individual success, and we we can change that narrative. We can start telling stories about about collaborative success, about a group of people gathered together, coming together as a team and producing something producing something great sort of out of out of that collective skill and that and that and that sense of collaboration. And we and we can, you know, we can celebrate those types of successes, those sort of quiet, you know, quiet, steady improvement over a long period by a large by a large group and sort of celebrate the the work that it takes to keep a group of people executing.
And, yeah, I think that that's I'm thinking about that a lot. I think that starting to tell those types of stories more can really help make our community feel more engaging and more welcoming because it it sends a message, you know, not that you have to be brilliant and and and and, and a and a lone wolf, but that you can, you know, you need to you you need to figure out how to fit into a team and be part of a group. And I think that, you know, I think that there's something really powerful about this concept of of being part of a team. I mean, we have this, I mean, you know, we have this hunger for for sports as a as a culture. And and, you know, we're watching these team sports and thinking about this idea of the whole as as more than the sum of its parts. And I think we can apply those kinds of narratives to the the stories we tell about software. I think we can start to get to a healthier place. Where does the myth of exceptional versus terrible programmers come from? And can we provide can you provide some examples of times you came in contact with this narrative? Yeah. Where does it come from is a difficult question. I think there's a lot bound up in it. I think 1 aspect of it aspect comes from there there's sort of a there's a there's a running narrative in in American culture about this sort of this this myth of American exceptionalism, you know, pulling yourself up by your bootstraps, you know. Anybody can do anything if you just work hard enough. It's kind of this, this Protestant work ethic that's embedded in our culture. Jung might call it the collective unconscious, not dangerous ways with with software because we don't we we are so terrible at measuring our work when it comes to when it comes to software. I mean, I I mentioned this in my keynote, like, what metrics do we have when we say someone is a good programmer? Like, what are we measuring?
Are we measuring lines of code written? I mean we know that that's a terrible metric for for productivity. A line of code is neither good nor bad. Are Are we measuring, you know, story points? You know, what's a story point? How do you, you know, can you collaborate or or can you correlate from 1 project to another or even from 1 day to another? Like, how are we measuring when we say someone's really good, we're measuring that. I I don't think we're measuring anything at all. I think we're we're just just sort of we have this, like, we're just sort of making these assumptions and making up these stories about people but we really have a way of actually measuring what what good is and so we have this we have this 1 idea of of these geniuses that we're sort of we think they're more common than they are because of because of the the the sort of root myths in our culture, and then we we don't have any tools to measure anyone's performance. And so we we just sort of try to fit them to a narrative, stereotype, and and either they fit into this idea of the genius or or they don't. And so we assume if they're not a genius, they they must be the other thing. They must be the idiot, and and we don't have a we don't have a complex way of thinking about skill and software.
But so that's where I think it comes from although there's probably a lot more going on there. Times when I've run into it, think about that for a second. Well, you certainly see it in you certainly see it in recruiting and in hiring. I mean, I tend to focus in on that, you know, know, words like ninja and rock star because I think they're just so silly to apply to to what we do. I mean, we, you know, we sit in front of a computer all day and click at a keyboard. It's very different from what a rock star does. And, but, yeah, we, you know, we put these we put these things in our job ads, and they and they tend to be really off putting people who are are newer in the industry or don't match the stereotype of what a, you know, quote, unquote ninja programmer is supposed to look like or dress like or act like, and it tends to, you know, keep those people from even thinking that they might be, they might be qualified for for that job.
[00:16:02] Unknown:
The whole the whole, gestalt around hiring in our industry is so strange speaking about that. When you look at the the requirements that the average job lists and they're like, 10 years experience in Ruby on Rails. It's like Ruby on Rails hasn't been around for 10 years. So it's a physical impossibility for someone to have 10 years experience but it speaks to that kind of like, you know, they don't want just want you to know something. They want you to be an absolute subject expert on everything out of box. It's kind of crazy and I think it's really daunting for newcomers.
[00:16:36] Unknown:
Yeah. I mean we are just terrible at hiring and I include myself in that you know I'm, I'm a hiring manager at who I've hired a number of people and nothing, nothing freaks me out more than than than trying to hire. It's again, we have no tools to measure what we do, and so we are we are just we are just bound up in our own biases in making this decision in a very nonscientific and very, and very rough way. And I I think we do it I think we do it about as as well as anyone can at at Heroku. I think we've got some checks and balances in place to try to make sure that we aren't hiring on the basis of of of bias and quote unquote gut feel. But man, it's super tough and as an industry, we are so we are so immature when it comes to how we how we think of skill that that it's it's amazing that we are able to make good hires ever at all.
Indeed. Or actually, you know, now now that I've said that, I actually I wanna take that back. I think I'm wrong about that. I think that I think the fact that most people are kinda average at at things is actually what's saving us there because we we think that we're hiring for exceptionalism, but what we get is average because most people are average, and that actually turns out okay. So we're we're saved by the fact that even though we miss we miss the mark on hiring exceptional people, we get people who are fine at their jobs and they do fine and they're able to contribute in just a in just a fine way. So our our our own lack of understand it's not a surprise that we that we that hiring usually turns out alright, but we are missing the mark if we're if we're actually, you know, quote unquote trying to hire a a players all the time.
[00:18:27] Unknown:
Right. You know, it's it's really interesting that this comes up because I mean, I don't know if you've ever listened to, Saran Yiparak's podcast, the CodeNewbie podcast, but it's it's all oriented towards helping people get their first job in the industry, learn how to program, etcetera, etcetera. And 1 of the things she keeps going back to is don't be daunted by ridiculous job requirements, you know, like actually talk to people, actually get a sense of what will the job be like to do, what kind of work would they actually expect you to perform day to day in this job and and don't get scared away by these, you know, 20 years experience, you know, programming particle accelerators at CERN. It's it's almost meaningless.
[00:19:12] Unknown:
Yeah. You know, I, I struggle this with this when I write job postings because on the 1 hand, I wanna sort of make a laundry list and put sort of all the things that I think might be might be intriguing and might make me want to interview a candidate. But then when I step back at the end and I look at the list of things it's like there's no way that any 1 person knows all of these things. So you know I've started doing things like saying hey if you know if you know at least 70 percent of this stuff, you should go ahead and apply. Or you should you should know some of these things and be excited to learn the rest. That's another 1 that I've that I've used to sort of say, like, hey. This is a wish list, not a not a hard set of hard and fast requirements. Like, you know, if you kinda match this, we should and, you know, hopefully that balances those things. But, yeah, like, we tend to sort of we write these job ads, like, we're I don't know.
Like, we're dreaming about some some mythical person who's gonna be able to do everything all at once, and we're never actually gonna find that person. Yeah. And 1 thing that I've seen a few articles recently about that's
[00:20:15] Unknown:
an attempt to address some of that is having more of a a trial period. So basically having a project based interview cycle. So rather than having somebody come in and do the entire interview all in 1 day, they say, okay. Here's some materials. Here's some information about the kind of stuff we're doing. Why don't you work with us a little bit on this 1 small little project so we can see how you work and the kind of things that you actually know, you know, when you're when you're really working on something, kind of things that you actually know, you know, when you're when you're really working on something. And then we'll use that as our basis to determine if we wanna actually bring you on full time. And that's sort of going back to the old apprenticeship mindset that we have recent you know, in recent years moved away from. And I think that's, to a degree, detrimental to our industry and a number of other industries as well. But there's definitely been a little bit of a renaissance around that idea.
[00:21:05] Unknown:
Yeah. And that's similar to what we do at at Heroku. We do what we call a starter project, which is a sort of couple day, you know, intensive working together project, try to, you know, simulate what it's like to to actually be colleagues. The problem is, you know and I think that that works better than the adversarial interview process, but it's still problematic that, you know, it requires that the candidate have the, you know, the ability to take a couple, you know, a couple days a week off from their normal their normal work and do what's usually some an unpaid engagement on the basis of maybe getting a job. And so there's a lot of privilege bound up in there. You need to be financially stable enough to be able to take some time off from your current job. You need to have a current job that won't fire you for missing a couple days. I mean, you know, back when I was before I I was lucky enough to work in software, I definitely had jobs that if, you know, I was an hour late, I'd get fired, let alone taken a couple days off.
So the the, apprenticeship style interviews certainly help with kind of bias, but they also introduce another 1. This stuff is is hard and it's it's complex.
[00:22:16] Unknown:
Very good points. Thank you for bringing those up.
[00:22:19] Unknown:
I will say though that I I I very enthusiastically recommend this kind of approach because, I actually, I just went through a job transition 5 or 6 months ago now, maybe it might be a little more. But in any case, 1 of the companies that I was interviewing with did that, and I thought it was so incredibly beneficial. They ended up not choosing to make me an offer, but they because of that apprenticeship program, I ended up realizing that that was the right thing for me as well as for them and I felt like, you know, as opposed to this crazy hiring process of, you know, you go through the interviews and then it's like this black box and now you hear back or you don't and you're always wondering more exactly what happened. I feel like with the project based approach, it's like, well, you know what happened. You know what I mean? Like my skills were were measured accurately based on what I did and and I felt like it was as as as educational and as satisfying for me as it was for them. So I I really like that approach.
[00:23:20] Unknown:
Yeah. I think, you know, like I said, it's the it's it's what it's what I use, it's what we use at Heroku. So I can't be too critical of it because I I do it, but I do think it's important to to recognize the the, you know, the imbalance there and and the fact that it it's just may not be possible for certain types of candidates. You know, I try to Absolutely. I try to explain it to candidates as as an option and say, you know, if you can't make this work, we'll do something else. But even there's kind of a power imbalance. Right? Because I have the job, they need the job. So I'm definitely sitting in the in the power seat when I'm when I'm having those kinds of discussions. And so it's it's difficult. You know? We have to these are the types of things I think we need to be thinking about and be really conscious of. The, you know, the the the essential question when it comes to hiring is, you know, are we is is the interview process, whatever that looks like, what is it measuring? Is it measuring your ability to to deliver at the job, or is it just measuring your ability to get through the interview process?
You know, if we because if we do it wrong, it's gonna end up being something like the the SAT test, which is utterly not predictive of performance in college, performance after college. The only thing that the SAT predicts is your performance on future SAT tests. And so if our hiring process is measuring the wrong things, we're gonna end up hiring people based on their ability to interview, not based on their ability to actually, you know, contribute and be part of the team. And all of these types of biases that we introduce into those processes run the risk of selecting for the wrong, criteria.
I let me give you an example. When 1 of the things that that we do at the end of the starter project at Heroku is some sort of, like, you know, what we used to call it a presentation. We used to have we used to have candidates sort of, you know, give a presentation on what on what they worked at. And over time as as Heroku grew, the number of people that would come to these presentations got more, you know, got bigger and bigger and and at at certain point, there were, you know, a few dozen people, like, coming to a presentation of this candidate's project. And, you know, suddenly we realized that, wait a minute, like, we're we're we're now starting to select on the basis of someone's ability of someone's public speaking ability, which from almost all of our job roles is is somewhat irrelevant. Like, you know, how often in in your in your programming job do you have to get up in front of 20, 30, 40 people and give a really stressful presentation, like most of the time if that's not something you're good at, something you enjoy, you just don't do it. And so we we dropped the the name presentation, we scaled it back really far. I I call it a debrief now, and it's usually, you know, it's it's a handful of people, you know, half a dozen at most, and no slides, you know, very very informal because, again, like, what are we selecting for? Do we are we trying to hire people based on their ability to deliver a presentation? You know, maybe if there's some sort of developer evangelist, then that might be appropriate. But for the vast majority of the role, that's a really inappropriate signal to be selecting for. And, yeah, we were sort of unconsciously doing it because we weren't quest we weren't looking at what was happening to our process as it but as it scaled. So I I think these are the types of things we have to constantly be looking at and constantly be asking ourselves, are we what are we actually measuring here? What are we looking at?
[00:26:50] Unknown:
So what are some ways that we can work toward eradicating the myth of the 10x programmer?
[00:26:58] Unknown:
I wish I knew that. I think it's I think it's pernicious, and I think it's gonna I think it's gonna stay with us for quite a long time because it taps into something it taps into something really deep, something we wanna believe about about the world and, you know, bluntly, we wanna believe it about ourselves. I think the people who are most attached to this to this idea of exceptionalism are people who want to believe that they are, that they are exceptional, or that they could be exceptional if they're not now. So I I think we need to keep pushing back on it. We need to keep telling people who we need to keep telling people that they are welcome regardless of what their skill level is.
We need to work towards a much more nuanced understanding of what of what skill means and celebrate other types of skills, like project management is incredibly important to complex work. Design, product management, you know, that many there there are some does it go into delivering great software besides just writing the code? I think we need to work on celebrating those things as much as we celebrate the cranking out code aspects of our jobs.
[00:28:17] Unknown:
Absolutely. And I think, I mean, you know, even even beyond what you're talking about as far as people's job functions, I think sometimes celebrating people's ability in in terms of like their personality and the skills that that personality embodies. Right? Like in in my experience, there's always kind of 1 I know this is a real oversimplification, but there's always 1 zen guy on the team. You know, the person who, it doesn't matter. The building could be burning down. There could be explosions happening. People screaming and this guy is just calmly sort of walking along. Like okay, let's get to the exit. Everything's fine. And that having that sort of that kind of person around can be such a benefit.
[00:28:59] Unknown:
Yeah. I mean all the, all the studies on all the studies on diverse teams, show that diverse teams outperform homogeneous ones. And a lot of that comes down to different different mindsets, different backgrounds, you know, different sort of a different set of tools that people bring to the table. And yeah. That that difference that difference in in in in mindset, that calmness is incredibly important. You know? I I think about that a lot, you know, working for essentially an operations company. Right? Like, being calm during a crisis is pretty critical skill skill when you work for, you know, a company that operates a a cloud as as big as the ones we do.
But I think most companies are would be suited by that type of calmness. You know everyone faces a crisis at some point. So yeah. You know, definitely sort of selecting for a wide a wide range of backgrounds and a wide range of skills helps us be prepared for the events that we can't we can't predict.
[00:30:03] Unknown:
So following on from the last question in our last discussion here, thinking about our industry's problems relating with, relating, pardon me, retaining women and other undervalued groups, Do you think that the way many managers do performance reviews play a role? And if so, how can we do better?
[00:30:23] Unknown:
I think performance reviews are are pretty awful at least the way that they're normally practiced. This idea of the yearly performance review. Man, if you're not if you're not talking with your manager about if you're only talking with your manager about performance once a year, something is seriously wrong. I mean that needs to be a regular ongoing that needs to be a regular mission. Something that happens continually and all the time. It should you should never be surprised by a performance review. In terms of how it, you know, how it impacts women, I'm I'm definitely not an expert there. I would point to, I just read a really fantastic book called, What Works for Women at Work.
And it really goes into a lot of the a lot of the biases and struggles that that women in particular face face at work and and and talks about, talks about strategies that women can can use to sort of work against the work against those problems. And I found it incredibly good reading, you know, as someone who's trying to be who tries to be supportive of women in in tech. It helps me to understand, you know, the challenges that they face and to see the types of patterns that I may never be able to see directly and firsthand as a man, but that are are are things that, you know, are are very real.
I suspect that performance reviews play into that retention in in some way because they're super busted. But I I don't know I don't know specifically.
[00:31:49] Unknown:
Well, I think part of what I was thinking of was exactly what you just said when when asking the question in terms of a a common sort of anti pattern that I see is exactly you just said. The yearly performance review where you don't hear anything, anything, anything and all of a sudden your review comes, you know, dropping down at you like a like a brick to the head and you find out that your manager has not been happy with with, you know, whatever might have happened during the course of the year that you heard virtually nothing about. And I, you know, I I can only imagine that leads to unhappy people.
[00:32:25] Unknown:
Yeah. 1 of the 1 of the pattern that the authors talk about in in what works for women at work is what they call the the prove it again pattern, where women and other marginalized people, in in in our industry need to repeatedly prove their own their own worth in a way that men don't. A man who is successful wants sort of that that success tends to be remembered, whereas women need to sort of continually prove their own their own worth. And I suspect if you are only if you're only having a performance review once a year, it's very easy for each review to be, you know, a struggle to prove success. Whereas if you whereas if you have or regular cadence of recognizing success, it's easier for someone to overcome that that pattern of needing to, you know, prove their success over and over again if they have a repeated opportunity to point, this is what I did well this week. This is what I did well this week. This is what I did well this week. And kind of build build on that that narrative of success over a long period of time.
[00:33:30] Unknown:
Can you tell us about some other ongoing narratives in the technology industry that you find equally as damaging as our misconceptions around skills and knowledge?
[00:33:40] Unknown:
Well, 1 that I really hate is the way that we think about the the sort of vent the sort of venture capital approach to forming businesses. We we we talk about from the very beginning we talk about an exit strategy. Like, all all when we're at the stage of a of a of a startup and the only thing that exists is a is a pitch deck, we're already talking about exit strategy. Oh, I'm gonna sell to Google. Oh, I'm gonna get bought by Facebook. Oh, you know, and it's it's all about take a bunch of cash, push really hard, you know, burn it out and then maybe get bought. And you know sure if that's successful that can make you a ton of money but man is that really the only the only measure of success that we have? I I really hope not. There's, I would like to believe that businesses can be formed that grow slowly and make make money over the long term and provide a healthy work environment for employees and provide a product that people like and that is, you know, valuable to to our our world. And this sort of get rich quick scheme of venture capital really doesn't, allow for those types of businesses.
I'm really interested there's a new sort of investment firm called indy.dc, which is all about trying to build these longer term sustainable businesses. And I'm I'm really excited about that type of that type of model of funding and investment, and I'm hoping that it catches on and it's successful.
[00:35:14] Unknown:
Yeah. I've definitely seen a number of instances where people have referred to smaller companies or, Yeah, I've definitely seen a number of instances where people have referred to smaller companies or 1 person companies as a quote unquote, lifestyle business and using that as a derogatory term where I personally view it as being a good indicator of personal success, because it means that somebody is able to be financially independent and do something that they're really interested in rather than having to tie themselves to the goals of a corporation that they maybe philosophically disagree with.
[00:35:46] Unknown:
I remember back during the first.com bubble hearing somebody talk about what they call the, the the the Sunday test. And they were trying to decide if they want if they were gonna invest. This is a a VC talking about whether he was gonna invest in a company and he said he would he would swing by the company's offices on Sunday and if the parking lot wasn't full, he wouldn't invest in the company. And, you know, when I was, you know, when I was 19, I think it was around when I heard that, you know, my thought was, yeah, of course. Like, we should really just be working our asses off and and and, you know, struggling really hard to to, you know, you have to try really hard and maybe you you you make that maybe you make those 1, 000, 000 of dollars and and maybe you don't but it's worth the risk.
Now now in my thirties it's like, yeah, you know, I don't wanna work on Sunday. No. No. I like my weekends. I like my evenings.
[00:36:37] Unknown:
Absolutely. And it's and that's a healthy attitude. Right? Like I was just thinking as you were saying that cue all the current discussions in our field around, you know, burnout and other mental health issues from people who work at 24 hours a day, 7 days a week. Humans were not designed to deal with ongoing stress like that. We need breaks. We need the opportunity to give our brains a rest or at least do something different. I mean, it's just it's that is an unsupportable lifestyle and I think the industry on the whole is starting to learn that. The whole startup culture is still kind of in this crazed like work is life mentality, but I think there are a lot of people in a lot of places and not just those of us who are getting older who are coming to realize that this is not the way to run a ship.
[00:37:28] Unknown:
Yeah. It was a great there was a great study on on on crunch mode on sort of make, you know, having people work very long very long schedules. I I forget the details but it was it was something on the order of, you know, 1 1 week of 60 hour 1 60 hour week is more productive than a 40 hour week, and 2 is as well. But once once you get past about 2 weeks of crunch mode, performance just drops off sharply. And over time, it drops below the 40 hour 30 hour success rate. And so, you know, what happens is if if you're seriously, you know, you've got a deadline in a couple of weeks and you need to go into crunch mode to meet the deadline, as a strategic decision that can be that can be healthy ish. But as a as a long term as a long term process forcing people to work these incredibly long hours is actually less productive over a long period of time than working a more sustainable schedule.
And, you know, that that definitely matches my, you know, my experience of sure. I'll crunch now and again to meet a deadline is something that something that happens as as a business. We're often beholden to circumstances not entirely under our control and yeah. Sometimes you sometimes you make a mistake and commit to a timeline that's a bit too aggressive. But as a regular thing, this idea that you should be working every waking minute, man, it's you're you're actually you're actually damaging yourself. You're you're and and you're damaging your business too. It's bad it's bad for business. You're actually delivering less over a long period of time than you would be if you were working a more sustainable schedule.
[00:39:02] Unknown:
Yeah. And go and going back to your keynote as well, you mentioned not just working for your primary occupation, but also working in your evenings and weekends to contribute to open source projects and continually be learning new frameworks and new methodologies and always feeling like you're falling behind if you're not constantly working on something is another thing that really drastically contributes to burnout. And I've definitely, you know, found myself susceptible to this notion as well that if I'm not constantly reading another book about a, you know, new way to build APIs or something, then I'm wasting my time because, you know, otherwise, I'm gonna end up falling behind and not be as marketable in 5 years if I'm not constantly on edge. Yep.
Tobias, why don't you take it away with the picks? Sure. So my first pick is relevant to our conversation today. It's a website and platform called True Ability, and it is a different way of going about trying to apply for jobs. So rather than sending your resume into a black hole and hoping that you get a callback, it's more focused towards operations folks. But what they do is they give you a prebuilt virtual environment. So they give you a virtual machine, has some particular problem with it or some particular thing that you need to do. They give you the, you know, list of things that they want done. And then they record your entire SSH session on that virtual machine. And then once you're completed with that, that gets sent to the hiring manager of the company that posted that particular job opportunity.
And then rather than basing their decision of whether or not they wanna continue the conversation on just what marks you happen to have on your resume, they can see how you actually performed and behaved in a pseudo real environment. So that's my first pick. My next pick is Manjaro Linux. It is a Linux distribution that's based off of Arch, but it adds a lot of extra polish on top of it. So they have a graphical installer and just a really good default setup to make it easier to get started in the Arch world. They also maintain their own package repos so that you they can ensure a little bit more stability than the default Arch repos, but you still have full access to the Arch user repositories and all of that. It's still a rolling release. So I've been greatly enjoying using that as my primary Linux distribution.
My 3rd pick is a company called Vultr, v u l t r. And in a lot of ways, they're very similar to DigitalOcean in that they provide VPS. They're backed by SSDs. But they have a little bit little bit different pricing model in terms of what you get for your money. And they also have a little bit more choice in terms of the types of images that you can spin up. So started playing around with that recently. Definitely worth a look if you're a fan of DigitalOcean because their $5 plan actually gets you, I think, 3 quarters of a gig of RAM versus the 512 you get on Digital Ocean. So just another platform worth checking out.
And my last pick is a board game called Mage Wars. And it's very interesting. I haven't had a full game yet, but I've played it a little bit. And you have a board, and you have a you have a mage that you place on the board. And then you can summon different creatures and spells. And the whole object of the game is to try and beat the other mage on the board. You can actually it's by default a 2 player game. But if you get 2 sets, you can actually make it a 4 player game and just a lot of really interesting game mechanics to it. It has a little bit of a deck building aspect to it, like with Magic, but it doesn't have the the same aspect of magic where you always have to be buying new decks and new decks to be able to keep up with the current state of the world. You can just buy the core set and leave it at that, or you can get a couple of expansion sets if you really want to. And it just adds a lot of really interesting dimension to the game.
So Chris, why don't you go ahead?
[00:43:12] Unknown:
I'm gonna kick it off with a beer pick, which I because I like beer. This last weekend, we had some friends up and he brought a bottle of k's for creek from Brooklyn Brewery and it's a style of beer that I had never had before called creek and it's basically a beer that has had fruit, introduced to it during the brewing process. And this beer is really It's dark. It's it's spicy and cinnamon, it's got like notes of citrus in it, it's really complex, really tasty, everybody enjoyed it, even my wife and you know a dark beer has to be good for her to like it. So definitely recommend that.
The next thing I wanna recommend is Trello and I know a lot of people have probably already seen this. It's not new, but if you haven't seen it and you need to collaborate with a bunch of people on a complex task and you need very simple task tracking that's like basically kinda effortless, you don't need something like a Jiro or like a bug tracking system, you just need a cork board that you can track who's doing what when on, This thing, it nails it. It is super simple, super accessible, great for collaboration, and they even have a nice CLI for it. I really like it a lot.
My last pick is a another podcast called, Dan Carlin's hardcore history. If you're a a history dabbler like myself, I I can't consider myself to be an expert or even a real student hardcore student of history. This podcast is is really, really top notch. He he just finished a 6 part series on World War 1 called Blueprint for Armageddon and it was just amazing. And if you even if you're, you know, not really interested in history but you're interested in you like you you follow current events, it is just amazing to me after having heard this series, How much world war 1, the the echoes of that conflict still resonate to this very day in world politics and in in all kinds of other ways.
So great podcast. If you like history, I hardly recommend it. Jacob, what kind of picks do you have for us?
[00:45:25] Unknown:
Yeah. I got a few things. The first is a new, a new book for people who want to learn Python and Django. It's called Hello Web App. It was written by Tracy Osborne, who was, who who herself taught herself to code about 4 or 5 years ago. And she's got kind of a design background, not a software background. And and Hello Web App is written, sort of specifically for non programmers, people who wanna be able to build their own sort of web product, their own startup without much, or any programming background. There are a handful of Django tutorials out there.
This is 1 of the best that I've seen. I really I really recommend it. It's very hands on. It's very, it's very sort of actionable. It's extremely well written. I have a pdf. The physical book hasn't arrived yet, but it looks gorgeous. I'm looking forward to seeing the physical book as well. I think it's gonna be really pretty, and this is probably gonna be my go to pick for people who ask, the best way to learn to learn django. I have a couple of picks about women in tech. The first I mentioned earlier in this podcast was what works for women at work. I think this is a fabulous reading both for women who want to know some know about the sort of the patterns that they're likely to face in in in tech and in in other industries as well. And then also for men who want to be supportive and want to try to work on diversity in our in our industry.
The other is a, a similar report about, Why Women Read Tech written by Sue Gardner who works for Wikimedia and has been involved in women in tech in a long time. And she has pulled together an astounding amount of research. I think something on the order of a 100 different studies about why why women, leave tech, and it distilled it down into about a 30 or 40 page in progress, Google Doc that she's published for people to, read and take a look at, and it's pretty, it's pretty great. My last pick is, a browser extension called library extension. There's a Firefox and a Chrome extension, and it adds on any Amazon page. It adds a little, any Amazon book page that's a little sidebar that tells you whether whether that book is available in your local library.
And so when you are browsing to see if you want to buy a book, it will tell you if it's available in your library. There's even a button to, you can click on it to to reserve the book and then go pick it up at at your library. And that is as someone who likes to read and doesn't like to spend a obscene amount of money on books, I find library extension
[00:48:25] Unknown:
Great. Well, thank you very much for taking the time to speak with us today, Jacob. And for anybody who wants to follow you and the different kinds of things that you're up to, what would be the best way for them to do that?
[00:48:35] Unknown:
Yeah. I'm Twitter is the best way. I'm jacobian, jacobian on Twitter.
[00:48:42] Unknown:
This has been fantastic and, sometime I would love to have you back on the show to talk about obviously, you can't, you know, reveal all the secrets, but I would love to talk to you about your work at, Heroku with security and perhaps about Python and security in general?
[00:48:58] Unknown:
I'd love to. Yeah. There are very few secrets actually.
[00:49:02] Unknown:
Excellent.
[00:49:03] Unknown:
Alright. Well, thank you again, and I hope you enjoy the rest of your day.
Hello, and welcome to podcast.init. We're recording today on May 14th 2015. Your hosts as usual are Tobias Macy and Chris Patti. And don't forget, you can follow us on iTunes, Stitcher, or TuneIn Radio. And please give us feedback. Leave a review on iTunes or Stitcher, contact us by Twitter, send us an email at hosts@podcastanditdot com, or leave a comment in our show notes. Today, we're interviewing Jacob Kaplan Maas about his keynote at PyCon 2015. Jacob, could you please introduce yourself?
[00:00:49] Unknown:
Yeah. Hi. I'm Jacob. I helped create Django about 10 years ago. I founded the Django Software Foundation. Today, I'm the director of security at Heroku.
[00:01:01] Unknown:
So, Jacob, how were you first introduced to Python?
[00:01:06] Unknown:
Let's see. I was working for I was working for a data storage company. It's quite a while ago, maybe 15 years ago. I was an intern, and I was in the QA department there. And we had this massive test suite written in Well, the whole the whole thing was written in Java. And for reasons I don't fully remember, it took it took ages to recompile and to rerun the test suite. And I I remember taking, like, an hour and and needing to go play, we would go play foosball while while we waited for the test suite to recompile and rerun again. I got really good at foosball.
Not so good at Java. And I, and I got really frustrated 1 afternoon with just how long it took to do anything, and I started casting around for, a faster way. I had sort of this vague notion that there must be some sort of way that type code interactively and get and get a response back. And I and I stumbled across, I stumbled across across Python, the Java implementation of Python. The first thing that attracted to me was was exact that was the the REPL being able to load up the compiled classes and interact with them dynamically and and fool around there, and I got really inspired. I rewrote our test suite in Python over the course of just a couple of days.
This was something that other, you know, it it had taken this the QA staff maybe 6 months to to write up all of these test suites and mostly because of just how how terrible and slow it was writing it in in Java at the time. And I was able to rewrite it in Python in about 2 days and ran faster. It was easier to contribute to. It was easier to maintain. Just kind of all around better, and I was I was pretty hooked from that moment forward.
[00:02:47] Unknown:
Very cool. I have to admit that when I worked in Java quite a number of years ago at this point, that was always 1 of my big frustrations was the fact that there is no REPL. You know, like, I I'm so used to learning languages by by REPL, by playing with things that, it was a great frustration.
[00:03:04] Unknown:
So that's interesting.
[00:03:06] Unknown:
You know, it was it was it was weird because I, you know, I don't have a a formal background in CS, and I don't think I knew what a REPL was at the time. I'm I'm trying to remember, but I think at that point, the only languages I knew were c and Java, and I don't think I'd been exposed to anything with a REPL, but I had this notion that I just had this idea that it couldn't it didn't have to be this way. Like, it was too this was too clunky. There's no way that this is just how it's done. And, you know, I I stumbled across Python. Later that I sort of, I think, learned that word, repl, and, like, you know, the background and the history of that idea.
[00:03:37] Unknown:
So we wanted to invite you on the show to discuss the keynote you gave at this year's PyCon. Can you tell us what you mean when you say that you're a mediocre programmer and why that's such an important admission to make?
[00:03:48] Unknown:
Yeah. I mean, so there's this thing that happens when you when you get known for something like Django. I mean, most people in the open source world who who know me know me because of Django. And and Django's been, you know, successful beyond our our wildest expectations. Today, you know, 10 years after open sourcing it, it's it's quite good. And there's this assumption that people make that the reason that Django is so fantastic is because I'm this really badass programmer. And people always talk about, you know, they'd always say things to me like, oh man, like I can't even imagine making something as awesome as Django, you know. You must be you must be super great at what you do and it's a weird feeling because I'm getting credit for I'm getting credit for something that I don't feel like I deserve. And this is different from impostor syndrome in that there are things that I'm that I am very good at, and there are things that I'm very proud of. And I I can attribute some of the success of Django to some of some of those things, but not my programming ability. When it comes to just writing code, I'm I'm at best average. I mean, I can do a fine job. I'm not I'm not bad. I'm not gonna I'm not gonna screw up horribly, but I'm also not this exceptional developer that most people think I am. My skills lie elsewhere.
And it was sort of that that was the germ of the idea that led into led into this talk is is about the assumptions that people make about me based on these couple of data points they have and how incorrect they are and casting about and talking to most of the other people that I know in in the software industry, the majority of us are not particularly exceptional when it comes to software skill. You you can do you can do a lot with a little bit of skill, and we have exceptional tooling and exceptional practices available to us that can help really help people with average skills produce exceptional products. And that was really that, you know, the idea that I was trying to reach for is this idea that software development is a whole suite and range of skills and that you don't have to be quote unquote ninja to be able to be, you know, really valuable and to be able to do good work.
[00:05:57] Unknown:
Absolutely. 1 of the things I really enjoyed about your talk was where you talked about how your strength was not in going really deep with something, but in understanding having a really good all around view and also understanding lots of different things and how they fit together and how that how, you know, how that made you successful.
[00:06:17] Unknown:
Yeah. I've always been kind of a, I've always been kind of a dilettante when it comes to learning skills. I love to learn new things but I don't particularly like to, practice them very deeply. So as a consequence, I have a lot of basic exposure to a lot of a lot of things. I know I know a little bit about a lot of things.
[00:06:35] Unknown:
Right? Yeah. Well, it's funny in our industry there used to actually be a title for that it was called the generalist but it's kinda fallen by the wayside, and everybody wants hyper specialists now. Although, it's moving in the other direction again, so who knows?
[00:06:48] Unknown:
Well, it seems like people want hyper specialists in all skill areas is the thing. They they they want people who are specialists at general skills, which is kind of an oxymoron and impossible to achieve.
[00:07:01] Unknown:
Indeed. Well, that's the thing is when we talk about, you know, when you see a job ad, you know, saying that it's looking for a ninja programmer, like and then you look at that company's product and, you know, if it's a typical if it's a typical web app, there's, like, at least a dozen things that you need to know from, you know, HTML, CSS, JavaScript to whatever back end language to the framework to SQL or other data stores, you know, operation skills. There's there's this entire, you know, suite of skills there and and this idea that 1 person is going to be exceptionally good at all of them is
[00:07:47] Unknown:
going back to what you were saying earlier about people saying to you that, oh, I can't imagine building something like Django is another misconception people have thinking that they need to be able to create this magnificent piece of software fully formed at the first go rather than really approaching it in the way that it always is and being an iterative building of things over time. You have to start with the core kernel of functionality. Just add to it and add to it over time until eventually you get to something, the scale and capability level of Django.
So it's just just another misconception that we have in our industry.
[00:08:28] Unknown:
Yeah. I mean, if you look at, you know, if you look at Django's contribution data, there's something around a 1000 people who have contributed something to Django. You know? And I'm I'm nowhere close to in the top 10 on that on that list. Might be in I might be well, I might be in the top 10 but barely. You know? And and and yet we sort of we tend to credit we tend to credit that to 1 to 1 person. We we have this we have this idea really deeply embedded into sort of our our psyche about this sort of genius inventor, and it doesn't release it doesn't mesh with the collaborative way that software, both open source and commercial, is produced these days, but it tends to we tend to still we tend to still believe it. You know, we're much we're much more invested in the sort of, you know, Steve Jobs, Elon Musk, you know, billionaire brilliant inventor inventor myth than we are with the idea of someone with a spare couple of minutes fixing a typo and multiplying that effort across thousands of people.
[00:09:32] Unknown:
You know, it's it's really interesting that you say that because I think that myth is is is equally mythic in other areas as well. Right? I mean, like, you mentioned Steve Jobs or Elon Musk. You know, they had I forget who it was who said, we build upon the backs of giants. I mean, each each 1 of those inventors, I mean, even Albert Einstein or Thomas Edison, you know, they built on generations of scientists or whatever or whatever field they were working in before them who paved the way for them to make these great discoveries. And I feel like software is exactly the same way. Right? Like, I mean, even if you really are the lone hacker working till 2 o'clock in the morning in your garage, creating something amazing, you're using tools that were created by other people who that, you know, you're leading on this ecosystem that was created by a cast of 1, 000 probably.
[00:10:27] Unknown:
Exactly.
[00:10:30] Unknown:
So what are some of the ways we can change the tone of the conversation around programming skill?
[00:10:37] Unknown:
I was talking about this with a colleague of mine at Heroku, Crystal, who runs our, our our support team. And he was talking about he made a really good point which was that 1 way we can get at this is by changing the types of stories that we tell. So we so we tell these stories about we tell stories about about, you know, about Steve Jobs, about Linus Toribalds, about about the the the genius, the the the lone wolf, you know, we tell these stories about individual success, and we we can change that narrative. We can start telling stories about about collaborative success, about a group of people gathered together, coming together as a team and producing something producing something great sort of out of out of that collective skill and that and that and that sense of collaboration. And we and we can, you know, we can celebrate those types of successes, those sort of quiet, you know, quiet, steady improvement over a long period by a large by a large group and sort of celebrate the the work that it takes to keep a group of people executing.
And, yeah, I think that that's I'm thinking about that a lot. I think that starting to tell those types of stories more can really help make our community feel more engaging and more welcoming because it it sends a message, you know, not that you have to be brilliant and and and and, and a and a lone wolf, but that you can, you know, you need to you you need to figure out how to fit into a team and be part of a group. And I think that, you know, I think that there's something really powerful about this concept of of being part of a team. I mean, we have this, I mean, you know, we have this hunger for for sports as a as a culture. And and, you know, we're watching these team sports and thinking about this idea of the whole as as more than the sum of its parts. And I think we can apply those kinds of narratives to the the stories we tell about software. I think we can start to get to a healthier place. Where does the myth of exceptional versus terrible programmers come from? And can we provide can you provide some examples of times you came in contact with this narrative? Yeah. Where does it come from is a difficult question. I think there's a lot bound up in it. I think 1 aspect of it aspect comes from there there's sort of a there's a there's a running narrative in in American culture about this sort of this this myth of American exceptionalism, you know, pulling yourself up by your bootstraps, you know. Anybody can do anything if you just work hard enough. It's kind of this, this Protestant work ethic that's embedded in our culture. Jung might call it the collective unconscious, not dangerous ways with with software because we don't we we are so terrible at measuring our work when it comes to when it comes to software. I mean, I I mentioned this in my keynote, like, what metrics do we have when we say someone is a good programmer? Like, what are we measuring?
Are we measuring lines of code written? I mean we know that that's a terrible metric for for productivity. A line of code is neither good nor bad. Are Are we measuring, you know, story points? You know, what's a story point? How do you, you know, can you collaborate or or can you correlate from 1 project to another or even from 1 day to another? Like, how are we measuring when we say someone's really good, we're measuring that. I I don't think we're measuring anything at all. I think we're we're just just sort of we have this, like, we're just sort of making these assumptions and making up these stories about people but we really have a way of actually measuring what what good is and so we have this we have this 1 idea of of these geniuses that we're sort of we think they're more common than they are because of because of the the the sort of root myths in our culture, and then we we don't have any tools to measure anyone's performance. And so we we just sort of try to fit them to a narrative, stereotype, and and either they fit into this idea of the genius or or they don't. And so we assume if they're not a genius, they they must be the other thing. They must be the idiot, and and we don't have a we don't have a complex way of thinking about skill and software.
But so that's where I think it comes from although there's probably a lot more going on there. Times when I've run into it, think about that for a second. Well, you certainly see it in you certainly see it in recruiting and in hiring. I mean, I tend to focus in on that, you know, know, words like ninja and rock star because I think they're just so silly to apply to to what we do. I mean, we, you know, we sit in front of a computer all day and click at a keyboard. It's very different from what a rock star does. And, but, yeah, we, you know, we put these we put these things in our job ads, and they and they tend to be really off putting people who are are newer in the industry or don't match the stereotype of what a, you know, quote, unquote ninja programmer is supposed to look like or dress like or act like, and it tends to, you know, keep those people from even thinking that they might be, they might be qualified for for that job.
[00:16:02] Unknown:
The whole the whole, gestalt around hiring in our industry is so strange speaking about that. When you look at the the requirements that the average job lists and they're like, 10 years experience in Ruby on Rails. It's like Ruby on Rails hasn't been around for 10 years. So it's a physical impossibility for someone to have 10 years experience but it speaks to that kind of like, you know, they don't want just want you to know something. They want you to be an absolute subject expert on everything out of box. It's kind of crazy and I think it's really daunting for newcomers.
[00:16:36] Unknown:
Yeah. I mean we are just terrible at hiring and I include myself in that you know I'm, I'm a hiring manager at who I've hired a number of people and nothing, nothing freaks me out more than than than trying to hire. It's again, we have no tools to measure what we do, and so we are we are just we are just bound up in our own biases in making this decision in a very nonscientific and very, and very rough way. And I I think we do it I think we do it about as as well as anyone can at at Heroku. I think we've got some checks and balances in place to try to make sure that we aren't hiring on the basis of of of bias and quote unquote gut feel. But man, it's super tough and as an industry, we are so we are so immature when it comes to how we how we think of skill that that it's it's amazing that we are able to make good hires ever at all.
Indeed. Or actually, you know, now now that I've said that, I actually I wanna take that back. I think I'm wrong about that. I think that I think the fact that most people are kinda average at at things is actually what's saving us there because we we think that we're hiring for exceptionalism, but what we get is average because most people are average, and that actually turns out okay. So we're we're saved by the fact that even though we miss we miss the mark on hiring exceptional people, we get people who are fine at their jobs and they do fine and they're able to contribute in just a in just a fine way. So our our our own lack of understand it's not a surprise that we that we that hiring usually turns out alright, but we are missing the mark if we're if we're actually, you know, quote unquote trying to hire a a players all the time.
[00:18:27] Unknown:
Right. You know, it's it's really interesting that this comes up because I mean, I don't know if you've ever listened to, Saran Yiparak's podcast, the CodeNewbie podcast, but it's it's all oriented towards helping people get their first job in the industry, learn how to program, etcetera, etcetera. And 1 of the things she keeps going back to is don't be daunted by ridiculous job requirements, you know, like actually talk to people, actually get a sense of what will the job be like to do, what kind of work would they actually expect you to perform day to day in this job and and don't get scared away by these, you know, 20 years experience, you know, programming particle accelerators at CERN. It's it's almost meaningless.
[00:19:12] Unknown:
Yeah. You know, I, I struggle this with this when I write job postings because on the 1 hand, I wanna sort of make a laundry list and put sort of all the things that I think might be might be intriguing and might make me want to interview a candidate. But then when I step back at the end and I look at the list of things it's like there's no way that any 1 person knows all of these things. So you know I've started doing things like saying hey if you know if you know at least 70 percent of this stuff, you should go ahead and apply. Or you should you should know some of these things and be excited to learn the rest. That's another 1 that I've that I've used to sort of say, like, hey. This is a wish list, not a not a hard set of hard and fast requirements. Like, you know, if you kinda match this, we should and, you know, hopefully that balances those things. But, yeah, like, we tend to sort of we write these job ads, like, we're I don't know.
Like, we're dreaming about some some mythical person who's gonna be able to do everything all at once, and we're never actually gonna find that person. Yeah. And 1 thing that I've seen a few articles recently about that's
[00:20:15] Unknown:
an attempt to address some of that is having more of a a trial period. So basically having a project based interview cycle. So rather than having somebody come in and do the entire interview all in 1 day, they say, okay. Here's some materials. Here's some information about the kind of stuff we're doing. Why don't you work with us a little bit on this 1 small little project so we can see how you work and the kind of things that you actually know, you know, when you're when you're really working on something, kind of things that you actually know, you know, when you're when you're really working on something. And then we'll use that as our basis to determine if we wanna actually bring you on full time. And that's sort of going back to the old apprenticeship mindset that we have recent you know, in recent years moved away from. And I think that's, to a degree, detrimental to our industry and a number of other industries as well. But there's definitely been a little bit of a renaissance around that idea.
[00:21:05] Unknown:
Yeah. And that's similar to what we do at at Heroku. We do what we call a starter project, which is a sort of couple day, you know, intensive working together project, try to, you know, simulate what it's like to to actually be colleagues. The problem is, you know and I think that that works better than the adversarial interview process, but it's still problematic that, you know, it requires that the candidate have the, you know, the ability to take a couple, you know, a couple days a week off from their normal their normal work and do what's usually some an unpaid engagement on the basis of maybe getting a job. And so there's a lot of privilege bound up in there. You need to be financially stable enough to be able to take some time off from your current job. You need to have a current job that won't fire you for missing a couple days. I mean, you know, back when I was before I I was lucky enough to work in software, I definitely had jobs that if, you know, I was an hour late, I'd get fired, let alone taken a couple days off.
So the the, apprenticeship style interviews certainly help with kind of bias, but they also introduce another 1. This stuff is is hard and it's it's complex.
[00:22:16] Unknown:
Very good points. Thank you for bringing those up.
[00:22:19] Unknown:
I will say though that I I I very enthusiastically recommend this kind of approach because, I actually, I just went through a job transition 5 or 6 months ago now, maybe it might be a little more. But in any case, 1 of the companies that I was interviewing with did that, and I thought it was so incredibly beneficial. They ended up not choosing to make me an offer, but they because of that apprenticeship program, I ended up realizing that that was the right thing for me as well as for them and I felt like, you know, as opposed to this crazy hiring process of, you know, you go through the interviews and then it's like this black box and now you hear back or you don't and you're always wondering more exactly what happened. I feel like with the project based approach, it's like, well, you know what happened. You know what I mean? Like my skills were were measured accurately based on what I did and and I felt like it was as as as educational and as satisfying for me as it was for them. So I I really like that approach.
[00:23:20] Unknown:
Yeah. I think, you know, like I said, it's the it's it's what it's what I use, it's what we use at Heroku. So I can't be too critical of it because I I do it, but I do think it's important to to recognize the the, you know, the imbalance there and and the fact that it it's just may not be possible for certain types of candidates. You know, I try to Absolutely. I try to explain it to candidates as as an option and say, you know, if you can't make this work, we'll do something else. But even there's kind of a power imbalance. Right? Because I have the job, they need the job. So I'm definitely sitting in the in the power seat when I'm when I'm having those kinds of discussions. And so it's it's difficult. You know? We have to these are the types of things I think we need to be thinking about and be really conscious of. The, you know, the the the essential question when it comes to hiring is, you know, are we is is the interview process, whatever that looks like, what is it measuring? Is it measuring your ability to to deliver at the job, or is it just measuring your ability to get through the interview process?
You know, if we because if we do it wrong, it's gonna end up being something like the the SAT test, which is utterly not predictive of performance in college, performance after college. The only thing that the SAT predicts is your performance on future SAT tests. And so if our hiring process is measuring the wrong things, we're gonna end up hiring people based on their ability to interview, not based on their ability to actually, you know, contribute and be part of the team. And all of these types of biases that we introduce into those processes run the risk of selecting for the wrong, criteria.
I let me give you an example. When 1 of the things that that we do at the end of the starter project at Heroku is some sort of, like, you know, what we used to call it a presentation. We used to have we used to have candidates sort of, you know, give a presentation on what on what they worked at. And over time as as Heroku grew, the number of people that would come to these presentations got more, you know, got bigger and bigger and and at at certain point, there were, you know, a few dozen people, like, coming to a presentation of this candidate's project. And, you know, suddenly we realized that, wait a minute, like, we're we're we're now starting to select on the basis of someone's ability of someone's public speaking ability, which from almost all of our job roles is is somewhat irrelevant. Like, you know, how often in in your in your programming job do you have to get up in front of 20, 30, 40 people and give a really stressful presentation, like most of the time if that's not something you're good at, something you enjoy, you just don't do it. And so we we dropped the the name presentation, we scaled it back really far. I I call it a debrief now, and it's usually, you know, it's it's a handful of people, you know, half a dozen at most, and no slides, you know, very very informal because, again, like, what are we selecting for? Do we are we trying to hire people based on their ability to deliver a presentation? You know, maybe if there's some sort of developer evangelist, then that might be appropriate. But for the vast majority of the role, that's a really inappropriate signal to be selecting for. And, yeah, we were sort of unconsciously doing it because we weren't quest we weren't looking at what was happening to our process as it but as it scaled. So I I think these are the types of things we have to constantly be looking at and constantly be asking ourselves, are we what are we actually measuring here? What are we looking at?
[00:26:50] Unknown:
So what are some ways that we can work toward eradicating the myth of the 10x programmer?
[00:26:58] Unknown:
I wish I knew that. I think it's I think it's pernicious, and I think it's gonna I think it's gonna stay with us for quite a long time because it taps into something it taps into something really deep, something we wanna believe about about the world and, you know, bluntly, we wanna believe it about ourselves. I think the people who are most attached to this to this idea of exceptionalism are people who want to believe that they are, that they are exceptional, or that they could be exceptional if they're not now. So I I think we need to keep pushing back on it. We need to keep telling people who we need to keep telling people that they are welcome regardless of what their skill level is.
We need to work towards a much more nuanced understanding of what of what skill means and celebrate other types of skills, like project management is incredibly important to complex work. Design, product management, you know, that many there there are some does it go into delivering great software besides just writing the code? I think we need to work on celebrating those things as much as we celebrate the cranking out code aspects of our jobs.
[00:28:17] Unknown:
Absolutely. And I think, I mean, you know, even even beyond what you're talking about as far as people's job functions, I think sometimes celebrating people's ability in in terms of like their personality and the skills that that personality embodies. Right? Like in in my experience, there's always kind of 1 I know this is a real oversimplification, but there's always 1 zen guy on the team. You know, the person who, it doesn't matter. The building could be burning down. There could be explosions happening. People screaming and this guy is just calmly sort of walking along. Like okay, let's get to the exit. Everything's fine. And that having that sort of that kind of person around can be such a benefit.
[00:28:59] Unknown:
Yeah. I mean all the, all the studies on all the studies on diverse teams, show that diverse teams outperform homogeneous ones. And a lot of that comes down to different different mindsets, different backgrounds, you know, different sort of a different set of tools that people bring to the table. And yeah. That that difference that difference in in in in mindset, that calmness is incredibly important. You know? I I think about that a lot, you know, working for essentially an operations company. Right? Like, being calm during a crisis is pretty critical skill skill when you work for, you know, a company that operates a a cloud as as big as the ones we do.
But I think most companies are would be suited by that type of calmness. You know everyone faces a crisis at some point. So yeah. You know, definitely sort of selecting for a wide a wide range of backgrounds and a wide range of skills helps us be prepared for the events that we can't we can't predict.
[00:30:03] Unknown:
So following on from the last question in our last discussion here, thinking about our industry's problems relating with, relating, pardon me, retaining women and other undervalued groups, Do you think that the way many managers do performance reviews play a role? And if so, how can we do better?
[00:30:23] Unknown:
I think performance reviews are are pretty awful at least the way that they're normally practiced. This idea of the yearly performance review. Man, if you're not if you're not talking with your manager about if you're only talking with your manager about performance once a year, something is seriously wrong. I mean that needs to be a regular ongoing that needs to be a regular mission. Something that happens continually and all the time. It should you should never be surprised by a performance review. In terms of how it, you know, how it impacts women, I'm I'm definitely not an expert there. I would point to, I just read a really fantastic book called, What Works for Women at Work.
And it really goes into a lot of the a lot of the biases and struggles that that women in particular face face at work and and and talks about, talks about strategies that women can can use to sort of work against the work against those problems. And I found it incredibly good reading, you know, as someone who's trying to be who tries to be supportive of women in in tech. It helps me to understand, you know, the challenges that they face and to see the types of patterns that I may never be able to see directly and firsthand as a man, but that are are are things that, you know, are are very real.
I suspect that performance reviews play into that retention in in some way because they're super busted. But I I don't know I don't know specifically.
[00:31:49] Unknown:
Well, I think part of what I was thinking of was exactly what you just said when when asking the question in terms of a a common sort of anti pattern that I see is exactly you just said. The yearly performance review where you don't hear anything, anything, anything and all of a sudden your review comes, you know, dropping down at you like a like a brick to the head and you find out that your manager has not been happy with with, you know, whatever might have happened during the course of the year that you heard virtually nothing about. And I, you know, I I can only imagine that leads to unhappy people.
[00:32:25] Unknown:
Yeah. 1 of the 1 of the pattern that the authors talk about in in what works for women at work is what they call the the prove it again pattern, where women and other marginalized people, in in in our industry need to repeatedly prove their own their own worth in a way that men don't. A man who is successful wants sort of that that success tends to be remembered, whereas women need to sort of continually prove their own their own worth. And I suspect if you are only if you're only having a performance review once a year, it's very easy for each review to be, you know, a struggle to prove success. Whereas if you whereas if you have or regular cadence of recognizing success, it's easier for someone to overcome that that pattern of needing to, you know, prove their success over and over again if they have a repeated opportunity to point, this is what I did well this week. This is what I did well this week. This is what I did well this week. And kind of build build on that that narrative of success over a long period of time.
[00:33:30] Unknown:
Can you tell us about some other ongoing narratives in the technology industry that you find equally as damaging as our misconceptions around skills and knowledge?
[00:33:40] Unknown:
Well, 1 that I really hate is the way that we think about the the sort of vent the sort of venture capital approach to forming businesses. We we we talk about from the very beginning we talk about an exit strategy. Like, all all when we're at the stage of a of a of a startup and the only thing that exists is a is a pitch deck, we're already talking about exit strategy. Oh, I'm gonna sell to Google. Oh, I'm gonna get bought by Facebook. Oh, you know, and it's it's all about take a bunch of cash, push really hard, you know, burn it out and then maybe get bought. And you know sure if that's successful that can make you a ton of money but man is that really the only the only measure of success that we have? I I really hope not. There's, I would like to believe that businesses can be formed that grow slowly and make make money over the long term and provide a healthy work environment for employees and provide a product that people like and that is, you know, valuable to to our our world. And this sort of get rich quick scheme of venture capital really doesn't, allow for those types of businesses.
I'm really interested there's a new sort of investment firm called indy.dc, which is all about trying to build these longer term sustainable businesses. And I'm I'm really excited about that type of that type of model of funding and investment, and I'm hoping that it catches on and it's successful.
[00:35:14] Unknown:
Yeah. I've definitely seen a number of instances where people have referred to smaller companies or, Yeah, I've definitely seen a number of instances where people have referred to smaller companies or 1 person companies as a quote unquote, lifestyle business and using that as a derogatory term where I personally view it as being a good indicator of personal success, because it means that somebody is able to be financially independent and do something that they're really interested in rather than having to tie themselves to the goals of a corporation that they maybe philosophically disagree with.
[00:35:46] Unknown:
I remember back during the first.com bubble hearing somebody talk about what they call the, the the the Sunday test. And they were trying to decide if they want if they were gonna invest. This is a a VC talking about whether he was gonna invest in a company and he said he would he would swing by the company's offices on Sunday and if the parking lot wasn't full, he wouldn't invest in the company. And, you know, when I was, you know, when I was 19, I think it was around when I heard that, you know, my thought was, yeah, of course. Like, we should really just be working our asses off and and and, you know, struggling really hard to to, you know, you have to try really hard and maybe you you you make that maybe you make those 1, 000, 000 of dollars and and maybe you don't but it's worth the risk.
Now now in my thirties it's like, yeah, you know, I don't wanna work on Sunday. No. No. I like my weekends. I like my evenings.
[00:36:37] Unknown:
Absolutely. And it's and that's a healthy attitude. Right? Like I was just thinking as you were saying that cue all the current discussions in our field around, you know, burnout and other mental health issues from people who work at 24 hours a day, 7 days a week. Humans were not designed to deal with ongoing stress like that. We need breaks. We need the opportunity to give our brains a rest or at least do something different. I mean, it's just it's that is an unsupportable lifestyle and I think the industry on the whole is starting to learn that. The whole startup culture is still kind of in this crazed like work is life mentality, but I think there are a lot of people in a lot of places and not just those of us who are getting older who are coming to realize that this is not the way to run a ship.
[00:37:28] Unknown:
Yeah. It was a great there was a great study on on on crunch mode on sort of make, you know, having people work very long very long schedules. I I forget the details but it was it was something on the order of, you know, 1 1 week of 60 hour 1 60 hour week is more productive than a 40 hour week, and 2 is as well. But once once you get past about 2 weeks of crunch mode, performance just drops off sharply. And over time, it drops below the 40 hour 30 hour success rate. And so, you know, what happens is if if you're seriously, you know, you've got a deadline in a couple of weeks and you need to go into crunch mode to meet the deadline, as a strategic decision that can be that can be healthy ish. But as a as a long term as a long term process forcing people to work these incredibly long hours is actually less productive over a long period of time than working a more sustainable schedule.
And, you know, that that definitely matches my, you know, my experience of sure. I'll crunch now and again to meet a deadline is something that something that happens as as a business. We're often beholden to circumstances not entirely under our control and yeah. Sometimes you sometimes you make a mistake and commit to a timeline that's a bit too aggressive. But as a regular thing, this idea that you should be working every waking minute, man, it's you're you're actually you're actually damaging yourself. You're you're and and you're damaging your business too. It's bad it's bad for business. You're actually delivering less over a long period of time than you would be if you were working a more sustainable schedule.
[00:39:02] Unknown:
Yeah. And go and going back to your keynote as well, you mentioned not just working for your primary occupation, but also working in your evenings and weekends to contribute to open source projects and continually be learning new frameworks and new methodologies and always feeling like you're falling behind if you're not constantly working on something is another thing that really drastically contributes to burnout. And I've definitely, you know, found myself susceptible to this notion as well that if I'm not constantly reading another book about a, you know, new way to build APIs or something, then I'm wasting my time because, you know, otherwise, I'm gonna end up falling behind and not be as marketable in 5 years if I'm not constantly on edge. Yep.
Tobias, why don't you take it away with the picks? Sure. So my first pick is relevant to our conversation today. It's a website and platform called True Ability, and it is a different way of going about trying to apply for jobs. So rather than sending your resume into a black hole and hoping that you get a callback, it's more focused towards operations folks. But what they do is they give you a prebuilt virtual environment. So they give you a virtual machine, has some particular problem with it or some particular thing that you need to do. They give you the, you know, list of things that they want done. And then they record your entire SSH session on that virtual machine. And then once you're completed with that, that gets sent to the hiring manager of the company that posted that particular job opportunity.
And then rather than basing their decision of whether or not they wanna continue the conversation on just what marks you happen to have on your resume, they can see how you actually performed and behaved in a pseudo real environment. So that's my first pick. My next pick is Manjaro Linux. It is a Linux distribution that's based off of Arch, but it adds a lot of extra polish on top of it. So they have a graphical installer and just a really good default setup to make it easier to get started in the Arch world. They also maintain their own package repos so that you they can ensure a little bit more stability than the default Arch repos, but you still have full access to the Arch user repositories and all of that. It's still a rolling release. So I've been greatly enjoying using that as my primary Linux distribution.
My 3rd pick is a company called Vultr, v u l t r. And in a lot of ways, they're very similar to DigitalOcean in that they provide VPS. They're backed by SSDs. But they have a little bit little bit different pricing model in terms of what you get for your money. And they also have a little bit more choice in terms of the types of images that you can spin up. So started playing around with that recently. Definitely worth a look if you're a fan of DigitalOcean because their $5 plan actually gets you, I think, 3 quarters of a gig of RAM versus the 512 you get on Digital Ocean. So just another platform worth checking out.
And my last pick is a board game called Mage Wars. And it's very interesting. I haven't had a full game yet, but I've played it a little bit. And you have a board, and you have a you have a mage that you place on the board. And then you can summon different creatures and spells. And the whole object of the game is to try and beat the other mage on the board. You can actually it's by default a 2 player game. But if you get 2 sets, you can actually make it a 4 player game and just a lot of really interesting game mechanics to it. It has a little bit of a deck building aspect to it, like with Magic, but it doesn't have the the same aspect of magic where you always have to be buying new decks and new decks to be able to keep up with the current state of the world. You can just buy the core set and leave it at that, or you can get a couple of expansion sets if you really want to. And it just adds a lot of really interesting dimension to the game.
So Chris, why don't you go ahead?
[00:43:12] Unknown:
I'm gonna kick it off with a beer pick, which I because I like beer. This last weekend, we had some friends up and he brought a bottle of k's for creek from Brooklyn Brewery and it's a style of beer that I had never had before called creek and it's basically a beer that has had fruit, introduced to it during the brewing process. And this beer is really It's dark. It's it's spicy and cinnamon, it's got like notes of citrus in it, it's really complex, really tasty, everybody enjoyed it, even my wife and you know a dark beer has to be good for her to like it. So definitely recommend that.
The next thing I wanna recommend is Trello and I know a lot of people have probably already seen this. It's not new, but if you haven't seen it and you need to collaborate with a bunch of people on a complex task and you need very simple task tracking that's like basically kinda effortless, you don't need something like a Jiro or like a bug tracking system, you just need a cork board that you can track who's doing what when on, This thing, it nails it. It is super simple, super accessible, great for collaboration, and they even have a nice CLI for it. I really like it a lot.
My last pick is a another podcast called, Dan Carlin's hardcore history. If you're a a history dabbler like myself, I I can't consider myself to be an expert or even a real student hardcore student of history. This podcast is is really, really top notch. He he just finished a 6 part series on World War 1 called Blueprint for Armageddon and it was just amazing. And if you even if you're, you know, not really interested in history but you're interested in you like you you follow current events, it is just amazing to me after having heard this series, How much world war 1, the the echoes of that conflict still resonate to this very day in world politics and in in all kinds of other ways.
So great podcast. If you like history, I hardly recommend it. Jacob, what kind of picks do you have for us?
[00:45:25] Unknown:
Yeah. I got a few things. The first is a new, a new book for people who want to learn Python and Django. It's called Hello Web App. It was written by Tracy Osborne, who was, who who herself taught herself to code about 4 or 5 years ago. And she's got kind of a design background, not a software background. And and Hello Web App is written, sort of specifically for non programmers, people who wanna be able to build their own sort of web product, their own startup without much, or any programming background. There are a handful of Django tutorials out there.
This is 1 of the best that I've seen. I really I really recommend it. It's very hands on. It's very, it's very sort of actionable. It's extremely well written. I have a pdf. The physical book hasn't arrived yet, but it looks gorgeous. I'm looking forward to seeing the physical book as well. I think it's gonna be really pretty, and this is probably gonna be my go to pick for people who ask, the best way to learn to learn django. I have a couple of picks about women in tech. The first I mentioned earlier in this podcast was what works for women at work. I think this is a fabulous reading both for women who want to know some know about the sort of the patterns that they're likely to face in in in tech and in in other industries as well. And then also for men who want to be supportive and want to try to work on diversity in our in our industry.
The other is a, a similar report about, Why Women Read Tech written by Sue Gardner who works for Wikimedia and has been involved in women in tech in a long time. And she has pulled together an astounding amount of research. I think something on the order of a 100 different studies about why why women, leave tech, and it distilled it down into about a 30 or 40 page in progress, Google Doc that she's published for people to, read and take a look at, and it's pretty, it's pretty great. My last pick is, a browser extension called library extension. There's a Firefox and a Chrome extension, and it adds on any Amazon page. It adds a little, any Amazon book page that's a little sidebar that tells you whether whether that book is available in your local library.
And so when you are browsing to see if you want to buy a book, it will tell you if it's available in your library. There's even a button to, you can click on it to to reserve the book and then go pick it up at at your library. And that is as someone who likes to read and doesn't like to spend a obscene amount of money on books, I find library extension
[00:48:25] Unknown:
Great. Well, thank you very much for taking the time to speak with us today, Jacob. And for anybody who wants to follow you and the different kinds of things that you're up to, what would be the best way for them to do that?
[00:48:35] Unknown:
Yeah. I'm Twitter is the best way. I'm jacobian, jacobian on Twitter.
[00:48:42] Unknown:
This has been fantastic and, sometime I would love to have you back on the show to talk about obviously, you can't, you know, reveal all the secrets, but I would love to talk to you about your work at, Heroku with security and perhaps about Python and security in general?
[00:48:58] Unknown:
I'd love to. Yeah. There are very few secrets actually.
[00:49:02] Unknown:
Excellent.
[00:49:03] Unknown:
Alright. Well, thank you again, and I hope you enjoy the rest of your day.
Introduction and Host Welcome
Interview with Jacob Kaplan Maas
Jacob's Introduction to Python
Keynote Discussion: Mediocre Programmer
The Myth of the Exceptional Programmer
Collaborative Success in Software Development
Challenges in Hiring and Recruitment
Eradicating the Myth of the 10x Programmer
Performance Reviews and Retention of Women in Tech
Damaging Narratives in the Tech Industry
Work-Life Balance and Burnout
Closing Remarks and Picks
