tag:lizthedeveloper.com,2013:/posts lizTheDeveloper 2017-03-02T23:00:40Z tag:lizthedeveloper.com,2013:Post/943192 2016-03-18T21:51:34Z 2016-09-02T07:30:08Z Changing Education - How bootcamps outperform a university education

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 large fraction 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.


]]>
tag:lizthedeveloper.com,2013:Post/797459 2015-01-17T01:32:49Z 2016-08-15T20:53:08Z Teaching is Selling

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.

]]>
tag:lizthedeveloper.com,2013:Post/771745 2014-11-21T23:10:12Z 2017-03-02T23:00:40Z How to reward skilled coders with something other than people management

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.

]]>
tag:lizthedeveloper.com,2013:Post/771328 2014-11-18T19:42:17Z 2015-01-09T21:50:33Z How 'The I to We Ratio' provides quick cultural insight

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.


]]>
tag:lizthedeveloper.com,2013:Post/740303 2014-09-15T19:00:00Z 2014-10-30T13:54:29Z Coding School Graduates and Market Saturation

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?

Differentiation for a Naïve Market

Today, coding schools attempt to differentiate themselves for the sake of their graduates ability to get positions, or choose to opt out of that metric entirely. Everyone wants to be the "Harvard of Hack Schools", or the main supplier of diversity candidates. These methods of differentiation are a bandaid that addresses the question "will our graduates be able to get jobs" with the answer "of course, because they are different than other schools' 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. 

]]>
tag:lizthedeveloper.com,2013:Post/738470 2014-09-09T00:23:54Z 2015-11-19T22:10:08Z 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.

]]>
tag:lizthedeveloper.com,2013:Post/700382 2014-06-05T05:36:52Z 2014-06-05T05:36:52Z Talking to kids about conspiracy theories

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.

]]>
tag:lizthedeveloper.com,2013:Post/699204 2014-06-02T19:55:09Z 2014-06-05T05:37:07Z 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

]]>
tag:lizthedeveloper.com,2013:Post/685346 2014-05-01T22:18:47Z 2015-11-19T21:51:38Z Goodbye, Hackbright

To: Hackbright Staff

From: lizTheDeveloper

Subject: Thanks

]]>
tag:lizthedeveloper.com,2013:Post/662276 2014-03-10T04:49:26Z 2014-03-10T04:49:26Z Live-coding in lecture

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. 

]]>
tag:lizthedeveloper.com,2013:Post/632262 2013-12-19T02:27:07Z 2014-06-30T16:29:40Z How to hire a lady to do software engineering

I'm guessing you're reading this post because you've got a problem. Your problem is, you can't seem to hire any women. No matter how many events for women in tech you have, no matter how many women you get into the pipeline, you never end up with as many as you want getting through. You might be aware of other problems with your hiring process, maybe a friend you know wasn't able to make it through, despite being smart and capable. Maybe you give out a lot of offers, but despite them being generous offers, few are taken. Maybe you're interested in a candidate with a non-traditional background, but you know your interview process will grill them on things they are weakest at, robbing you of the talent you need. Maybe you just hate whiteboarding, which sounds like an enhanced interrogation technique. 

So what is there to do? After all, there's a shortage of talent, but no shortage of pretenders to software engineering. Candidates that can't code fizz buzz are rampant, and new grads from nearby colleges are whisked away quickly by Facebook or the Department Of Defense. You don't want to waste your company's resources on someone who proves down the line to be incapable of doing the work, 2 months of salary and a bunch of onboarding time down the drain. The question is, how can you tell the difference?

First, let's talk about the information you're actually after. What kind of information do you actually need to know, in order to know you want to hire someone?

What do you actually need?

For me, I need to know someone can learn fast (ie, is smart) and communicate well. No one starts a job knowing the whole tech stack, and many people start without the requisite language experience. Really just being able to pick things up without being told over and over again is a good indicator. I also need to know that they'll communicate well, and tell me when they don't know something. Pairing with someone can show me both of these things, and can give me another insight as well. I typically expect a developer to be able to research things and learn things by themselves, not just when I'm sitting there spoon-feeding them. So, giving the interviewee advance notice that you'll be pairing, and what technologies you'll be using gives them a chance to prepare. As a senior developer who mentors a lot of junior developers, it's much simpler for me to show up to help them if they have already prepared, and can demonstrate to me where they're stuck. 

An example:

I'm in contact with a potential developer named Jane. She's been developing in Python but mostly in Javascript for about a year. She's used Django before, as well as Flask. She's never worked on a super complex webapp, because she's mostly been in the front-end for awhile. I need someone to do some work in the back-end, so I don't know if Jane will be a good fit, but she's expressed strong interest in doing more server-side work. I've brought her in for a culture interview, and she gets along famously with the team. I've decided to bring her in for a pairing interview. 
The main things I want to test are her knowledge of server-side web development. In particular, we have a lot of asynchronous processes that run to integrate our application with other services. The nitty-gritty details aren't important, I want to test Jane's thinking style, and know whether or not she'll be able to understand and work on these kinds of problems.
I'll send Jane this email:

Hi Jane,

I wanted to drop you a line and see if you'd be interested in coming in to do a pairing interview. You got along so well with our team, they wanted me to bring you in for a second round. 

Because you've been mostly a front-end developer for awhile, I'd like to focus on your back-end skills. We'll be creating a small Flask app that serves JSON, but we'll also be using Celery to schedule data processing tasks. We'll be creating an app that allows a user to sign up with Facebook or Twitter. That user will then be put in a queue of users to be processed. We're going to try to find people they're connected with that also use our app, and then notify them that they have friends using the application. It will probably take us all day to get this done, so plan on a full day of coding with me. Also, take a look at Flask, Celery, the python-twitter module, and the python-fb module. Let me know if you have a preferred editor or any tools that will make you more effective.

I'd like to give you some time to prepare, so does a week from now sound good? I have Wednesday and Thursday next week available for this, or the week following on Tuesday.

Thanks, and let me know if you have any questions before then.

In this email, I made sure to do a number of things. First, I made sure she understood we were interested in her. Many candidates, especially women, have serious problems with impostor syndrome. They might be sure of their code, but aren't sure of themselves. They don't know where they stand, and this weakens their resolve. Starting from a place where they can feel confident will help them perform at their best.

Second, I was clear about what we'd be doing, and why. Many candidates that complete coding challenges or whiteboarding problems don't know what you're looking for. Other interviews with other companies, friends and colleagues are giving this person advice about what to accentuate and show you - this advice may or may not be correct. You might be looking for a front-end developer but not care about their UX skills, what you want to see is performant code. When they lay on thick with the transitions and sparkly colors but don't bother to optimize, you'll pass on someone who is normally good, but just got out of a process with another company who wanted clean lines, not clean code. In a normal workplace situation, you'd be able to give feedback and get what you want. Why not do it in an interview?

Third, I told her what to familiarize with, and I made it clear I expected her to prepare. Too many times we've been judged because we didn't know a command-line tool, a common module, or something someone has decided we absolutely need to know in order to program properly. Given the diversity of applications of a given language, how could we possibly have a canonical set of tools or modules? 

Preparation isn't something that will cause you to receive fake signals. In an actual job situation, you'd have time to prepare and research any given solution before you begin programming. This doesn't mean you never have to think on your feet, and during my 4-to-8 hour session with Jane, there will be many opportunities for me to make her think on her feet, and show me her just-in-time learning and problem-solving skills. Doing the search of the graph, for instance, or intelligently processing a queue of users will be great examples of her having to learn a new way of doing things. There are also enough things for her to learn that she probably won't end up finishing them all by the time we pair. It will give me a chance to know if she's a preparer or a procrastinator, and it allows me to do it in a friendly setting. 

Other Tactics

This example is one of many tactics to use. Contracting is also a valuable and useful solution to not knowing whether or not someone will fit in with the team, or be able to do the work. Depending on your company, you might have a backlog of bugfixes, support emails that require doing research in your codebase, or a mystery to solve due to an intermittent error. Exposing someone to your actual code, or watching someone solve a problem on a computer rather than an arbitrary environment will help you know whether they're a problem-solver, not a syntax-memorizer. If you want to use contracting as a means to interview someone, keep a developer environment set up for this purpose. Having something ready decreases that day-long setup process that most developer environments take to setup, and you don't want to pay someone to watch things install.

The main thing here is removal of as much intimidation as possible. You want a working environment where people trust one another, where we feel we can ask questions, both because we don't know, or because we've found a better solution. Fear, and problem-solving in the face of fear isn't a useful metric to judge any person by - how does it help to know how someone does under the worst possible circumstances? 

On Attracting Talent

Hiring is often approached at the 50,000 foot view. "Smart and scrappy" is great at that height, but in order to actually hire you have to connect on a human level. You have to zoom down 48,994 feet. Once you've said "I need the smartest people in the industry", you've applied a filter, and it's not the filter you believe you've applied. Most of the best programmers are humble. The more you understand about software engineering, the less likely you believe you're the "best". Overconfident engineers move fast and break things, yes, but they tend to break the build too. Women, as everyone's brought up, tend to have impostor syndrome. We don't think of ourselves as the best in the industry, nearly ever, despite the reality of the situation. If you'd like to attract more "A" level talent, be clear about what constitutes "A" level. Qualities, over qualifications. Ability over identity. Be clear about what kind of person you'd actually want to hire, and how much growth you'll want while they're in that role. Focus on what they'll do, not a checklist of skills. Being clear about what you'll actually accept is going to get you people who are honest about their talents. 

Another example

An example job posting for a mid-level web developer at a python shop that would appeal to most women I know is this:

We're looking for an engineer with 2 or more years of experience to draw on. This person needs to have the learning mindset, someone who wants to pick up new skills and research new ways of doing things often. 

You're expected to know these things:

  • What happens when you type "www.example.com" into a web browser.
  • Any scripting language, though some experience with Python would be good.
  • Enough Javascript to manipulate the DOM
  • Know the box model with respect to CSS, and understand HTML to the point where you could knock together a reasonable bootstrapped site.
  • Understand how to build a basic API with any web framework
  • Understand how to schedule tasks to do data processing, in any language.
  • Know some SQL, and know how to use any ORM. Know what an ORM is.


If you know at least 80% of that list, go ahead and apply. Our office is in San Francisco, on Market street. We use Python, Django, RabbitMQ, NGINX, Redis, Postgres, some Node.js, and a smattering of other technologies. Our team is comprised of a lot of young entrepreneurial types, as well as industry veterans. We have a lot of fun at work, and our culture runs heavy on the nerdy side. A picture of our office:

[put a picture here.]

Perks:

  • Market Salaries / Standard benefits
  • Catered Lunch *
  • Commuter stipend *
  • Equity
  • Bike parking on-site *
  • Gym memberships *
  • Lots of beer in the fridge
  • Tech talks / continuing education incentives *
  • Travel if you want to / Don't if you don't *
  • Work from home whenever *
  • Bring your dog to work on M / W / F *
  • Wellness stipend *
  • 2 months maternity / paternity leave *
  • Childcare subsidy *

That's a lot of perks, I marked the ones that women and married men tend to prioritize more than young bachelors. This posting talks about what you actually need to know and the proficiency level, rather than a laundry list of buzzwords. This will also get you fewer emails from recruiters, who tend to only be able to produce laundry-list candidates. Focusing on what it would actually be like to work there helps candidates that would fit in well actually be able to imagine themselves working there, which increases the chances they'll be able to do well in the interview. 

What you actually want is more people, who feel more empowered, to do more work. You want to output the best product or service you can, and so enabling someone from the very first time you talk to them is crucial. Hiring itself is emotional labor, because what you're doing is seeking to understand someone, not testing them. You're trying to bring someone into the fold, not put them through a trial by fire and then expect them to be able to trust you. Software engineering is probably 60% learning, and 40% problem solving. Learning requires vulnerability - don't force your talent to do 60% of their job away from you, because they can't be vulnerable around you. They won't learn what you need them to, and they won't ever really feel appreciated in their job. Having a process that begins by taking candidates and their time seriously sets a tone that the right candidates will match. Fits will be more obvious than ever, and your culture will improve. You'll also end up with the right mix of diversity that will help you innovate.

Contact me if you're in need of consulting on this. Hackbright Academy and Ashe Dryden (and her book) can also help you fill your pipeline with smart, scrappy ladies, and explain how to hire properly. 


]]>
tag:lizthedeveloper.com,2013:Post/628117 2013-12-08T20:19:23Z 2014-11-27T09:15:58Z Create a community the hard way

At Hackbright, we have a strong community. Our students, mentors, partner companies, even applicants we regretfully turn away are very involved, and contribute in a positive way. I've been asked, how did we get here? I've actually been thinking about it myself recently, and I've figured out how we did it. We used one guiding principle that maybe we weren't strictly aware of, but we've followed faithfully and over time, we've built an awesome group of people that continually surprise me.

Love is all you need

I'll get into details, so follow me here. 

Our main guiding principle is that we love them. Love them really, honestly, like they are family. 

It turns out, you can't actually get anything worthwhile without caring about it. Think back to every job you've had where you didn't care, where the seconds ticked by like minutes, and the minutes were hours. You probably found yourself resenting your boss, your customers, which in turn feeds the cycle of resentment.

Now think of a place you've been, some organization, where you cared. Maybe this was a school, or a church, or a volunteer organization. Maybe you were lucky enough to have been part of a company that cared about you, and you in turn cared about those around you. However, excepting perhaps in the case of a church, you probably wouldn't describe that feeling as "love". You might say, "I love my job" or "I love this company", but what you likely meant by that is "I really like this job".

This is a step further - this takes something from you, but gives immeasurably back. Being a part of a community with the right stuff, the stuff people will pour their hearts into, that requires actual love. 

This is not to say, happy-go-lucky hippy flower power time prevails all the time. This past class, "Hackbright" became a verb, which means "to cry on the floor of the bathroom". Emotions don't run that strong when you don't love something. Familial love doesn't come easy most of the time - think about the screaming fights you've had, and times when you've had to cut a family member off because that was the only way they could get better. Sometimes, you have to say something difficult to someone, and then they don't understand, and they hate you for it, and you have to wait until they come to an understanding on their own. 

But think about this - you'd do pretty much anything for your family. Anything to ensure they have a happy, healthy life. Anything to make them more comfortable, their lives easier, to make them better than they are. These actions are how you tell them you love them, not by saying "I love you", although verbal affirmation is an important action to take. 

So, how to create a community? Love them. Honestly, deeply love and care that they are able to do whatever it is they have their heart set on, and help them to do that. They will love you back, and they will love each other the same way. Do the love thing in your own way, we each have our own special-snowflake way of showing it.

The Business Case for Love

This totally works, by the way. We're not the only ones doing this. I can name some companies offhand that love their customers in an authentic way. Zappos, Rackspace, Keen.io. There are many more, but those are companies I can especially call out. They range from large to small. Famous to startup. The common factor is authenticity, and success. You can't fake this kind of thing, and if you try your customers will know. 

When your customers know you love them, they don't switch brands at the slightest slip-up. They don't leave because you're not perfect, because you're not the cheapest option. It's no longer a race to the bottom line with your customers when you have an actual relationship with them. Much like a real relationship, the other person doesn't leave because someone is slightly more attractive, or makes slightly more money than you. These things are superficial compared to the relationship you've built, and your competitors can't make a dent in that. 

They also are typically prepared to pay more - when you create a relationship, your customers see your product as unique, even if it's not. You're probably not the only person out there doing what you're doing, but relationships are unique. Your customers pay for a relationship, not a brand, not a product. 

Roadmap to Love

1. Understand that your customers are the reason you exist. You might be a startup or a global brand, but because these people like what you do, you get to keep doing it. Be thankful, be awed.

2. Internalize this message, and spread it around the organization. This is easiest if you're a startup, because you can be selective with who you hire. Look to Zappos if you're not a startup.

3. Show your customers you love them. Think about what you'd have to do to prove to someone that you love them, without saying it out loud. Show them with actions. Prove to them they're your favorite customer. 

Human support agents, email response times, caring that issues are resolved, following up. Selling things at a reasonable price. Ad campaigns that take your customer seriously, as though they are smart, human, and have dignity. Messaging that talks about who you actually are as a company, as a group, instead of pandering. Compassion when your customer messes things up. These things and more come out of that simple principle, so prove you love your customers, and they'll love you back.



]]>
tag:lizthedeveloper.com,2013:Post/609052 2013-10-15T18:00:00Z 2013-10-15T23:36:45Z How to have an Awesomely Inclusive and Radically Transparent Hackathon

We had a hackathon last weekend, and we managed approach organization and inclusivity from a perspective of transparency and empathy, which made the event rock pretty hard.  We did it with not a huge amount of radical change, but rather a few subtle changes that made all the difference, and I thought I’d talk about them in case someone else wanted to deal with the same things we did.

These aren’t simply box-ticks, they’re different approaches borne of different attitudes, so I’ll also go ahead and explain why we made the small changes we did, and what we were hoping to achieve.

Events need user experience design too - someone who’s going to think about how the audience feels is key to have on staff. For that, @aerialdomo(main organizer), @undeRStandig and @janardanyri were critical members of our planning group, they were key to understanding how our audience would experience the event, and interface with the organizers.

A Clear Narrative

We wanted to invite our attendees to participate in a narrative about the event we were having. We couldn’t have thought properly about how to do that without writing the actual narrative first, so we wrote this:

My friends and some people I recently met (mostly women) formed a team of 5-7. We got some hardware to develop with, and were encouraged to bring our own parts. We brought something from home, and added it to our project to make it unique. We didn’t know much about hardware, but there were extremely helpful mentors at the event. Everyone learned something from the mentors, and everyone contributed to the project. Then, we presented our product to the audience, and everyone cheered. We won a prize, which wasn’t a huge prize, but helped us feel recognized for our efforts. In the end, our team made plans to meet up a few more times to work on our project, since the supplies are shared and we want to continue learning more about working with hardware.

Writing a story like this, where the story is generic to all teams, but is a basic template, will allow you to design the schedule and guide your audience to participate in the story. For more examples of this, look at storyboarding a game. What you’re creating is an experience, not just an event. Write a story, and invite people to participate.

Getting everyone ready for what was going to happen next was the main job of the organizers, and it kept us busy throughout the event. Clear communication was our goal, which gave our attendees prep time for everything from talks to dinner. Some tips for creating a narrative:

  • Write the story of the event you want people to tell. A template allows you to understand what you need to do in order to create that experience.
  • Post a highly visible schedule. Include food, speakers, presentations, and availability of mentorship. Set expectations about what attendees are supposed to be doing. 
  • Incentivise following the narrative, be clear about how to obtain the incentives.

In our case attendees, who were self-identified beginners, were supposed to be using a box we had given them and well as their own supplies to create a physical object to show to the other participants. They understood this as the storyline, and participated. Because of this, 90% of teams presented. 100% of teams created hardware-based projects. 80% of our audience was female, and 60% reported that they had never programmed before.


Removal of Barriers

A huge part of the success of our event was removal of barriers. Essentially, we did more experience design by thinking about common objections people might have to signing up and participating. We did a lot of brainstorming around “well, what if someone doesn’t want to come because”, and then we did our best to remove those barriers. I’ve included some examples from our hackathon.

Our first, and biggest biggest barrier to hardware hackathons is the hardware itself - it’s expensive, and most people don’t know where to buy it, or what to buy. Even those who are apt to dive in and purchase something usually don’t know where to start or what to buy, so we did that legwork for them. We bought SparkFun’s Inventor’s Kit - they have “lab” discounts for bulk purchases. The kit comes with some amazing things, the biggest one being the book that comes with the device with lots of examples to build, and colorful, large, easy-to-read diagrams. It also comes with a wide enough range of sensors to push the imagination, while keeping them simple enough to be approachable.

The next barrier is that, unlike software, circuitry does not have as tight of a feedback loop, or comprehensible error messages. It’s difficult to dive in on your own, so we saw a potential attendee imagining sitting at the hackathon, unaware of what to do next or how they could contribute, and then opting not to embarrass themselves. We made it clear that mentors would be walking around at the event. We kept the mentorship recruitment in the same social media channels as the attendee advertisement, so that our attendees could see what we expected of the mentors. We also kept the ticket count of mentors visible, so that attendees could guess about the ratio of mentors to attendees. We helped them form a clear picture of what it would be like to be completely new to hardware hacking and participate in this event, which I think is responsible for the ratio of people who had no experience we got to come to the event, as well as display of amazing projects that got pushed to completion.


Experience Design

The other main thing we payed a lot of attention to was the design of the rest of the experience. In order to be inclusive of the most people, we tried to keep the event entertaining, with speakers and prizes and lots of audience participation. We also needed to keep it family-friendly, and free of explicit imagery or inappropriate behavior. Some factors that kept women engaged without excluding other attendees:

  • Cleanliness, and calls-to-action surrounding cleaning and organization from the attendees - this helped drive home the idea that this was a community event, not just some corporate stunt.
  • A code of conduct enforced in a way that appealed to empathy over public shaming
  • Specific encouragement of minors and family participation
  • Inclusion of noted advocates for hardware and learning, like Highway 1 and Julia Grace


Enforcement: Empathy over policy

We had a code of conduct that stated no sexual imagery in presentations, as the event was family friendly, and the inclusivity aspect was very important to us. However, we had a team that wanted to bring together two pieces of hardware that weren’t appropriate in a family-friendly setting. The project was interesting, and the team was enthusiastic and genuine. Rather than kick them out, we had a conversation with them about how we could allow them to continue with their plan, while respecting everyone at the event. We settled on having them not use the hardware out in the open, so that no one (especially minors) would stumble upon it. Next, we had them do any testing they needed to do in an area we blocked off for explicit content. Last, we made it clear that though they would still be eligible to win prizes and pitch their demo, they would have to do it off of the main stage, and after the other teams had pitched.

We might have had the demo pitched on the main stage and asked minors and those who might be offended to leave. We chose instead to have the team pitch the demo in an area where attendees would have to explicitly go. The difference is subtle, but important. It sets a tone - one where we’re not forcing you usher your children out of the room, or visibly work your way out of a crowd of 200 people because you don’t feel comfortable or just don’t feel like seeing explicit content at the moment. Instead, we invited adults to come see content of a mature nature in a different area, which set the tone of getting to see something interesting and fun. The idea is an explicit opt-in, versus an explicit opt-out. This is the difference between a vulgar joke in a comedy show, and a vulgar outburst in a restaurant. One is something people are prepared for, one they have consented to. The other is intrusive if you’re not ready, and weren’t expecting it.


Empathy and Transparency

We were able to have a great deal of fun with the hackathon, without worrying about whether or not we were being “politically correct” or not, by changing the conversation. We approached each decision we made by thinking about how our attendees would experience the event, and by appealing to empathy, rather than strict rules. By communicating what we were going for, the experience we were trying to create, our audience helped us achieve our goals. We were clear about our thinking process, rather than seeming to make exceptions for some people, but not others. Our community developed a great deal of trust for us as organizers, and have a new expectation about how events can be managed.

Our code of conduct is posted here - feel free to use it for your hackathon. 

We hope you can join us for the next one, as a mentor or an attendee, or even as a sponsor. We sold out this event, so we’d love to offer it again for everyone on the waitlist, and the new batches of students that will be coming through Hackbright Academy. Let us know if you’re interested in getting involved





]]>
tag:lizthedeveloper.com,2013:Post/606086 2013-10-03T21:16:53Z 2014-05-10T03:23:34Z Scarcity and Hackbright - the Top 5%

There are some major parts of Hackbright that deal with scarcity. Our business model (and we are a business) is based on it, and our company philosophy (and we do have one, one that's very important to us) is based around it as well. First, let's talk business.

There aren't enough developers. Not in Silicon Valley, although you can't sit in a cafe without hearing about code or devops. Not in the rest of the world, either. There are nonprofits that need help, terrible industries that need to be automated away (I'm looking at you, medical billing), and information that needs spreading to the bottom billion, so that they can be informed, and more powerful. This kind of thing sounds great, but in order for any of those jobs to get filled, there first have to be enough developers to go around. And there aren't.

There also aren't enough women in development. There are probably a million and a half ways to solve this issue, we're choosing one path. Increasing the number of female devs directly by training them is a great start to help with the issue, as well as solve the scarcity of developers. This brings us to supply and demand, and scarcity. 

We exist because companies can recruit from us. We provide enough high-quality candidates that companies come back to us time and time again. The reason our candidates are high quality is because we train them, yes, but also because we select them from a pool of smart people. Currently, we accept 5% of candidates that apply to Hackbright. Why? Wouldn't it make sense to take more? We're a for-profit company, the students pay us to attend. We're leaving money on the table by not accepting more - we could double our earnings by accepting 10%, right?

The problem here is complex. It's about keeping our quality high - as a company, and for our students. We try to do the right thing for quality first, profit second. Scaling out doesn't make sense if the experience gets worse, or if fewer of our students end up with jobs. The reason quality suffers is because of scarcity.

First, we're doing very emotional labor. Emotional labor is traditionally undervalued, and it's also regarded among the professional world as a limitless resource. If you're a caring person, you should be able to expand that caring to an infinite set of people, right? This is a fallacy - one person can't be the emotional pillar needed from a teacher to as many people as they're asked. Even given that there simply isn't time in the day to do that, we're ignoring the fact that helping someone through something difficult, like say, rewiring your brain to think like a computer scientist in 10 weeks, takes something out of you. It's rewarding, sure. It gives something to you that you can't buy or get otherwise. But it does drain. 

So the emotional labor is scarce - people who can both program, debug well, explain things well, and do the emotional labor are scarce, but the biggest scarcity is people willing to do that labor. This labor is traditionally reserved for significant others, friends, your children, your family. When doing this work, students often replace your friends and family, become as significant to you as your children. You have to be willing to do that to at least a limited extent, and most people aren't, or at least not for long. 

The next scarcity is space - simply having enough desks and pairing stations in a city like San Francisco is both expensive and hard to find. Keeping everyone together as a cohesive class unit is also tough. 30 is probably the maximum number of people that could function as a class, especially because being a part of the class is such an integral part of Hackbright in general. We can't just upsize the class, we'd have to create an entirely new instance of the class - with lead instructors, assistant instructors, a new group of mentors, et cetera. 

The last scarcity is absorption. The bay area needs more developers, but has a limited capacity to absorb new junior developers. Everyone who comes out of any intensive is essentially a "prepared beginner", who, through their own curiosity and drive, as well as a bit of help from a senior developer, can add functionality to software projects, run tests, debug, and make modifications. They're not yet capable of designing a project that scales, or spinning off an entire feature branch without much help. They do consume resources when they join a company, although the company gets a net gain. After about 3 months, all of our students are major contributors in whatever teams they join, but it does take that 3 months. We release 26-30 new candidates quarterly, and they've got to go somewhere - there are a finite number of jobs even for perfect candidates with the exact right stuff.

]]>
tag:lizthedeveloper.com,2013:Post/600960 2013-09-12T07:05:42Z 2014-05-22T22:52:24Z Pedagogy and why we only accept women at Hackbright

I recently wrote a post regarding why we only accept women into Hackbright's engineering fellowship. It received some criticism, and I'm completely open to that criticism, as that post largely was about philosophy. Philosophy differs, and there's nothing anyone can write on the subject that won't have some debate, some disagreements, and some controversy. 

What I'm addressing in this post is pedagogy. The method or practice of teaching. I'm going to talk about women's performance in STEM education, and about the learning environment. What this post is NOT about is workplaces, or suitability, or what I can and can't do. It's also not about Hackbright's mission or philosophical goals. It's simply about the science and art of pedagogy, and what I've personally witnessed as a teacher of computer science.

Women learn differently than men. Human beings learn differently than each other. There are learning disabilities, aptitudes, magnet programs. There is a profound difference between what you, the reader, and what I experienced in school. Because of this, different programs must abound in their complexity and approach. A master teacher cannot reach every student, but a skilled teacher can vary their approach by the person for maximal effect and understanding. 

Currently, there is a problem in STEM education for women. Right now, it favors men. Largely this is because of subtle biases in how STEM material is taught, and because of how many women experience that material. I'm speaking of women as a group, but I'm talking tendencies and trends, not about women as a whole. I am sure everyone reading this can think of a counterexample.

There are many, many problems with STEM education, I will enumerate some of the more relevant ones to this post:

 1. Most classrooms are male-dominated, and men tend toward high degrees of competitive behavior display when in groups composed mostly of men. When women are present in this group, many women feel uncomfortable competing in a large group of men.

 2. While most people lack confidence getting into something for the first time, they often warm up to the problem by seeing role-models, or by joining a peer group that supports them. Women often have no role models readily available (especially in terms of mentorship) and have no peer group, in terms of other women.

 3. There are subtle biases from professors, directors, counselors and other faculty that often ostracizes women.

 Many of these are problems women will encounter in the job market, and in the rest of their career should they choose to go into software engineering. My main conjecture is that the learning environment is necessarily different than the real environment. In the learning environment, you will fail, and fail often. You will not understand things. You will become upset with how hard you have to struggle to get through things, and you will do it without the firm ground that prior understanding gives you. During this, is it really necessary to add biases, insecurity and fear of ridicule? Computer science is a discipline with a fast feedback loop, allowing you to try and try again until it works. As a student, you are limited only by how fast you can understand new concepts. Removing these limitations is paramount, and the limitations are largely defined by having a peer group that can accelerate you past your struggles.

 Studies show that women's classroom engagement goes up when women are in a single-sex classroom. They also show better test scores, lower dropout rates, better knowledge retention, better critical thinking skills application, more lateral thinking, better ability to engage in meta-cognition, and better ability to think overall. It also shows that students have better mental wellbeing during and after single-sex classroom education, have more self-confidence, and feel they know the material better. They hesitate less on the job, and they are better equipped to penetrate the obscure social cues associated with an industry. 

Self-confidence, and these mental health gains are significant. From The Australian Journal of Education on The Effects of Class Type on Student Achievement, Confidence and Participation in Mathematics,

"Despite some limitations in the data, the results indicated nonsignificant gender differences and a putative causal relationship between confidence and achievement. 

While the change in students' mathematics achievement over time, independent of confidence, was similar for all students, regardless of class type, there was a significant class-type intervention effect on students' confidence in learning and using mathematics, independent of achievement. 

 Moreover, for those students concerned, being placed in single-sex classes was associated with greater confidence which, in turn, significantly increased the likelihood of their subsequent participation in senior mainstream mathematics education. "

This doesn't even account for what I've seen. As a teacher, I use data to inform my technique, rather than trying to dictate how all education can be done in the general case. Informed by this research, and my previous experience with Girl Develop It I've noticed that women ask more questions, pair program with more engagement, show better retention of earlier concepts in later exercises, and most importantly enjoy the subject more. I'll get into this more in a later post, but when you love what you're learning, you understand it far deeper than things you don't. I think that last sentence is the least controversial thing I've ever said.

]]>
tag:lizthedeveloper.com,2013:Post/600854 2013-09-11T20:15:01Z 2016-10-31T08:19:48Z Why does Hackbright only accept women into the program?

Another blog post transcribed (thanks @rebecca_standig) from the same conversation about @Hackbright Academy. It also covers some hostility I get from people about our policies.

EDIT: changed "where all but about 80% of women" to "20%" - that was a mix-up on phrasing. 20% of women who start in comp sci degrees finish them.

Note: Hey Hacker News readers! I'll be publishing something on pedagogy in a bit. Stay tuned. 

So, why do you admit only women to Hackbright?

I've gotten this question really often via email, as well as at coffee shops and any time that I walk around the Mission or SOMA in my Hackbright Academy t-shirt. Often, people ask me why we only admit women. They say things like, "It's discriminatory. Aren't you trying to fight discrimination?" Or they say, "You can't just admit women. That's illegal." Or they threaten to sue me. People think that they're very clever.

The reason we only admit women is because as it stands, we put more women into software engineering in one semester than Stanford and Berkeley do every year. Women start a computer science degree at maybe 1/3 the rate as men. Then there's this freshmen drop-off, where all but about 20% of women end up changing their major, usually to something involving design or business. Sometimes, they go into electrical or mechanical engineering, but that's actually pretty rare. Usually they leave the field of engineering altogether.

I have a theory about why this is. During a computer science degree, most women don't have a lot of friends to turn to who are also doing a computer science degree. Most computer science education is heavy on theory and light on implementation. So, you learn a lot about computer science, but you don't really learn how to code. That is something that you have to do on your own. Since [these women] don't have friends that sort of expect that of them and know that that's what they're supposed to be doing, they don't spend a lot of time in it. If you don't spend time implementing theory, you'll never really understand it. The courses get harder and harder, and they haven't spent a lot of time with their friends talking about these kinds of things. They're surrounded by people who are not like them, and don’t openly talk about struggling to learn [difficult programming concepts]. This reinforces the idea that they don't belong there, and is a common fear. All the time, women tell me that they feel like they don't belong in computer science, or they don't belong in engineering, or they don't belong in a company as a programmer.

The reason for that is there aren't many women, and that begets even less women wanting to get into computer science.

So, what’s the solution?

So what do we do about that? First, we create a community. There are lots of communities for women. I know this because I'm a woman in tech, and I am inundated (especially as a leader of several general organizations for women in tech) with people telling me all about all of the different organizations. The problem is, I meet 4-5 women every week that have never heard of any of these organizations. So outreach is a problem.

The next problem is that it's intimidating even to join these big organizations because they're for people who profess that they are software engineers already. Sometimes, they're about being software engineering majors or computer science majors, and that helps. But they're campus-specific, so if you're in college that's great for you.

Most women who get into computer science that I interface with are doing so after they've already completed a degree in some other area, be it business, marketing, biology, chemistry, sometimes journalism. There are a number of things that drive people away from those fields and into software engineering, or just drive people away from software engineering initially into those fields and then they realize that this wasn't what they wanted.

These are the people that most often make really amazing software engineers, yet have no real path into software engineering. They're not already software engineers, so they don't feel like they can join these organizations, but they're also not going to college for software engineering, because they've already gone to college. It would be ridiculous to expect them to go and get another four year degree or a two year master's degree that they may be ill-equipped for. So these are the people we serve. They're a minority that needs a leg up. Just like having a foundation that helps Asian Americans or Hispanic Americans or Indian Americans get a leg up in an unfamiliar place, a place where you are underrepresented and generally marginalized.

That's why we serve only women.


So, what about the people who think you “have to” admit people?

We don't have to admit people. We're not a school that is accredited by the US Board of Education, nor are we a non-profit. We are a for-profit company, but we're a for-profit company with a mission.

That mission is to bring equality to computer science. Our strategy for doing so is the following: One, only let in people who will contribute to equality in computer science. Right now, the smallest subgroup of people in computer science is women. Other than, potentially, transsexual people. They're a small enough group, though, that if we were only to serve them, I think we'd go out of business. Women make up half the population on the planet, yet only about 6% of computer science engineering jobs.

The second thing that we aim to do is promote the idea that women are competent in the field. They are smart and useful, and just as smart and useful as men, and should be taken seriously. Rather than admit literally everyone who comes in, we admit the top 5% of our applicants. Now, these might have been people who would have gotten into computer science some other way, and that's great. But what it does by producing a candidate of a consistently high quality is further promote the idea that women are just as competitive as men in computer science. By putting out really excellent women into computer science, we reinforce a positive stereotype. Stereotypes are not all bad; positive stereotypes are great. We would love to reinforce a positive stereotype, which will help combat all of the subtle biases that work against women in computer science.

The last thing we do is make sure the insecurities and vulnerabilities that causes women to leave computer science in the first place are patched. We do some drills in the safety of Hackbright on whiteboarding, on salary negotiation. We do some generalized therapy, just by talking out insecurities and fears. We get very involved in their emotional wellbeing, because it matters a lot. The most productive software engineers aren’t afraid all the time, or down on themselves - they feel empowered. So, we do our part to empower our students.


]]>
tag:lizthedeveloper.com,2013:Post/600377 2013-09-10T07:54:13Z 2015-07-19T01:44:09Z What do I look for in a potential Hackbright Student?

I had my cousin transcribe the following conversation, which answers a lot of the questions I get asked during interviews. I went through and added a few links to it, but it's generally unedited- it's just how I talk with the "um"s and "uhhh... [long pause]"s taken out.


So, what do you look for in a potential Hackbright student?


I get asked that a lot, actually. What is it that makes us see a person and say, "Yes, we're going to admit them into this program and ignore 95% of people. But this person, yes, we believe in them." The answer is simple. But the backstory is a little more complex.

Salon recently published an article called "School is a Prison - and Damaging Our Kids." It is. That's the biggest problem. School, as an institution, was created to teach children how to not question authority, and how to crush their own curiosity for the betterment of absorbing someone else's ideas. It is mostly about causing someone who might otherwise be compelled to learn whatever they wanted to on their own to instead accept what they're being taught. This system worked really, really well during the Industrial Revolution, when the highest demand was for low-skilled factory workers. Today, that’s not the case- knowledge worker jobs are on the rise, and are going unfilled, but not for the reasons you might think.

One of the biggest things that our school system does today is cause people to start thinking like factory workers. They start questioning the audacity to want certain things, like respect in their field. They stifle their own thirst for knowledge and think, "Well, I don't need to know that. I only need to know certain things - things I've been told that I need to know in order to get a job, or have the life I’ve seen on TV."

What we're looking for is somebody who was terrible at that kind of thinking. We're looking for somebody who isn't very good at being told what to do or doing what they’re told. We're looking for somebody who is actually often bad at school and bad at listening to directions. Instead, what we look for is someone who is very good at following their own thoughts about what it is they want to learn.

Now, usually someone who has always decided to follow 100% their own thoughts and feelings about what they want to do isn't what we're looking for. What we're really looking for is someone who has had to fight that system so hard and so long, and had no help doing it. What we want is to be that help. I say this to people often: "I take people that were always meant to be software engineers, and I rectify that mistake."

That's sort of the secret of what we're looking for at Hackbright, but often times the reason these people aren't software engineers is because they're just no good at identifying the fact that they should be software engineers. So, don't think that just because you think that you aren't a software engineer deep down inside that that means you can't be a successful Hackbright student. What we're looking for is somebody who fits the philosophical profile of a Hackbright student.


So then what’s the philosophical profile of [a Hackbright student]?

Well, the philosophical profile of a Hackbright student is somebody who is curious, is uncompromising in their search for answers, who has a questing approach to truth rather than an accepting approach to truth, and has a natural affinity for systems. They have an affinity for logical systems, for mechanical systems, for how things work. This often means biologists, but it also means mechanics, and it means people who are interested in law. We have a positive correlation with law a lot. Chemistry, physics, math.

The biggest thing that is often found lacking in people who would normally correlate  really well with being a Hackbright student, people who sound great, is the “why” factor. Why are you doing this? Why do you want to know? Why have you done everything else in your life? If you ask that question on a constant enough basis, it leads you to act a certain way. That's what we're looking for most of the time, when we ask you all about your background. We want to see evidence of you asking why. We want to see evidence of you looking at what you're doing, looking at the world you've gotten yourself surrounded in, saying "Why?" and in some cases being unable to answer that. That’s when you have to jump ship- to change what you’re doing. We see half-finished degrees and projects abandoned a lot. A lot of people are leaving what they thought would be their dream job to come here and change their life.

Jumping into a situation is the only way to really learn about it. By asking why, that shows that you've learned about it, you've sought out enough information to understand where you are, and to get to the point that you can critically assess whether or not you're in the right place. If you can critically assess that you're at the right point, you're fine, and you probably won't apply to Hackbright. If you do apply, that means that you've decided that you aren't. It's not about the money, although money can be nice. It's not about doing something fun every day. It's about questing for that fundamental truth constantly, as sort of the driving force of who you are, and being unsatisfied when you aren't there.]]>
tag:lizthedeveloper.com,2013:Post/599130 2013-09-05T23:16:18Z 2013-10-08T17:29:25Z Woah, support

Writing that blog post about burnout was very cathartic, and it helped me to feel like I did something about it. It also helped me realize how huge my network is, in terms of support. Most of my students have emailed me. Most of the people that I've ever helped from Girl Develop It, and from other events in the community that I've helped with have emailed me. People from organizations that I care about have emailed me. Friends of mine from all over the world have emailed me. It made me realize that I have friends all over the world, and that I have friends who can help me, and that I can ask for help when I need to. That's a big deal.

Asking for help when you need is something is a skill. It's something that you have to learn to do. In order to ask for help from someone, you need to know what it is that they can actually help you with. Were you to ask your friend who's a doctor for help with your computer, you might not get a very good result. But if you ask them what to do about your stress level, you might get actually a really reasonable and helpful answer. The other thing that you need to keep in mind when you ask a person for help is what kind of time commitment they can actually give you, and how much you are actually committing them to do. You don't want to overcommit your friends. You don't want to ask for too much, but you can ask for a significant amount from people.A big thing to note is that it's not some currency that you're spending on the relationship. You're actually investing in the relationship that you have with a person. What you're doing is you're saying, "I trust you enough to handle something for me, and I would do this for you as well."

So, there's trust. There's investment in the relationship. Then there's that help. The energy of delegating something sometimes seems like too much. Sometimes, all you think you need is for everyone to leave you alone, but don't take for granted that the energy of delegation is going to be too much. It's like a get out of jail free card. You get a chance to take the cognitive load that something would have cost you, and just wipe it away. That's worth a lot, and is actually really helpful.

So, I'm getting help of different kinds from my friends and I'm getting help for my students, which is a big deal to me. I'm getting help with whiteboarding practice. I'm also getting help with development. I mean, people will just do some bug fixes for you, or they'll step up and organize the contributions they're already making for you.

Another huge thing that people have helped me with recently is typing things out for me. For instance, this blog post is being transcribed by my assistant, who I totally don't pay enough to do this. But, she's helping me because I have recently gotten carpal tunnel syndrome so bad that I just can't type or do anything really with my hands. So, I'm able to write and express myself without being in pain, and that's a big deal.

Recently, I had to think through the workflow of an application that I'm responsible for getting out before the next season of Hackbright starts. All of my direct reports helped me walk through that mentally, and offered their advice, support, and thoughts. I got several user stories spec'd out in like 15 minutes that I never would've gotten done by myself. I would have just stared at the screen like a burned-out mess.

It's a bit like pair programming, working through ideas with someone. When you have to talk it out, you can do problem solving in a way that you don't normally do. You're forced to think through the corner cases, and you're forced to think all the way through assumptions that you might make and shortcuts that you might take for yourself. 


Anyway, so that was a long-winded way of saying thanks, everyone. I hope that this post maybe helps you in a way, by providing a blueprint to ask for help from others when you're totally overwhelmed.


]]>
tag:lizthedeveloper.com,2013:Post/598740 2013-09-04T14:00:00Z 2013-10-08T17:29:20Z Teacher Burnout

What happens when caring isn't enough to combat burnout?


I care about my students a great deal. My company, a great deal. Our mission, a great deal.

Burnout comes regardless of where you work, what you're working on, how much you love the people and the things you do. It comes suddenly, and if you're the type of person who takes very seriously the work you do, it will probably come dramatically. One day you won't be able to leave for work, or go to bed for work the next day. You may even be on stage, speaking at a public event when it hits you that you can't do this today, or tomorrow. That you need time for you, and no one else.

I'm an introvert, and I'm doing a very public-facing job. I speak at conferences. I speak every day to my students in a large group. I sit down with people and take their emotional baggage and their fears about the future. I help them through the technical struggles they have while diagnosing where their misunderstandings are, as well as trying to understand what their weaknesses as a whole lie. I try to understand weakness in people constantly, because it is my job to make them strong. 

It is the best job. I can think of no other profession that plays to my strengths as well as this job. People tend to open up to me, I can look at someone's code or their writing and usually divine their thought process. I can look at a thought process, and figure out where understanding falls away, where concepts become fuzzy and hard to grasp, and then I can usually clear the fuzziness by explaining exactly what they don't know, which keeps them engaged because I'm not repeating myself. Managing junior developers or an internship program might be a decent alternative, but it pales in comparison to creating new software developers from latent talent. I also have a penchant for quotability, for simplifying concepts in a dramatic way or for well-worded calls to action. This makes me a good speaker, and a good mentor.

However, I only have so much to give. I know so many amazing people now, so many who have full lives that they very much would like me to be a part of. I know amazing people who need strength of the particular brand that I am great at giving, but at this point I need that strength for myself. I need someone to sit with ME and have that frank talk, that spirit-bolstering pep talk, that serious advice that I take to heart and follow. I need it to come from someone who understands me, someone who can give me advice because they have been there, and back again, and they know how to get me up in the morning and keep me up at night. 

The secret is that I am not actually capable of doing things I don't want to do. I can't grit my teeth and bear it, or just push through because hey, a job's a job. My parents offer this advice constantly, it is useless to me. Because I know this about myself, I know that I very much love my work and don't want to leave it. Being burnt out isn't a sign that this is the wrong work for me. It's a sign that it's very much the right work for me, because I can go as hard and as fast as I want to with this job. I can make impassioned pleas and they will be listened to, log complaints and action will be taken. I can have everything I want, but I have to ration my enthusiasm, because this is the marathon. I can't get too tired and stop, because my energy drives the whole machine, and we can't lose momentum.

So, I need help. I need someone I can trust to be my right hand, to train to be my equal in accomplishment and capability. The potential energy they must possess has to transform quickly into kinetic energy used to drive us all forward, to keep everything moving. Because it is so, so important that we keep going. 

If you're interested in being that right hand, liz@hackbrightacademy.com


]]>
tag:lizthedeveloper.com,2013:Post/598746 2013-09-03T01:30:12Z 2013-10-08T17:29:20Z Why I joined Hackbright


I've been tooling around, trying to start my own bootcamp for about 2 months now. Ever since December, I've been telling people that I'm trying to start my own school. I had big dreams, grand ideas that I felt only I had the vision and drive to actually implement.


The plan was to start a school for women only. Based on my experience with GDI, I noticed that when women are learning with other women, starting at or around the same skill level, they did much better than when they mingled genders. It seems to be about gender, about being around people you identify with and feel safe around. Women learn differently, and they value different social dynamics when they're around each other. That, and they feel less like the class is a race or a competition - instead they collaborate, and are open about what they don't understand.

This isn't to say the model wouldn't have it's problems - women who don't like each other react very strongly, much more strongly than when they don't like a man. But, as this is a learning environment, and everyone is generally very friendly and communicative here in SF, I didn't anticipate any problems there. It would also be very different from a GDI class, we would be pre-screening applicants for compatibility and ambition. By getting to know them, we could structure the class for harmony.

All of this had me very excited - I had trouble sleeping, laying down at night required a pen and paper nearby at all times in order for me to feel like I could fully rest. I'd spring out of bed every day - but the excitement began to wane once I figured out how much legal, financial, and general business development there was involved. It was extremely draining. So I started shopping for a cofounder, and I took on an intern - Lillian Chan, who I had been training in programming for several months.

I started doing competitive analysis on the bootcamps I would have to compete against, and came across HackBright. I had heard of them before, mostly good things from their students, and from people considering applying to be students, the only complaint I had heard was that "they were a bunch of dudes". At some point after hearing this enough times, I started searching through the about page of every bootcamp, trying to find a female teacher anywhere. I found none. Irritated, I turned where we all turn when we have a bone to pick with a community.

I tweeted ..

Are there... ANY female instructors at ALL at any of these bootcamps? /cc @devbootcamp @hackbright @catalystclasssf @ga

— Liz/Ann Howard (@lizthedeveloper) February 6, 2013

Ever quick on the draw, @Hackbright replied.


@lizthedeveloper yes, we are focused on having an awesomely diverse team.We have two women joining our team in March :)

— Hackbright Academy (@Hackbright) February 7, 2013


After calling them out, they offered to grab coffee with me, and we had a bit of a chat. I explained my motivations for wanting to start a bootcamp for women. Mostly, I was frustrated by the lack of women teaching, the lack of focus on hard computer science, the lack of fundamentals, the creeping drift of ideas like "you don't need to know how it works, you just need to know how to use it", and other such nonsense. I feel like teaching people tools without teaching concepts is a recipe for kludgy, unmaintainable code and the inability for anyone to take such training programs seriously. 

Christian expressed the exact same doubts about the other bootcamps in the space. He talked about how Hackbright did command-line on the first day, how they build concepts up, rather than going from the top down. How curiosity carries students deep into how things work, and how that contributes to their ability to understand the ramifications. He was clearly on his game, which I was immediately excited about.

That said, I was working on a competitor. I had business partners, funding, a space lined up, a long-term vision on how to expand in a slow, but steady manner. I was shopping for co-founders. 

I realized after talking to Christian and David that I had never met anyone who "got it" as much as they did. I've yet to meet anyone since. I realized that this was a once-in-a-lifetime opportunity to shape a company, and help two people who have come to be some of my very closest friends. I realized that working against them would make no sense, so I informed them I'd be joining the team. 

It was one of the best decisions I've made in my entire life. I don't think I'll ever regret it. 

]]>
tag:lizthedeveloper.com,2013:Post/598738 2013-07-29T12:00:00Z 2013-10-08T17:29:20Z Learning Resources for Girls (not Women)

Often I am asked for advice about girls in tech. This is largely because I'm so involved in the women in tech movement, but it's also partly because of problems one of the organizations I'm involved in has with branding problems. I'm looking at you, "Girl Develop It!". 

Usually this group is confused for a group that serves "girls", as in, underage female humans, rather than "girls", adult female humans. I'm not exactly one to throw stones, being from Texas. I often use the term myself, even at Hackbright to refer to a group of women who are often older than me. It's the parlance of the area, but it's also enmeshed in the culture to infantilize women. Most chivalry is - but I digress.

I prodded twitter this morning for some advice, because so often I recieve emails from parents asking what to do for their daughters. They face the tough job of encouraging their smart daughters to get involved in technology before the terrible thirteens arrive, and girls start to begin "experimenting" with their identities (disclaimer: I was once a 13 year old girl.) 

Making something part of your identity at a young age is sometimes a recipie for abandoning it later, however starting girls early on the road to being tech-savvy or even ultra-l33t prepares them for a pretty sweet life. Tech skills are in demand, and the only person I have ever known to be more bratty than a supermodel and get away with it is an iOS developer. I'm just saying, there are some aspects of tech work I didn't anticipate when I was 13 that would have appealed to me quite a bit.

With that, here's some resources the twitterverse has come up with.

View the story "Twitterverse Resources for Girls in Tech

  • http://coderdojo.com/
  • https://itunes.apple.com/us/app/hopscotch-coding-for-kids/id617098629?mt=8
  • http://www.ncfirstrobotics.org/programs/jr-first-lego-league/
  • http://www.indiegogo.com/projects/app-camp-for-girls
  • http://scratch.mit.edu/
  • http://www.amazon.com/Game-Programming-Kids-Interactive-Programmers/dp/1937785440
  • http://herideasinmotion.com/
  • http://www.internaldrive.com/
]]>
tag:lizthedeveloper.com,2013:Post/598739 2013-04-15T12:00:00Z 2013-10-08T17:29:20Z 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.

]]>
tag:lizthedeveloper.com,2013:Post/598741 2013-04-15T12:00:00Z 2013-10-08T17:29:20Z Week 10 Roundup

Well I certainly didn't keep up with blogging through the 10-week rollercoaster that is HackBright. I learned, laughed, cried, went through crazy emotional times, and made friends. I also drank a lot of alcohol. 


Week 2 was a blur, mostly lectures in which I trolled Christian to make sure certain points got across well, and to keep him human to our students, rather than some kind of job-bestowing godlike figure. I don't know that I fully succeeded with the second one.  We did a lot of breakout sessions, which I feel like were really helpful. They helped keep each lesson in context so that everyone understood that we may have been doing simple things, but that those things built up to me big deals.


Week 3, my son came to visit. By that point, our students had formed a bit of a bond with me, so me being not there was not too bad for morale. It was however, really tough on me, because I brought him in to work 3 out of the 5 weekdays he visited on. He enjoyed himself enough, and ingratiated himself with most of the students pretty well. Christian showed him the roof and talked to him about physics, which made him instantly reverent. It was pretty cute. 


Week 4, I was playing catch-up, in terms of energy (9yos are very tiring) and in terms of where everyone was in the program. I also stopped making progress on the project I was working on at this point - students needed too much outside help for me to spend time on it, so I was forced to just kind of back off. In the middle of the week, Donglegate came to a head and got really nasty online. Like many women in SV, I responded emotionally to the threats Adria was getting, especially as she's a friend of mine. Due to complexities and traumatic events in my past, seeing some of the images posted online and the vitriol spewed at her, I was emotionally drained and very upset for some time after. Even now, it's tough to write about. At some point, I'll post in detail on this.


Week 5 was a blur - bringing people up to speed on common web technologies and the idea of markup was a big deal. We explained HTML and how it was like Markdown or Wiki Markup, only with a lot more eccentricities helped them deal with what seemed like an impenetrable world. We covered a slight bit of CSS, and then I got to delve into JavaScript. At this point, my energy from the kid visit and ensuing trauma, plus 18 hour days were beginning to wear on me. The lesson I learned here was that we needed more instructors, and that I cannot take time off during Hackbright, or have visitors. Downtime is going to have to be the only time someone can come to SF to see me. 


During Week 5 we also began preparing for projects. We had to very explicitly state that we're not an accelerator. We're not an incubator. We're not here so that you can develop an amazing product vision and start a company. Our students are here to program and to learn things - you can't do that if you're worried about the marketability of a product. Sure, learning happens better when you're solving a specific problem for yourself - when you listen to a lecture on SQL and can imagine using it to solve the problem of how to get two rows of data to JOIN together, it makes sense. If you talk about JOINS in the abstract, it kind of sounds like a crazy, useless concept. So it's useful to have a project you're excited about - but focusing on becoming a crafts[wo]man means you have to focus on the craft, not the business. They're two separate disciplines, and we're not here to make companies, we're here to make developers.


Week 6 was the official start of projects - students were finishing up the final tutorials that would show them how to use SQLAlchemy. Many wouldn't end up using that kind of thing at all for their projects, but understanding the principles behind an ORM is important, because they're more than likely going to encounter them in the wild. 


One thing I wasn't prepared for was the scope of some of these projects. We had webapps of varying complexity - some that had to keep consistent state between two people, some that used multiple APIs and a lot of data, one even used single value decomposition to intelligently rate movies on millions of rows - dealing with datasets larger than the RAM on your computer is not a simple task. But the next tier of projects, things I've personally never even done (although, this does not mean I won't try), things like database engines that handle concurrency, written in a language we didn't teach, using concepts we didn't teach. Things like compilers, lexical parsers, people writing their own programming languages. 


We had a student who read a paper on someone who found correlations between genes and characteristics that had never been noticed before by doing Natural Language Processing on Pubmed papers. This paper kind of contained some abstract notions on how you might do this, but I watched her tear the paper apart, and put it back together in python. It was amazing. Her twitter is @cadeparade, and she's still for hire as of me writing this (but probably won't be for long.) I also got to learn a bit about Part of Speech Processing - which is incidentally really cool.


I had to mention at least one of them, not to show favoritism, but I feel like what happened wasn't real. Like it was somehow removed from the real world. It was like I was out of the country for 10 weeks, and my friends and family kind of watched this amazing thing occur from my excited tweets and late night rushed updates by phone. But it wasn't. It happened right here, in San Francisco. 


Tonight, some of them got offers, which were beyond anything I expected whatsoever. I have no doubt that every single one of them is employable, and would contribute a lot to the organization they end up at. Plus, I have 26 new best friends. 


In 4 weeks, I have to start all over again.


]]>
tag:lizthedeveloper.com,2013:Post/598744 2013-03-09T12:00:00Z 2013-10-08T17:29:20Z 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. 

]]>
tag:lizthedeveloper.com,2013:Post/598735 2012-12-20T12:00:00Z 2013-10-08T17:29:20Z 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. 

]]>
tag:lizthedeveloper.com,2013:Post/598736 2012-01-29T12:00:00Z 2013-10-08T17:29:20Z 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.

]]>