Greatra Mayana

Career & Employment Opportunities

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

RANDALL: 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, turn them into fairly proficient junior programmers,
and a little biased in how well we did, with you I think we did pretty well at that. I
kept in contact with some of my students afterwards, and one of them sent me a message about six
months after I graduated. He was fun of my top students, stayed late every day wanting
to learn more and more and more information. The more information I threw at him, the more
questions he had, which was fantastic. He contacted me six months later, and he said,
“I think I made a mistake.” I said sounds good, where do you want to hide the body?
[Laughter]. “No, not that kind of mistake. I think I picked the wrong career.” “Wait,
hold on a second. You just spent three months of intensive 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?” 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 my proficiency skill level, and we have our way to seniors,
a decade of experience. And none of them were planning on staying in software engineering
in the next year or so.” I said, “Wait, does everyone on your team hate coding? I understand
I hate it myself sometimes! Most of the time, I actually enjoy what I do.” He said astonishing
— he said, “No, they love it. They’re upset they would to leave.” Why on earth would an
entire team of quite competent people think, “That’s it for software engineering”? He said,
“They all liked it but the only way to progress in their careers was to — “say it with me”
— go into management. 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 should not
be mandatory. No-one wants to take a software engineer and turn them into a mediocre manager
because that is the only way to move them up. We as an industry have failed at setting
a career path and 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! [Laughter]. So, I was curious. What do we mean when we say senior software
engineers? So I asked around a bunch of friends. I said, “What is your response? What do you
think the qualities of a senior engineer are?” The first thing I think of myself is when
I was much younger developer, and I had about ten months of experience. And I was interviewing
around trying to get out of an absolute horrid start-up, and I got an offer. Woo! It was
for a senior software position with ten months’ experience. 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 the first definition
of senior that I’ve seen: Expensive! [Laughter]. “Hello, I’m an expensive software engineer”.
The next thing I hear a lot is people who say, “I’ve been in engineering for five, ten,
15 years. I’ve 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 year, but I’m
not sure where to go in software.” The second definition I heard from people was “bored”.
[Laughter]. The most popular, unfortunately, answer I received … . [Laughter]. Was that
a senior software engineer, whichever software engineer in the room had the most opinions.
Which is not good, but my favourite of all of the answers I received to this question
was “from Minnesota”! We’ve got one person from Minnesota. Inflation has got so out of
hand there that you’re offered a senior position at entry level. Once you do work as a senior
engineer, you’re promoted to senior architect. No mid- level architects there, just senior
ones. Once you’re hoping to finish as an architect, you’re hoping to go again to senior fellow
– whatever that means! [Laughter]. We don’t really know what a senior is, but the one
thing I think we can all agree on that most people define seniority by is years of experience.
Which, as far as quantity fires go, I think years of experience is worse than “from Minnesota”
as a definition because have you gone to your boss and said, “I’ve done this work, projects,
and I’m ready for a raise.” “It turns out you have a number of years of experience,
however many years you have plus one.” Last last. So we keep using that word, what should
senior mean? What can we do to define that the apex of the software engineering career
path? We talk about junior engineer, mid-level engineer, senior engineer. We’re talking about
where people are on a career path, I hope, and when we talk about senior, that’s the
end. That’s where everyone wants to go, and if where you want to go isn’t well defined,
then your career path is kind of rubbish. So the problem of senior is not that we don’t
have enough definitions but rather we have too many definitions. So instead 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 when we talk about this, we need to talk about where we are.
So many people are like, “I guess I’m senior because that is the title I have” and they’re
no better way of establishing where on their path. Experience provides this, but one year
to start-up is different from massively to co-operation. Secondly, these words need to
establish where we are going. After all, it is a path. Years of experience also provides
this. In the absolute worse possible way, because in order to progress, to move forward
in your career, if years of experience is 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 and the caption “continue existing” would raise morale around the office! [Applause].
I don’t know whether that is an indication of how low morale is at the office or if you
just like kittens. Everybody likes kittens. [Laughter]. [Applause]. For those of you who
follow me on the internet, I’m known as “some kittens” on the internet and we don’t like
you! So finally, as a third metric, we need to describe the work we do, for those of you
who have been around for a while, you know a junior engineer is going to do fundamentally
different work from a senior engineer but from the word junior and senior you wouldn’t
know that, which phrases another interesting question: What work do we do? Physics tells
us that work is applying pressure through a distance and technically I have a 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. It’s a long, round problem with rounded corners. We all start
with one big problem. Not just at the engineering level but at 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 say, “What do I want to do tonight?” We want the answer to be Netflix,
not Amazon Prime, or Go or, heaven forbid, broadcast television, but Netflix! You can’t
write a function even in Python, I know, to extreme content to over 100 million customers
so we need to break that down into its component parts. We need the streams not only to be
fast but reliable. If Netflix is down, no-one is going to watch Netflix. We need a comprehensive
monitoring and alerting platform as part of that. Still can’t write a function. Break
it down further. Part of that, we need an intuitive UI for people at Netflix, other
engineers to tell the monitoring and alerting team what wrong is for their service. Maybe
100 per cent CPU is a huge problem or maybe you’re a batch job and in a is per effectually
normal. That’s what I do in my day job, as I have that UI. That’s my big problem. How
do I build this UI? I take that problem when I break it down, and I break it down, and
I do user interviews, and I write code, and I try to build something, until I’ve broken
it down into a problem 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.
So now we’ve broken down the problem enough so we can actually have code to do. We don’t
have code yet. We have essentially a specification. These are solutions. We have now solved the
problem and just need to write code which is the final step you need to – you need to
implement that code. Remember that thing we do. So, you will notice that all of these
problems and solutions are different shapes. Because not all problems are the same. They’re
different sizes and they’re different shapes of problems. So, if you’ve ever heard the
expression, “Does this person have ten years of experience or one year of experience re-Pete
ed ten times” we now know what they mean because the happy face here has ten years of experience.
They have solved all sorts of differently shaped problems. They have tackled things
from, say, putting a small microcontroller on a shipping container needing to survive
the Pacific to dealing with massive things in the cloud. The un happy engineer here has
dealt with square-shaped problems. He might be pretty good at square-shaped problems – I
hope so – but if you give them any other shape of problem, they’re not going to do too well.
So, with all that in mind, talked a lot about words, let’s get to the words. These are now
I would describe an engineer career path. We start off instead of junior with “solution
implementer”. Instead of mid-level, “problem-solver”. Instead of senior, that final step on this
path, we talk about “problem finders”. That sounds really corporate-y. Let’s talk more
about it in detail. The solution implementer, this is actually the student who inspired
the story at the beginning, solution implementer is a beginner. They need to learn the basics.
So, as a leader, responsible for solution implementers, your job is to take that bottom
row, problems that have broken down so much that they are solutions, things you only need
to write a function for to solve. Your job is to give them the solutions and let them
write code so they can learn how to turn solutions into code. Then your job after they have finished
this is to review them, say this is why this problem was picked. 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 or 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 the whole breadth
of what your company does, you can have them kneel and tap the magic wand of tech leadership
and say, “All rise, Problem Solve er!”. The problem-solver takes the problems and solves
them. Take a metaphorical pick-axe. They get to solutions and then implement them. They
put the implementations back together, and, surprise, you’ve solved 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 first level, so they break them
down directly into codeable solutions, write code, et cetera. That’s not the end state
you. You want these people to get better at their job of course, and then you give them
another problem and another until you give them bigger and bigger and bigger problems
that require more and more breaking down because they’ve seen such a breadth of differently
shaped problems. 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 of the reining, you need
to start backing off saying, “Here’s the problem, it is your job to solve it.” Don’t micro manage.
As they grow, they will say, “Here’s a new feature. We have kind of a vague idea how
it should work. But I trust you to take that, take this huge, vague problem, and break it
down.” That’s not the end. The vast majority of engineers today are probably-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 giving them complete autonomy. Instead of giving them tasks, you
give them context. This is why our company exists. This is why our application exists.
This is why our team exists. They take this context, the understanding of what the goal
is, look at the app and find a lot of problems. Because it is easy to find problems, but the
speciality of the problem-finder is prioritisation. 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
can leave it there because we have higher priorities. 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.
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 it is big enough to hold the next level, the
problem-solver. Expand that until we get to the problem-finding third level. And you’re
not done been it is not you’re a problem-finder and you can never learn anything new again,
but instead you have all three of these levels of the pyramid to learn and grow on. With
this new context and mind for building a career path for software developers, we can talk
about where we go wrong as an industry. The first one is when your pyramid gets misshapen.
You become a finder and find the great problems but you never solve them or, heaven forbid,
write code. I think this anti-pattern is called a software architect! [Laughter]. On a 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, there are companies
who think that beginners – implementers – are just cheap problem-some of solvers, throw
problems at them and never teach them to do the work they are expected to do. I hear a
lot from companies, “We don’t hire juniors. They never work out.” I understand if you
had some problems hiring and you don’t have 100 per cent success rate but if no juniors
work out of your company, that’s not the fault of the juniors. Let me 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 had an excellent presentation on how mentorship really works
before lunch. We have to get to my personal love-to-hate anti-pattern of this industry:
The UI squeeze. Do we have any UI engineers out there? People who lead UI? A few, okay.
I had a terrible start-up experience. One of the problems was all of the product managers
would go into a meeting room, sit down and decide what we were going to do for the next
two weeks. They would churn out reams of tickets on our ticketing system and hand them all
over to the designers. And the designers would take them and say assign this, add this button,
it is great. And then they would hand it off to the UI engineers. We in titles like mid-level
software engineer but we weren’t doing that work, we were implementing. All right, when
you click a button, it makes that call, fine. They wondered why they had such a high turnover
rate because they were hiring thought what they thought were the best and then going
to put them in doing beginner work. Now, when a beginner entered that environment, they
did very well until they learned how to do things and then they were also bored. The
answer here is not to stop doing UI engineering but bring the engineers back to the front.
That one initial meeting where all 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. We have a lot of tech debt because you haven’t
been listening to us! Finally, this was mentioned earlier as well, we have imposter syndrome.
Imposter syndrome is where someone is put into a position of seniority or leadership,
and feel 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 talked about what a senior software engineer
is other than perhaps opinionated and expensive, then it gets really person for that person
to say, “I don’t feel like a senior.” Has anyone out there been promoted and didn’t
feel like a senior? If we take these words and we start saying and being descriptive
about the work that people do and say of course you’re a problem-finder, done amazing work
closer of the over the last ten months, done this problem and helped all these people out
with it, break it down for them, it helps so much in the mind of an engineer who is
going, “Well, I’m wrong all the time because the errors always pop up.” To settle their
mind and say maybe I am on the right course. So, to some up with the story, I used to work
at a company called Norse, and now you know where I got the helmet. We did what we called
cybersecurity threat intelligence which is a big fancy way of saying we opened attachments
on emails from people we didn’t know. [Laughter] But then took notes! On what happened opinion
we had a – we had a fantastic bunch opening things seeing what happened. We had the email
people who were taking the email and web crawlers, and all sorts of fun things. If you’ve heard
of Conway’s Law, you can understand why every team had their own silo. We do malware we
are, don’t manual email. And none of the teams were ever talk to each other. This was a problem.
My boss at the time was acting as a problem-finder, and saw that. He said all right, it is a problem
that no-one is talking to each other. As a context, we would be a lot better if someone
could take an email attachment, send it to the mall wear team and automatically rather
than a bunch of squabbling happening in the middle, so broke that down and handed it over
to me. I was the tech lead. I said, “I need you to build a extreme 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 is a stream processing system? We took that and broke it down further.
I had a bunch of reports at all different skill levels. In my job as a technical lead,
because we are here to learn about being technical leads, was to take it and break it 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,
and some of them were implementers, and I had to write out what the software would do
for them. I could trust them to come back to me, solve this, I had this other problem
and work that out. We did. We put that all together, and, in about a month, I had a Kafka-based
stream processing system. The company collapsed, but that’s another story! I think that’s how
it should work: People are challenged to take on the work they’re ready for, be it just
writing code, solving problems, or tackling and finding and prioritising the biggest problems
of all. Thank you. [Applause].

7 Replies to “Rethinking the Developer Career Path – Randall Koutnik | The Lead Developer UK 2017”

  • "To offset that karma, he’s adopted a cat that wakes him up at night whenever a new JS framework is released." ROFL

    By the way, in the talk he explains why "senior" is a vague/misused term but in the description we have: "Randall is a senior engineer at Netflix" 😁

    Great talk, couldn't agree more.

  • You took down a copy of this talk on "Coding Tech" for copywrite? (It's gone from my likes via copywrite claim by White October Events).

    This is an amazing talk, but Coding Tech has a much larger audience than this channel, and the title "What does senior mean" is a (personal opinion) better name for this type of video on that type of channel.

    By taking this video off their channel, you're doing nothing but depriving tens of thousands of people from randomly finding it on Coding Tech's playlist (which are frequently recommended to me, which is how I found this talk in the first place).

Leave a Reply

Your email address will not be published. Required fields are marked *