Onboarding Junior Developers

3 months after leaving Hackbright, and I'm still running triage for many of my students who've been hired in the past 6 months. Not that partner companies are mistreating them, or that their skills aren't up to snuff. Most of my triage stems from a lack of real mentorship. Everyone knows that "time-to-useful" with any engineering hire is usually around 2-3 months, but no one really understands what is happening during that time that takes so long, and why some people don't really make it. 

So I'm going to write a book about it.

In this book, I'm going to discuss some of the programs I've seen work, ways they could be better, and most importantly, how to make junior developers useful, quickly, while making sure they understand how their performance actually is throughout the entire process. There will be case studies, research, fun charts and graphs and instructions on how to cost-and-time-effectively hire and onboard junior developers.

But this is a blog post, not a product announcement, so I'm going to drop some insights on you before that. 

A culture of teaching

Mentorship

How many mid-to-senior level developers reading this right now feel like they know everything they need to know to do their job? That they could functionally program without any reference materials, or debug without Google? Anyone who raised their hands probably doesn't work well with junior developers. 

Everyone who didn't raise their hands understands that knowing isn't the important part, reasoning is. Mentorship makes up the space between a productive jr. developer, and an unproductive one. Mentorship mostly consists of style guidance, help in navigating the typically awful reference materials for a given language, and institutional knowledge about the codebase and it's quirks. Junior developers need this, and it's a people skill to be a good mentor. Not everyone is suited to mentorship, but those that are can multiply the output of a junior developer by their own, and end up with much more than either would have produced alone.

Mentors should plan to spend at least 8 hours a week with a junior developer for the first month of their employment, and 5-6 hours for the next two. That's at least an hour a day, preferably in the morning. This should mostly be spent pair programming, or doing an overview of what you expect them to be able to do, and how they might go about doing it. Usually, an honest end-of-day check in is also important, but this can be done over email. Encouraging honesty about what they are having difficulty with is imperative, so that you can give further reading, or explain concepts that might not yet have solidified.

Workshops

Fostering a culture of learning doesn't end with mentorship, however. Everyone on the engineering team is a learner, and everyone has the capacity to share knowledge. Having workshops and lunch sessions taught by your engineering staff helps encourage senior staff that sharing their knowledge is important, and helps set expectations that it's not just up to them to handle the hard stuff. Teach a mix of beginner and advanced topics, such as explaining how the complex recommendation engine you use works, as well as a primer on your front-end JS framework. This prevents siloing, and also helps jr. developers to feel they can be honest about their actual skill level. You want to foster the idea that you don't expect them to just know, but that you expect them to ask. Junior developers should also be expected to teach, and asking them to explain in depth things you know they will have had to learn on the job will help them with both their credibility and confidence. 

Re-teaching language fundamentals is a good idea- most developers have to learn a new language for their first job, and going over both basic and advanced techniques will help new developers become more effective, faster. You can lean on your existing talent to do this, over lunches and in afternoon sessions, but you may be able to bootstrap it by inviting user groups to put on classes in your office in the evenings. Asking your junior talent to teach things they don't yet have confidence in causes them to investigate deeper, think more critically, and helps others. Having junior talent do a series of short talks that other junior staff is required to attend allows you to parallelize the effort they're individually putting in, as well as give them expectations to measure up to.

Hiring In Groups

Junior developers work best together, in pairs. Hiring a group of 2-6 (or more, if you have the budget and inclination to take on "classes") can be many times more effective. When working together, two jr. developers can more easily ascertain if they need help, learn faster, and have twice the working memory space. When hired together, most jr. developers are net positive twice as fast than when hired alone. 

New developers need someone who they can realistically compare their knowledge against, and who they can freely toss ideas around with. Many jr. developers don't feel comfortable or feel intimidated by other members on their team, out of a feeling that they are wasting time, or their ideas are primitive and too obvious. Most developers probably can remember a time they didn't speak up because they thought their idea was too obvious (and obviously wrong) and so hadn't been covered by the team, only to bring it up later and be told they could have saved everyone a lot of time.

Setting (real) Expectations

Honestly discussing and setting productivity milestones within the first few weeks are extremely important. Understanding what is expected of them in terms of productivity is important, because most new developers will spend most of their time learning the skills they need to accomplish what is expected of them, and they need to know if (for instance) they need to spend more hours at work getting things done, or if they can go home and learn more about the skills their job demands, or if they can rest their brains. 

Realistic milestones are important - if you feel like your junior developers should be blowing away your milestones, then your expectations aren't real, they're just a minimum that you'll ultimately be disappointed in. 

Hiring a consultant

Ultimately, these things are hard to implement. It's tough to look at your existing team, and know who will make a fantastic mentor, what your junior talent should be learning (and teaching themselves). It's hard to know what they'll be capable of 2 months from now, based on where they are now. Hiring an engineering onboarding consultant, or an educational consultant, can be a fantastic option for those running teams strapped for time, or whose teams lack the empathy capital to spend on hours of mentorship. 

Fortunately, consultants exist who can do this kind of thing. I'm one of them (shameless plug) and can help you design an onboarding process, or help your existing onboarding process accommodate developers from a more diverse set of backgrounds than it currently does. These processes can help your existing team save time, identify stars (and bad apples) faster, and help foster the growth of your entire engineering team. 

If I can help, shoot me an email at lizTheDeveloper@gmail.com.

The educational implications of Swift

Apple announced a new programming language today, one that has massive implications for iOS developers around the world. 

Overlooked so far (I know, it hasn't been that long) are the educational implications of Swift. Swift playgrounds are an amazing innovation in introducing new developers to concepts of programming that are often overlooked, and not well understood by new developers.

Take for instance, the instant feedback, in-line feature of playgrounds. Knowing what a string interprets to is a big deal. Visualizing how code executes is a skill that new developers often have trouble developing. The idea that they should even attempt to visualize the execution of code given input is a new, difficult concept. Having something do that for you as part of the normal course of development is incredibly important, it reinforces habits that are ultimately the difference between someone who continues to code, or someone who looks on from the sidelines.

Knowing what a variable's value is at an arbitrary point in the code is huge- debuggers have been with us for some time, but are often too cumbersome to drop on a junior developer who is just learning how to do something as simple as file I/O. They're important, and developers learn to use them eventually, but having them right there with you at the start is an immense head start. 

Playgrounds reframe the notion of debuggers and interpreters, from "engineering tool" to "experimentation sandbox". Something new developers often have trouble with is the idea that they should absolutely play with the interpreter all day. Too many new developers try writing a line of code, running the entire program to see if it works. Why have interpreted languages at all? Reinforcing that the computer can think as fast, or faster than you, is a huge idea. Similarly, isolating small parts of the program you'd like to test becomes very apparent in the sandbox, and from that flows functional programming, unit tests, and general architecture. Being able to see the next step in the design of your program comes from understanding these ideas, and Playground puts them right there alongside the program you're writing.

Similarly, math and programming for developers who aren't computer science graduates seem hardly connected. Later, the math becomes apparent, but in the beginnings of your career you can get stuck where you don't understand the math and it becomes a barrier for you. Mathematics involved in programming are highly visual and intuitive, but stripped of their programming context they are dry to some, and do not seem useful. Being able to bring that into the context of seeing what happens to a variable's value over time, and seeing a graph of that information is incredible. Since programs result in something visual, why isn't the math that is crucial to understanding higher level concepts more closely interwoven into the development process? 


Swift is also amazing because iOS development, and Objective-C are Hard. Hard with a capital H. There is so much going on, that most developers can't get something usable up without several weeks of instruction. Because Swift can be written alongside Obj-C, junior developers can contribute to large-scale projects without needing months of bootstrapping, and new developers can get their projects out faster. This has ramifications that will echo down the line for some number of years, affecting new developers and the structure of teams alike. More iOS engineers means more coverage of apps that are needed by those not necessarily in the middle class. Apps will have shorter development timelines, meaning less apparent commercial viability is required to get your app to market. Diversification will thrive, and I think we'll see more children able to start making apps. 

Currently we'll have to wait all summer for this to come out to the general public. This sucks, because kids have ample time to get started on things in the summer. However, adults will have some time over this next year to develop some expertise in the language, and some curricula that is targeted at Swift. My advice is to get started now on developing these programs, have them ready by next summer. Similarly, programs for adults should target a Fall date to begin classes in Swift. Creating a developer community that is suffuse with programmers at all levels will help the community surrounding Swift to be as accessible as Python and Ruby. 

Python has playgrounds at the moment, they're similar but not quite as intuitive as an apple product. Check them out here: http://ipython.org/notebook.html

Maybe They Know

It strikes me recently that perhaps some of the people who have been running universities for hundreds of years might know what they're doing.

Christian, David and I have been working on basically reinventing the wheel in terms of what universities do for computer science students. This has been met with tremendous success, but at the near cost of our sanity and capacity to do anything else. We've successfully led 30 people through a computer science education by the hand, which is something universities don't do. 

Universities expect you to handle your own shit. They're as involved in your affairs as you involve yourself in theirs. They don't check up on you when you're quiet. Professors typically don't notice when you don't understand something, and stay into the night drilling you on your data structures. Basically, they expect you to figure out when you need help, and also expect you to force someone to help you. 

Our students are always type-a enough to be able to seek help in class, or for that matter in a workplace. However, they're new to a field that's so deep and frankly, lovecraftian in it's crazy hidden unknowns - they don't know what or when to ask. They don't know who to ask. They start out not even grasping the depth to which they don't understand.

Needless to say, we spend a great deal of time enumerating the order of magnitude of knowledge they're missing. 

The gulf however, drives Christian and I to spend 14 hours a day here. We even have a rule, we're supposed to leave at 6 on alternating days. Neither of us follow that rule with any kind of regularity. Generally only when we're expected to be somewhere. But, on the plus side, our students completely floor our partners on hiring day, and their managers come first review.

Rarely, but it happens, I envy the life of a professor - I wish I could be as aloof and more detached than I am from the success or failure of my students. But, I'm doing something that matters. So many people can't say that. I also suspect that most professors develop that detachment over a great deal of time, and heartache.

Week One

Week one down! 

It was all very exciting. I got up in front of 26 adult women, and explained that they might have trouble with logic when Aunt Flo comes around. Gutsy, but someone needs to talk about this stuff. 

I was pretty sure that I'd only connect with about half the class, and the other half would hate me. Turns out, I haven't met anyone in the class I wouldn't be friends with. Everyone seems interesting, with varied backgrounds and responses to the material.

One of the most difficult things I've found is the pairing. It takes the burden off of the instructors by forcing students who otherwise wouldn't know where to start to talk out their thoughts. It also makes for a VERY loud classroom, which can be stressful for some of our more introverted students. The other challenge is that it turns out that women like to talk to one another. A lot. While this is a boon for engagement in the material, and for productivity, it's a bit distracting and it's a constant roar of "Ohhhh I get it" and "What? Why won't this work?!". Still though, it seems to knit the class together.

I seem to have a pretty good rapport with Christian - he knocks on Javascript (which is secretly fine) and I knock on Python (Tuples are stupid), which the class enjoys. We've deliberately chosen skeptical, intelligent women who wouldn't take everything we said to be the word from on high, so the back-and-forth is nice. 

All in all, I am exhausted. But I haven't been so excited for Monday in awhile. 

Ask Questions

I've been teaching programming for Girl Develop It now for about 3 months. I've been loving it, because I'm secretly a teacher deep down underneath my programmer shell. If programming is my ethnicity, teaching is my calling.

 The unexpected benefit of teaching has been to help my own confidence when coming to a part of the country so steeped in engineering talent that you feel you're the only one who might have to ask a question now and again. I've realized the tricky bit about asking questions, however. It takes an enormous amount of confidence. 

Admitting that you don't know something, or don't quite understand it is really difficult. You feel that it calls into question things you DO understand. The problem with this, and something you have to remember when asking whether or not you understand something, is what the baseline for "understanding" actually is. "Understanding" means different things to people in different stages of their careers. Depth is a very relative thing(xkcd link) - something that's deep to you isn't deep to someone who's entire life revolves around a narrow slice of your profession.

Last year, Simon Collison wrote a piece called Maturity and the Weight of Learning. In it, he discusses a number of topics- namely, culling and surrendering, and the immature view of tools. Many young developers start with a host of very powerful tools, and so learn web development (and other forms of development) with a "top down" perspective. These tools make you feel powerful, and they abstract away the need to understand how they work - but they are built by human beings, with faults, and break down around the edges. Leaning on them in the beginning is fine - but as you get out towards the edges of the Kingdom of CRUD, you start to notice a need for you to get to your feet in shifting sands. It is here that most developers grow their wings- or turn back and toil in the overcrowded kingdom.

Simon's piece talks about the responsibility we have as craftsman, to learn, to ask, to be ashamed we used a tool without understanding how it worked. This is hard, but it is doable. It is part of accepting the mantle of craftsman - this title is not free. The prescription is to admit your own limits - knowing where they are is the first step to breaking them.

A final note - I assure you, those who have taken upon themselves the title of craftsman, and who are considered so by their peers will never look down on you for trying to learn. Ridiculing someone for not knowing a thing is the biggest indicator of personal insecurity. 

Knowledge is Relative

As a mentor, I spend a lot of time calming people down. This is I suppose my mother hen approach to mentorship, but it seems to work for the subset of people who I take on. I wrote a letter to someone who feels recently like she's failed because she doesn't have a firm grounding on the basics of what she's trying to learn. She doesn't see the progress she's made, or the ground she's gained- she only sees what she doesn't yet understand. I've written this letter to many people in the past, and I suspect I'll write it many times in the future. Here is what I usually say, more or less, with the identifying bits left out.