Teacher, Speaker, Leader, Mentor, Software Developer

I'm @lizTheDeveloper and I work at a bootcamp. I've chosen to remain in this role long past the average bootcamp-lead-instructor burnout time - just one year. I've been doing this since 2012, the beginning of the bootcamp industry. Why haven’t I burnt out? I believe a whole helluva lot in this thing, and keeping it alive, honest, and improving is a worthwhile way to spend my life. I firmly believe that bootcamps are outperforming universities.

It's a new model for making programmers - a cross between traditional academia and the bootstrapped-learning of the tinkering children of the 70s, 80s, 90s. To me, a bootcamp is like finding another kid at school who also spends their nights nerding out, fiddling with the same toys you're fiddling with. Only now that kid isn't on an island in a sea of people disinterested or actively annoyed with your passion. Now that kid is a group of people, learning with you, fascinated by the same stuff.

The reason it's like that is this: project based learning, and relationship-based learning. Unlike traditional university programs, you have a teacher that spends all day with you, encouraging you to learn and getting to know you. They stay with you through the whole course, not like a course advisor- an actual industry expert you develop a real relationship with. They aren't lecturing to 150 freshmen, they're lecturing to less than 30 people, all of whom they've sat and pair programmed with. And what you're working on is real and it's interesting. It's something you'd find in the industry, or something it might occur to you to make for fun. You make an actual webserver with real tools that you might be using when you go get a job. You build games and make diagrams of the way the data moves between them.

Traditional Academia would never hire me- I'm just a programmer with no degree. But I've done some impressive stuff in my career- industry changing shit. The respect of my peers and my ability to do the job and do it well, along with more than a decade and a half of experience means nothing in academia. My teaching abilities mean nothing there as well- people are literally fired for doing a good job teaching at universities. The incentives don't line up- professors are incentivized to do a bad job teaching. So my career in academia never would have happened- I love teaching too much!

The way most professors start out is by wanting to do real, very scientific, unbiased research. Unfortunately, the only way for you to do that work is to go become a teacher. The skill set for teaching and the skill set for research just aren’t the same- teaching is not research. There are a large number of people who care very much about their work and are willing to do what it takes to get to do it, and it turns out that the way to their goals is through some students. On top of that, there are a very small number of roles because very little money is allocated to people doing research, and so you have a lot of very desperate, type-a, driven people trying to advance the human race- these people are the ones asked to teach you. You're in their way.

Honestly, that's why college takes 4 years. As a student, you're often a necessary evil. A lot of the work you're given to do, you're sent to struggle with it alone for hours and hours. At a bootcamp, we give our students assignments and walk them through them- first showing them how, then doing it with them, and then letting them do it alone. We also keep in touch, and coach them on their careers. They typically come back for years, always having a place to get advice, and a network of people willing to help further their career. The relationships built between bootcamp instructor and student are deeper than those between college professors and their students. The advice is solid too, because instructors come from the actual industry the students are trying to get into.

Instructors cycle in and out, for many reasons. Part of it is just instructor burnout. I blame Dunbar's Number for this. At some point, your life fills up with the relationships you have with your students. With some of them, you become friends. The admissions processes are good enough that you can authentically believe in, and bet on your students. You find yourself spending lots of time mentoring and answering emails with long and thoughtful responses. Eventually your life is full, and you just don't have time to spend on developing new relationships- so you opt the keep the ones you have and then move on from the industry. If you elect to stay, you have to compromise - relationships that form are less deep, or you lose touch with people you don't mean to lose touch with.

It's easier to form fewer relationships. This is why it's industry standard to keep instructor-student ratios low. It's good practice not to go over 1:7. But many hands for one class means that prices are high- to pay a team of developers you need some serious coin. The developers cost just as much as they do in the industry, typically around $100k, more for anyone with senior or lead in their resume somewhere, less for someone just getting started. That means every student slot needs to bring in $14,000 a year on the low end, just to break even on salary- not to mention the rent in a tech hub, and all of the other staff. This bootcamp thing is fundamentally a pricey way to teach. The margins are low, and the impact doesn't scale like hiring a developer to build an application does.

Because instructors cycle in and out but follow the same teaching methodology and use the same materials, there's always new technology being folded into bootcamp curricula. We're teaching much more advanced concepts than when I started in 2012, but it's because the industry has advanced and obviated the need for a lot of training. Technology gets more advanced every year, but our industry believes that advanced means easier to use, and so more and more training time can be put into practice, and developing mental models for problem solving.

We bring the lean startup mentality to it, though. If went the route of DeVry or ITT Tech, or god forbid the University Of Phoenix, we would have sold 2-4 year programs of this stuff. It would cost the average student $100,000 to do a 4 year program at what we have to charge- the difference is that we think the opportunity cost is too high, students don't need that many years to break into the field. They need a growth mindset, some introductory materials, lots of practice, and some exposure to the community. The rest takes care of itself. And it's working- most bootcamps boast higher graduation and employment rates than state universities, and a largefraction of private schools. At a fraction of the cost, several times the impact, and with the hard data to back it up.

There's also the diversity problem. More diverse students come from bootcamps, because they don't have to pay the opportunity cost associated with spending over 40 hours a week learning instead of earning. The average person can't take 4 years out of the workforce except when they are very young- if they miss that window or pick the wrong degree, they're hosed. You often don't get another go-around, and if you can't find work with your history degree or your CS education from an online university didn't actually teach you enough to be employable, then it's unlikely you'll recover. Know who tends to miss that 18-22 year old window? LGBTQ youth in intolerant households. Young moms. First-generation immigrants. Refugees. People in generational poverty. People who have experienced a catastrophe, like a natural disaster or a subprime mortgage crisis. People who are smart, wanted more, and do have the aptitude to succeed, and can prove it- but not with 4 years of their time and 100k. It takes a lot of compound interest on early life success to pay the high opportunity cost of a degree.

The signaling of a bootcamp is different than college, as well. It represents a conscious decision, rather than the pressure exerted on you throughout your high school years. Often it represents a decision you made because you're dissatisfied with how things are going, or expected to go. It means declaring "what I have now is not enough", which conveys ambition and risk-tolerance. They're the only ones capable of making it through the bootcamp gauntlet. These individuals are battle-tested, which comes in handy in the often-hectic environment of a technology company, whatever size it may be.

The future of education is agile - programs that teach you to make things, rather than expect you to pry your education from their hands. Cohorts selected for bonding and cross-nurturing. Teachers that know your name and don't forget about you when you leave. Education focused on outcomes, with programs run by educators, alongside experts, alongside students who remain excited and enthusiastic. We change fast, we base it on data, we listen to our students about what they actually need, and rapidly iterate.

When I was little, my dad taught me everything I’d need to know to be, well, me. He taught me to code when I was twelve. I worked for him full time at 14, which we’re gonna pretend is totally great parenting for the purposes of this article. But before that, starting at around 9, he taught me how to sell.

My dad was a psychologist by training, but switched at the end of his master’s to marketing. Mostly because my mom said she wouldn't marry him if she beat him to finishing her degree, since he had a two year head start on her. So, he rushed through a few classes in marketing, and learned to do sales. Then, as a combination sales guy / hacker, he passed his skills on to me.

One of the techniques he taught me is emotional sales. I didn't realize it at the time, but this would shape my ability to teach and lecture well from the very beginning. You should use this too, in your next conference talk or training, because it’s an amazing way to introduce new information.

Most teachers are only able to get their students to retain 40% of the information they present, but I think this is due to the pitch. If people don’t understand the information in context as to why it is important, their brains will neatly file it away under “not important”, because that’s what our brains are trained to do. However, if you sell the new information like it’s a solution to a problem, our brains keep it top-of-mind for whenever that type of problem presents itself. It also lends itself to novel use better, because our brains try to pattern-match on problems, and if whatever you’re presenting is the solution for one problem, it might work for similar problems.

How to teach by selling

You probably know how your material will help the student, but they don’t. Picture a time in the future when your student will use the thing you’re teaching them. What’s the problem they’re trying to solve? Is the emotion associated with it positive, or negative? Start with this idea, you’re either making something bad go away (which is strong) or making something good happen (which is weaker).

Now, pick a memory you think a student has encountered. “When was the last time you were late to something because you couldn't find your keys” is a great example for a pitch for a product, and for education (especially in tech) it’s almost the same. “Remember the last time you spent hours trying to untangle your local git repository?” is a good for teaching a new git workflow, or “you know how a lot of your time is spent writing really basic SQL queries?” might be a good way to introduce an ORM. This is called picking an Associative Memory.

Now it’s time to grab their attention, typically with some humorous anecdote. Pick some specific details of the problem that bring the person’s association up strongly. “You spent 4 hours fighting with rebase, and ended up losing track of what you were trying to fix”, or “you end up creating mountains of unmaintainable code to get a few records out of a database”. This establishes you as “on the same team”, as someone who understands the pain they've gone through or what they’re trying to accomplish. It’s called Confirming The Schema. The more specific the details you talk about, the better the retention of the message, just make sure lots of people share that experience.

Now you Insert New Information — it’s time for the material. This is the part where the sales guy says “it doesn't have to be that way!”. It’s where you’d put statistics, like “in California it’s legal to keep your insurance documents on your smartphone”. In our example it’s a good time to introduce the concept- “Well it turns out there’s a tool for that- it’s called an Object Relational Mapper”, then you explain how it works. Give a brief overview of the concepts, don’t dive into specifics. This is the big reveal, so have some showmanship.

After the reveal, recall the Schema you established. Start explaining how the problems you talked about are solved with this new information. This part is called Rationalizing With Facts. In sales, this is where you would put your main argument. This is where the particulars become important, such as the actual syntax of the tool, or techniques you actually use to address the problems in the schema. What this really does psychologically is to satisfy the skeptic part of their brain that says “I don’t want to learn a new way to handle this”, but it also feeds the part that says “I’m excited to never have to deal with that problem again”. Explain how and why this is better and will make their lives easier.

Now it’s time for the exercise or implementation, called the Call To Action. Have a specific action item for your audience to do that demonstrates and cements that this is a real solution to their problem. This is really key to getting your material into long-term, problem-solving memory.

The last (optional) phase is called the Guarantee. This part is similar to Rationalizing Facts, in teaching it’s the best place to put other kinds of proof that aren't stuff you’d find in a textbook or documentation. Social proof, success metrics and special offers go here. For teachers, this is a great time to volunteer to answer questions or explain how you will be on-hand to help them with this. Finish by answering questions, which establishes credibility that you’re going to be there to make sure it goes smoothly.

This is typically how I teach new material. If you've seen me teach or speak at a conference, you’ll recognize this flow. My students typically hit the 80% retention mark, over the average of 40%. This is great for newer students, or people approaching something for the first time. If what you have to say is new to your audience, this technique is ideal. For review, or for refinement, this technique doesn't make sense. The students are already “sold” on the idea, and so they are already emotionally invested.

You have awesome engineers, and they want to advance in their career. Their team is growing because of advancements they've made, and you want to recognize the work they've done with something. The obvious answer is to put them in charge of the team they've built, especially as they're the de-facto leader of the team already. But is this what they want? Or just what they believe they're supposed to want?

People Management Is A Different Skill

It's well known in the engineering world that engineers often will reach a technical peak, only to be asked to learn an entirely new set of skills, revolving around social and soft skills that they've spent the past chunk of their career probably ignoring. Building these skills involves a lot of trial and error, and above all, most of their time. Their time is now spent not coding, which is what they were originally rewarded for. Suddenly, they go from being good at their job to bad at it, which destroys confidence and job satisfaction.

The problem here is that people management is a different skill than technical leadership. What you want is to reward someone with recognition that they are a thought leader, an exceptional performer- to make them an example of what others should strive to be. Everyone can't strive to be a manager, who would do the work? Additionally, you don't want to send the message that management, as a career, is somehow "better" than coding or anything else in the company, for that matter.

What Is Technical Leadership?

Technical Leadership is composed of several aspects of purview over parts of job responsibility. Think about the day of a typical engineer- many decisions have to be made, problems have to be prioritized, solutions need to be found. Those are the fun parts of any engineer's job, and indeed all engineers must exercise some degree of technical leadership.

The rest of the job involves answering questions about how a thing you made works or doesn't work. Bugs need to be found and fixed. Documentation has to be written. Code has to be reviewed. Estimations must be made. Most of all, the longer an engineer remains at a company, the harder it is to find a few hours of isolation, free from interruption, to get work done. These parts, they are the worst parts of the job.

All of the fun work happens in these uninterrupted times, and these uninterrupted times happen only when your disappearance doesn't materially slow down someone else's work. Innovation happens when you have the bandwidth to hold the entire problem in your head- most of the time that takes a great deal of "load time" - research and contemplation about the problem. For introverts this means quiet, for extroverts this means dedicated time in a room of other people you work well with, thinking about the problem.

So what gets in the way? Why can't exceptional engineers have more fun work, and have someone who is yet to be recognized do more of the less fun things? The key is in empowerment, and an engineer's ability to say "No". This isn't a function of courage, it's a function of empowerment - most exceptional engineers can't just let problems go unsolved, and if they feel responsible for a product or service, they end up chained to the project forever. Engineers often feel responsible for a project for the rest of its life, and this is exacerbated by the tendency for information to "silo" in one person, rather than distributing across a team.

How To Empower Your Technical Leaders

As a project grows, a technical leader might naturally accrue team members, and accidentally transform into a people manager. This is the biggest risk. The way to empower your technical leaders is to set expectations early and often, encouraging them to be clear about their ultimate goals, without sending the message that they will be less respected if they don't transition into people management. If their goal is to be the best programmer imaginable, or to create a system that scales to 10 million users, or to understand deep processes in the operating system, then finding ways to help them reach their goals is rewarding for everyone.

Technical goals are easy to meet - there will be plenty of opportunities as a company grows to reward engineers with "fun" projects, and the ability to learn and grow as an engineer. Identify when someone will have to learn a lot for a role, these roles are rewarding and coveted. Also find opportunities to allow for professional development outside of your company, such as encouraging engineers to go to conferences and give talks, and become thought leaders in their field. Most engineers don't have an actionable plan for their own professional development, and so can benefit from advice on how to celebrate their accomplishments by putting them in a favorable position. This also will help you make the case for raises and bonuses, and will increase the esteem of your engineering department in general, which in turn attracts more talent. Seeing someone speak on something that interests them is the number one reason why mid-to-senior level engineers seek employment in an organization, rather than being recruited. Developing a strategy for positioning your technical thought leaders as the technical thought leaders is empowering, and it helps them empower themselves.

The ability to say "No" is the second component of a technical leader - develop a strategy around handoffs. The objective here is to reward innovators by not chaining them to their innovations forever - it encourages those who create to continue creating. Junior developers are perfect to hand off smaller creations to, it helps them develop a sense of ownership without having to understand deeply the best practices that created the idea. Handoffs create opportunities in both directions- both for the person with more time, as well as the person accepting the responsibility. The incentives align well, but make sure there are expectations for the person receiving the responsibility- be honest about what it means for their career, and set up a strategy around them getting help with the project.

I came up with these ideas by helping Simple activate and reward their talent with things they actually want, rather than taking the obvious-but-wrong path. If you need help developing strategies for creating opportunities for your technical leaders, email me. I'm a consultant and I'm also an engineer myself, so I can provide insights into how to keep engineers happy and productive.

Tags

I'm doing some consulting for Simple in Portland, and I'm struck by how cohesive their culture seems to be. I couldn't put my finger on it at first, where this impression was coming from. I figured it out after attending a few meetings and watching team interaction, and I have a theory. I call it the "I to We" ratio - basically, how many times in a meeting, or a gathering, does someone say "I", vs how many times they say "We".

This is a good barometer of how connected to the company an employee feels, and how they perceive their level of integration in the team. It also indicates feelings of ownership, empowerment, and how an organization treats the idea of blame. Simple's We to I ratio is about 10:1, which I think describes how connected to each other they seem. It creates the feeling of warmth I notice, that they have each other's backs. Work being done is the focus, over "root cause analysis", which all too often turns into a witch hunt.

Think about when you use the word "I". Often at work, it's to talk about something you did, or didn't do. It might be about how you feel. In an integrated, healthy organization its usually something like "I filed a pull request" or "I updated that documentation". In an unhealthy one, it's "I didn't know I needed to handle that" or "I'm taking longer than I thought to get done, I'm trying." "I" is more often used defensively, whether to defend your actions or to defensively self promote - "I made a tool that handles that", "I fixed the certificates problem."

The word "I" isn't the problem in and of itself - it's when it's concordant with defensive tones. This is a difficult thing to notice, but an easier metric to test for is the absence of the word "We", alongside "I". "We" sounds like collaboration, and it evokes the sentiment that We Are In This Together. "We need to handle that 2-factor auth bug", "We just deployed to prod", "We don't know why this error happens", "We got the batch processor up again". The word We is powerful, and it helps make a team feel a sense of ownership, instead of burden.

You can listen in on a few conversations, status meetings, boardwalks or scrums, and get a feel for this metric. I've noticed that Kanban as a productivity management technique is more conducive to a high We to I ratio than Agile/Scrum, because the focus is on the work that needs to be done over the individual doing it.

If you use Slack, Hipchat or IRC, you can run a quick analysis on your per-team channels. Check how many times people say We, and how often they say I. Check the concordance of "We" and "I" with Python's NLTK library(http://www.nltk.org/book/ch01.html), which will show you the words that appear around the words you search for. Notice how often you see defensiveness around the word I, rather than empowerment.

All in all, this is a trailing indicator of how your team interacts, and how healthy your culture is. It's a subtle distinction to notice, but once you know it's there you can't un-see it. It's a great indicator for per-team cohesiveness, and if you do periodic checks, you can proactively address breakdowns in communication before they occur.

I do consulting for engineering process, management, and culture. I mostly work with companies in the process of growing from startup to mid-size company, and help keep them from losing their soul in the process. I also help with issues around diversity, including neurodiversity. Email me if you want to know more.

Tags

Coding schools abound these days, and there are now a proliferation of schools designed to handle many backgrounds, aspirations, and cost models. Most people who aspire to be a software engineer today can find a place to learn, and with some work, can find a job. But what happens as the market becomes more and more saturated with coding school graduates?

The market for new, junior software engineers today has a cap. As junior engineers mature into mid and higher level developers, leave the industry, found companies and make lateral moves, turnover keeps positions for junior developers open. However, junior engineers are (locally, in silicon valley at least) being produced at a faster rate than those positions are being created. No amount of amazing programs or creative, inspiring teachers can produce candidates that can enter a senior position without the experience they need. So what do we do? Turn down the throttle on junior developer production? We can't very well do that, as we're in a "baby boom" period in software - this happened in the last bubble, and when it burst we had homeless engineers and a mass exodus towards the midwest, where smaller, less well paid, semi-stable jobs awaited.

The market for junior engineers looks a lot like the western logging and mining efforts that ravaged our natural resources last century. There's wealth out there, and the market is going to reach for it. Asking people to produce less, strive less, and leave opportunity on the table is unrealistic and unfair. Fortunately, "replanting" and "conservation" efforts need not be as slow coming, nor as painful for the industry.

An Educated Market Is Bigger

I believe the answer is in preparing the market to receive and contribute to the rapid growth, and success, of candidates produced by coding schools. Recently I wrote about onboarding junior developers, and efforts to this end will help companies capitalize on a talent pipeline that will only grow larger and more sophisticated as time wears on, as well as stabilize the exit point of this pipeline for junior talent.

However, the onus is not solely on companies to provide stellar onboarding experiences. It lies on both the community, in providing stable, encouraging mentorship, and on the coding schools themselves. Coding schools can offer many things to graduates, from career counseling services to ongoing education in order to make their skills not just broad, but relevant to their specific employer. The biggest thing they can do is spend time educating companies on how to best use their graduates.

Coding schools teach widely different things, which create a thousand different vocabularies around what junior developers have learned. Some teach the Twelve Factor App, some teach MVC religiously as though it is the only programming paradigm that works. Some teach as agnostically as possible, leaving students to navigate and assert the usefulness of different technologies on their own. These different ideas and paradigms produce diverse candidates that can navigate the spectrum of the market's needs, but what they don't often realize is that their messaging around their curriculum is often the entry point of understanding that companies have about a candidate. You can say "we taught them Python, and how MVC webapps are built", and that sets a company up with both expectations, and explains what still needs to be taught.

Schools should standardize not their curriculum, but the language that describes the approaches they take, as well as what students can say that they know upon leaving. This doesn't need to be controlled by a committee or ruled by bureaucracy, but can simply be defined by communicating clearly what "they know Javascript" means. does it mean they can manipulate the DOM? Do they understand prototypal inheritance? A good breakdown of what exercises were done, what concepts are covered, and what proficiency means to the school itself can prepare a company for a candidate on the interview side, and once they've begun working.

Most coding schools have "partner companies", with which they enter both a monetary, but also a trust arrangement. This arrangement means usually that schools receive a recruiting fee, and get first access to graduates, improving chances of a match. The arrangement benefits the school and often is the reason they can keep their doors open. The arrangement only marginally benefits the company, however, and often does not benefit the candidate other than by doing a mass of introductions, and gives them an idea about what kind of company they might like to work for.

I encourage coding schools to prepare material that can help the onboarding process easier for candidates. Sharing the broad curriculum with partner companies, and educationally-minded suggestions about on the job training based on how their students are prepared during the program will help graduates be more successful, helps partner companies hire more and more effectively, and further solidifies the ideals encapsulated in the term "partner".

I'm available for consulting work in this area, and the next few months of my life I'm going to be collecting a series of case studies to test the point that an educated market is better for everyone. If you're interested in providing a case study, or interested in consulting, drop me a line at lizTheDeveloper@gmail.com.

Tags

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.

Tags

When I was a kid, I ﻿loved﻿ conspiracy theories. When you're growing up you learn just how inconsistent the world is, and it's very comforting to have an explanation other than "well, it's complicated."

Thing is, kids are best equipped to handle the "it's complicated"s of the world. They don't have a framework for thinking about how things should be, and so while explaining the behaviors of adults in a "child-safe" way is very difficult, it's actually much easier to just talk to them about things as though they're an adult, but an adult who isn't very well-read and didn't go through many history or government classes. Talk to them as though they'll understand, but be prepared to take detours. Rambling long conversations that start with "why do I have to go to school" will naturally end up covering topics like economics, education, forces of government, maybe even how governments come to be in the first place. Don't worry about circling back around, or talking in a straight line. My dad used to do this, but the best part was that it always ﻿did﻿ circle back, and the circling back was always a crazy conspiracy theory.

Not to say that they weren't true conspiracy theories - explanations of how the country got started, how companies got founded, the founding of religions, basically anything having to do with schedule 1 substances, and of course the crazy idea that the government listens to our phone conversations and reads our email. These were some of the more down-to-earth, realistic theories. As a hippie, he did occasionally tend to attribute to malice what could easily be attributed to incompetence, but those instances are far too many to list here (or anywhere.)

What this did for me as a kid was to give me a healthy dose of skepticism. First, I believed everything my dad said, but because that was often inconsistent with what I learned in school (my favorite was that we were teaching The Bhor Model in the 4th grade when it was so clearly didn't explain fine structure I mean what the hell) I started to realize that the narrative being sold by my school miiiiight not exactly be the cold, honest truth. I grew older, and after realizing that not absolutely everything my dad says is true but that most of his ideas were based on what he had learned and experienced in his lifetime, I began to accept that everyone might be like that. In fact, it might be that most people can only speak to what they have actually experienced, and everything else is just hearsay. This was a big thing for me, and it's what allowed me to summarily brush off people when they said I couldn't do things. This lesson is hard to teach, and it requires you being comfortable that your kid might form their own opinion, and that you might have to be the example when it comes to being wrong. I think my dad wasn't really afraid of that.

I will say, it has made me a good student of history. For a large portion of my life, I couldn't really study history to save my life (or grades.) After realizing that history is ﻿full of conspiracies﻿ I started to pay attention - the revolutionaries, the shady back-room deals, the murders, the lies, and best of all the successful cover-ups that we're only just now uncovering. Kids love that stuff - the more complicated, the more twists in the story, the more drama you can tell them, the better. They love, and can follow drama. Children are better at following drama than most adults, even if they don't have the reading comprehension skills they need to have. Telling them a story about the JFK assassination, or the Louisiana Purchase is riveting. Planet Money has amazing podcasts that explain the recent banking crises, which will easily get kids into current events. Explaining the reasoning (and maybe some of the action) of the Civil War will awaken the political scientist in your 10-year old.

I for one, tell my 10-year old all about conspiracy theories. Hopefully, he'll pick up the same skepticism I did. He frequently proudly announces when he's come to a conclusion opposite mine, and I'm proud of him for it (and then we get to argue.) I'll let you know if I catch him with a Dan Brown novel.

Tags

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. Swiftplaygrounds 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

Tags

One of the many teaching methodologies we employ at Hackbright came up in some reading I was doing today. Something we experiment with is the Worked Examples style of lecture. Essentially, this has us do live-coding in class, as we work through example problems using some of the tools that will be demonstrated in the exercise. Although students report back that they find live code to be more difficult to follow, and the lectures more confusing in general, during the exercise I've noticed fewer questions that require me to go over material that was covered in lecture, and more clarifying questions. Furthermore, as students have more clarifying questions, they're more apt to experiment with the interpreter rather than ask the questions of instructors.

I believe this is because the way information is presented leads us to retain it, or discard it. When someone is learning new information, the amount of "effort" put forth during the absorption of knowledge is proportional to how much of it is retained. When individuals display a high proficiency in typing, but a low proficiency in writing, they also usually report that they "remember more" when taking hand-written notes. I think this is due to the degree of struggle, or "effort", being proportionate to the reward.