Rethinking the Developer Career Path – Randall Koutnik | The Lead Developer UK 2017

thank you thank you so before I worked at Netflix one of the jobs I had was at a coding boot camp and we would take people who had never written hello world before and over the course of three months of intensive study turned them into fairly proficient junior programmers and a little biased and how well we did but I think we did pretty well at that and I kept in contact with some of my students afterward and one of them sent me a message about six months after graduated now this was one of my top students he was amazing he stayed late every day wanting to learn more and more and more more new information I throw at him the more questions he had it was fantastic and he contacted me six months later and he said I think I made a mistake I said all right sounds good where do you want to hide the body no no not that not that kind of mistake I think I think I picked the wrong career so wait wait hold on a second you just spent three months of sentential study where you loved it all you landed your dream job you have this fantastic team with good mentorship challenging problems I've heard nothing but great things about the work you've done why do you think you made a mistake in picking software engineering and he told me he said we had a team lunch where the team had lunch and the conversation came to the career plans of everyone there now there are other juniors about you know my proficiency skill level and we also have all the way to seniors with over a decade of experience and none of them were planning on staying in software engineering in the next year or so said wait wait so so dude does everyone on your team hate coding I mean I understand I hate coding myself sometimes but most of the time I actually enjoy what I do so no they all loved it they all actually were rather upset that they'd have to leave why on earth would an entire team of quite competent people think well that's it for software engineering he said well they all liked it but they all thought the only way to progress in their careers was to say it with me go into management now I'm not going to stand up in front of a bunch of managers and say that no one should go into management but I think we can all agree that it shouldn't be mandatory no one wants to take a excellent software engineer and turn them into a rather mediocre manager because that's the only way to move them up we as an industry have really kind of failed at setting a career path of setting some way of getting better as a destination for engineers that doesn't require people to go do something other than software engineering and so this all boils down to one question in my head what does senior mean after all this is in the context of senior software engineer does it perhaps mean a person who wears silly hats I hope so so I was curious you know what what do we mean we say senior software engineers and so I asked around a bunch of friends said what's your response what do you think the the qualities of a senior engineer are and the first thing I think of myself is when I was a much younger developer and I had about 10 months of experience and I was interviewing around trying to get out of an absolutely horrid startup and I got an offer whoo it was for a senior software engineering position it of course ten months of experience and it turns out it was with a consulting company and they could charge more for senior engineers so surprise all of their engineers were senior fortunately I didn't take that job but it leads to kind of a first definition of senior that I've seen expensive hello I'm Randall Cote Nick I'm an expensive software engineer the next thing I hear a lot is people who say you know I've been an engineer for 5 10 15 years I have done so many incredible things and I'm not sure where to go next I could pick up yet another programming language and stave off boredom for another maybe year but I'm not sure where to go in software so the second definition I heard from people was bored the most popular unfortunately ants I received was that a senior software engineer with whichever software engineer in the room had the most opinions which is not good but my favorite of all of the answers I received to this question was from Minnesota Minnesota is a state in the United States where oh we got one person from Minnesota where title inflation has gotten so out of hand that once you graduate from college with a degree you're offered a senior engineering position that's that's considered entry-level and then once you do some work as a senior engineer you're promoted to senior architect no no mid-level architects they're just senior ones and once you finish you know a whole bunch of study as a senior architect you're then promoted again to senior fellow whatever that means so we don't really know what a senior is but the one thing we I think we all can agree on that most people define seniority by is years of experience which as far as quantifiers go I think here's the experience was actually worse than from Minnesota as a definition because have you ever gone to your boss and said well you know I've done all this work and had help with these projects and I think I'm ready for a promotion or a raise and they say well you have a lot of experience and it turns out a number of years required for that promotion is however many you have plus one so we keep using that word what should senior mean what can we do to define that kind of apex of the software engineering career path we talk about you know junior engineer mid-level engineer senior engineer we're talking about where people are on a career path I hope and we talk about senior that's the end that's where everyone wants to go and if one where you want to go isn't well-defined then your career path is kind of rubbish so the problem with senior is not that we don't have enough definitions rather we have too many definitions since that I think we should have new words to talk about this career path these words need to be quantifiable we need to use them and so when we talk about this we need to talk about where we are because so many people like well I I guess I'm gonna senior because that's the title I have and they have no better way of establishing where they are in their path use of experience sort of provides this but one year to start up is vastly different than one year at a massive corporation secondly these words need to establish where we're going after all it's a path years of experience also provides this in the absolute worst possible way because in order to progress to move forward in your career it gears it experiences the metric you're using you need to continue existing and that's it raise your hand if you think that a poster with a picture of a kitten on it and the caption continue existing would raise morale around the office whoo I don't know if that's an indication of just how low morale is at the office or your office really likes kittens everyone likes kittens for those of you who follow me on the internet I'm actually known as some kittens on the internet and we don't like you all right so if I finally as the third metric we need to describe the work we do for those of you who've been around for a while you know that a junior engineer is going to do fundamentally different work than a senior engineer but from the word junior and senior you wouldn't know that which phrase is another interesting question what work do we do physics tells us that work is you know applying pressure through a distance and technically I have a very fancy keyboard that lets me do that but I don't think that's quite work what we have here at the top is a problem and it's a very long round problem with rounded corners we all start with one big problem we want to tackle not just at the engineer level but the company level too at Netflix our big problem is when our customers go home at the end of the day and they flop down on the couch and then they ant say what I want to do tonight we want the answer to be Netflix not Amazon Prime not HBO go or heaven forbid broadcast television but Netflix and you can't write a function even in Python I know to stream amazing content to over 100 million customers so we need to break that problem down into its component parts and as part of that we need the streams to not only be fast but also reliable because if Netflix is down and no one is going to watch Netflix so we need a comprehensive monitoring and alerting platform as part of that still can't write a function break it down further as part of that we need a intuitive UI for people at Netflix other engineers to tell the monitoring and alerting team what wrong is for their service maybe a 100 percent CPU is a huge problem or maybe you're a batch job and that's perfectly normal and that's what I do in my day job is I have that UI and that's my big problem how do I build this UI and when I take that problem and I break it down and I break it down I do user interviews and I write code and I try to build something until I've broken it down into probably the size of say how do I put a text box on the page that lets the user enter a percentage amount now that I can write a function for even in JavaScript and so now we've broken down the problem now so we can actually have code to do it we don't have code yet what we have is essentially a specification these are solutions we have now solved the problem and just need to write code which is the final step we need to implement that code remember that that thing we do so you'll notice that all of these problems and solutions are different shapes because not all problems are the same there are different sizes and there are different shapes of problems so if you've ever heard the expression does this person have 10 years of experience or one year of experience repeated 10 times we now know what they need because the happy face here has 10 years of experience they had solve all sorts of differently shaped problems they have tackled things from say putting a small microcontroller on a shipping container that needs to survive the Pacific to dealing with massive things in the loud the unhappy engineer here has dealt with square-shaped problems it might be pretty good with square-shaped problems I hope so but if you give them any other shape of problem well they're not going to do too well so with all that in mind I've talked a lot about words let's actually get to the words these are how I would describe an engineer career path we start off instead of jr. with solution implementer instead of mid-level problem solver and instead of senior that final step on this path we talk about problem finders that sounds really corporate II so let's talk about a little more in detail the solution implementer and this is actually the student who inspired the story at the beginning at rocket you solution implementer is a beginner they need to learn the basics and so as a leader responsible for solution implementers your job is to take that bottom row problems that have been broken down so much they become solutions things you only need to write a function for to solve and your job is to give them these solutions and let them write code so they could learn how to turn solutions into code and then your job after they have done finish this is to review them say this is why this problem was fixed this is why this solution was chosen for that problem and review the code of this is how you chose to solve it is it good is it bad after that once they've seen not just implemented a lot but rather implemented a lot of different shapes so they've seen kind of a whole breadth of what your company does we can have them kneel and tap the magic wand of tech leadership say all rise problem solver now problem solver takes through problems obviously and solve them using a metaphorical pickaxe so if you want to use literal one you can I don't recommend it they take these problems and they break them down into smaller problems till they get to solutions and then implement them put the implementations back together and surprise you solve the original problem when you have an implementer who is promoted to solver at first you want to give them very small problems they can break them down maybe the the first level so they break them down directly into codable solutions right code etc that's not the end state you want these people to get better at their job of course and then you give them another problem and another one another one until you can give them bigger and bigger and bigger problems that require more and more breaking down because they have seen such a breadth of differently shaped problems and as they get to these stages they grow bigger and bigger and bigger and get bigger and bigger problems you need to start letting go over the reins you need to start backing off and saying all right well here's the problem it is your job to solve it don't micromanage and as they grow they'll solve bigger them until you can say oh here's an here's a new feature that we have kind of a vague idea of how it should work but I trust you to take that take this huge vague problem and break it down but that's not the end the vast majority of Engineers today are problem solvers but it doesn't have to be terminal because one final layer the problem finder as someone saw a problem solver solves bigger and bigger problems you give them more and more autonomy the problem finder is given complete autonomy instead of giving them tasks you give them context this is why our company exists this is why this application exists this is why our team exists they take that context this understanding of what the goal is look at the app and find a lot of problems because it's easy to find problems but the specialty of the problem finder is prioritization not only can they find them they understand in the context why those problems exist maybe this bit of technical debt it's fine we don't we can leave it there because we have higher priorities then once the problem is found that the problem Finder wants to tackle they also break it down into smaller problems and finally also implement them because at no point should we stop telling software engineers to engineer software you can think of this like a step pyramid or perhaps I just really like pyramids where at the bottom of the pyramid we have the implementation of software if you can't implement software you're not going to be a very good software engineer as we learn and get better at that we can expand that base until finally it's big enough to hold the next level the problem solver expand it build that one as well as the implementation so we finally get to that problem finding third level and you're not done it's not suddenly your problem finder and therefore you can never learn anything new again but instead you have all three of these levels of the pyramid to learn and grow on so with this new context in mind for building a career path for software developers you can talk about where we go wrong as an industry the first one is when your pyramid gets a little bit misshapen and you become a finder and you learn and I'll find all of these great problems but you never actually solved them or heaven forbid write code I think correct me if I'm wrong this anti-pattern is called a Software Architect one more serious note one of the biggest problems I've seen especially leading a boot camp and watching a whole bunch of new engineers encounter the industry is companies who think that beginners implementers are really just cheap problem solvers they just throw problems at them walk away and never actually teach them how to do the work they are expected to do I hear a lot from companies like oh we don't hire juniors they never work out I understand if you have some problems hiring and you don't have 100% success rate but if know juniors ever worked out at your company that's not the fault of the juniors we repeat that you need to mentor juniors or it is your fault that they are failing I'm not going to say any more on this because you already had an excellent presentation and how mentorship really works before lunch we have to get to my personal love to hate anti-pattern of this industry the UI squeeze we have any UI engineers out there or people who lead UI q okay I was at I had an absolutely terrible startup experience one of the problems there was all of the product managers would go into a meeting room sit down and just decide what we were going to do for the next two weeks they would churn out reams and reams of tickets on our ticketing system and hand them all over to the designers and the designers would take them and say alright well app needs to do this we'll design this and add this button it's great and then they'd hand it off to the UI engineers now we had titles like mid-level software engineer senior software engineer but we weren't doing that work we were implementing we were just taking all right well they want a button when you click the button it makes that call ok fine and they wondered why they had such a high turnover rate because they're hiring what they thought you know we only hire the best and then we're going to go put them in doing beginner work you know when a beginner entered that environment it's very well until they learned how to do and then they were all so bored the answer here is not to stop doing UI engineering but instead bring the engineers back to the front that one initial meeting roll the product managers would meet together and give the engineers autonomy and say this is where we want to go we have these problems but you need to solve them and allow autonomy and the first thing you're going to hear from them is we've an enormous load of tech debt because you haven't been listening to us finally this was mentioned earlier as well we have impostor syndrome impostor syndrome is where someone is put into a position of seniority or leadership it feels like they don't deserve to be there now if we say congratulations you're a senior software engineer and at no point have we ever talked about what a senior software engineer is other than perhaps opinionated and expensive and it gets really easy for that person and their brain to go I don't know I don't feel like a senior does anyone out there have been promoted and didn't feel like a senior so if we take these words and they start saying being descriptive about the work people do and say of course you're a problem finder you've got amazing work of the last few months you found this problem and you're able to help all these other people out with it break it down for them it helps so much in the mind of an engineer who is going well and wrong all the time because all the errors always pop up and uh to settle their mind and say all right maybe I am on the right course so to sum up with the story I used to work at a company called Norse and now you know where I got the helmet and what Norse day is what we called cybersecurity threat intelligence it's a big fancy way of saying we opened attachments on emails from people we didn't know but then took notes on what happened we had a bunch of fantastic incoming streams so we had them all where people who are opening all sorts of things and seeing what happens and we had the email people who actually would take in all of the email and web crawlers all sorts of fun things but if you've heard of Conway's law you can understand why every team had their own silo we do malware here we don't handle email we do email here we don't handle Mull ware and none of the teams that ever talk to each other this is a problem and my boss at the time was acting as a problem finder and saw that said all right it's problem that no one's talking to each other at the context we'd be a lot better if someone could take an email attachment actually just send it to the email the sorry send it to the malware team and automatically rather than a bunch of squabbling happening in the middle so we broke that down and you hand it over to me how is it tech lead said I need you to build a stream processing system to take all of the incoming data and send it around so the silos can be broken down so it sounds good what's a stream processing system and then we took that broke it down further is that a bunch of reports at all different skill levels in my job as a technical lead because we are here for learning about how to be technical leads was to take that and break down to the level I thought each one of my people could handle and then I bumped it up a little bit because I like challenging them and they were amazing people so I took that well some of them were implementers and I had to actually write out what the software should do for them but others were problem solvers and I could give them bigger weightier problems and trust them to come back to me all right well I solved this but I have this other problem and work that out and we did we took that put that all together in about a month I had a copy of a stream processing system and then the company collapsed but you know that's another story that's how I think it should work that people are challenged to take on the work that they're ready for be it just writing code building problems or tackling and finding and prioritizing the biggest problems little thank you [Applause]

Channel: LeadDev

Views: 38,394

Keywords: randall koutnik, rethinking the developer career path, white october events, lead dev, lead developer, simple programmer, software developer, software development, senior developer, tech lead, the lead developer, the lead developer conference, the lead developer london, the lead developer uk, the lead developer uk 2017, Rethinking the Developer Career Path, developer career, Rethinking the Developer Career Path – Randall Koutnik

Id: yIPbE7BssOs

Length: 25min 4sec (1504 seconds)

Published: Wed Jul 12 2017