Teacher, Speaker, Leader, Mentor, Software Developer

Tag
Education

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

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

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.