Red Squirrel's Nuts

I constantly forget where I bury my nuts, but at least they sometimes grow trees.

Aug 20 2014

Responding to Jeff Casimir

Last week, Jeff Casimir pointed me at a blog post he had written about coding bootcamp intensity, and invited me to respond.

At the risk of sounding hypersensitive, I’m going to take a close look at his post and respond to both the explicit and the implicit messages he’s sending.

I like Jeff. He’s a good guy with a good school. I react strongly against some of the messages he’s sending and I still like Jeff. :)

Jeff started out with a disclaimer too. He said he respects Dev Bootcamp, Flatiron School, and MakerSquare. Cool, me too!

Then he chooses the word “notoriously” to describe the work ethic of DBC’s students: “Dev Bootcamp students notoriously spend super long hours in the building throughout their nine weeks.”

Huh? Are our students seriously notorious? I mean, I’m glad they’re well-known, but I do not appreciate our students’ work ethic being framed as if they’re doing something wrong. I’d prefer a critique of the pace of our program.

To be clear, our students spend super long hours for 9-15 weeks, depending on their learning speed. About 20% of our students take longer than 9 weeks to graduate, and it’s for a variety of reasons (got sick, new baby, got stuck on one concept, etc). We don’t charge them anything extra for their extra time with us. Our program’s flexibility is one of its key benefits.

Jeff goes on to ask us to “suppose that training the brain is like training a muscle” and then says that overuse could lead to injury. Your brain is indeed like a muscle in that you can strengthen it with deliberate practice. But it’s not like a muscle in that you’re not going to tear it, pull it, or strain it. Believe me, I did my best to strain it when I was teaching myself how to become a great software developer during the first five years of my career. What happened during those long hours and late nights was that I often feel asleep at the keyboard. I got tired, I caught up on sleep. That’s it. Our brains are extremely resilient.

Speaking about the DBC “all-in” approach, Jeff says, “Maybe you can get good value out of that approach for nine weeks, but it won’t work for 27.”

Maybe you can get good value? Maybe? Jeff, buddy, your agenda is showing! DBC has graduated over 750 people, they’ve been hired by well over 350 companies across the country (Turing School is one of those companies). And well over 100 companies have hired multiple DBC grads. In 2014, we have many family members and significant others of DBC alumni attending based on their loved ones’ recommendations. Read the latest report from Course Report and see for yourself. This model undeniably creates value. For God’s sake, people are writing songs about it!

I also need to clarify the 9 weeks vs. 27 weeks comparison: DBC’s immersive curriculum is a 9 week curriculum, but add our 9-week remote prep program (~20 hours/week), the possibility of stretching the immersion by 6 weeks, plus our 5-day post-graduation Career Week, and DBC provides students with up to 25 weeks of instruction for $12k. That’s incredible value.

Jeff is right when he says that we don’t value work/life balance for our students during their immersive experience. We tell our students to put their lives on hold so that they can learn their asses off for a few months. Many of them choose this approach because they want to minimize the amount of time they are unemployed. Others yearn for that immersive foreign language experience one can only get from visiting a foreign country. They want to only ever hear that strange new language until it finally starts making sense. Then after about a month, they begin speaking fluently. Putting their life on hold for 9-15 weeks is key to student success at DBC.

Jeff tells his students to “work crazy hard now so you never have to again.” I think this is really bad advice. It mirrors the mentality that many people bring with them out of CS undergraduate programs: “I’ve put in a ton of money, effort, and time, and now I’m ready to reap my rewards. It’s finally time to get paid and get pampered. Where’s the kegerator?!” And then they’re totally uninspired to learn anything else or improve their skills because learning hard is only for school.

I advise this: “Learn crazy hard now so that you learn how to learn crazy fast. Because you’re going to need to keep learning for the rest of your career.” Case-in-point: Our students consistently get non-Ruby jobs. Many of them land jobs doing Python, Node.js, Java, and even iOS. They’ve become world-class beginners (aka professional-grade learners), which means they can quickly transition to valuable team members regardless of the software platform the company is using.

Jeff goes on to say “At Turing we like to have more instructor-led sessions, lectures, and workshops because we have the classroom experience to pull them off.” If you look at the context, the implication is that DBC doesn’t have the experience to be as “instructor-led” as Turing. In reality, the DBC approach puts a ton of pressure on teachers to really know the craft of software development. Our students spend most of the day coding with each other while under our supervision and mentoring. Our teachers are accountable to guide the students toward the knowledge and wisdom they lack, regardless of whether it’s interpersonal, in the shell, in the database, in Ruby, in JavaScript, or in myriad frameworks, And the teachers don’t do this by simply coding up the answer, they help the student learn to find the answers themselves. This is improvisational teaching and our teachers are very good at it.

(Don’t even get me started on the workshops our teachers lead on empathy, sexism, oppression, the inner critic, effective feedback, and being authentic.)

I totally agree with Jeff on this point: “The important part is that there are constant expectations on student time and learning.”

But then he drops this little bomb: “If the staff is only there to answer questions, that’s not education.” He doesn’t attach this statement at any school in particular, so the implications are left to the reader. Ug.

I believe Turing School does great work. From what I can tell, Jeff is a good educator. I know some of his teaching team well since one was a 2013 DBC grad, and another was a former DBC mentor. They’re both amazing and Turing students are lucky to have them.

I think the world would be a better place if Jeff would write up a critique of DBC and/or the bootcamp model. It’s clear to me he thinks it has a lot of flaws, and I’d value an explicit critique a lot more than the subtle and indirect jabs in blog posts like this one.


Comments (View)
Jun 24 2014

A prospective student asked me

"What advice would you give to someone considering this industry to be (increasingly) successful in it?" My answer:

  • Follow your energy. If you find something interesting, dive deep into it.
  • Get extremely good at the first programming language you get paid to work in.
  • Develop a reputation for learning rather than a reputation of expertise.
  • As you move from team to team and/or job to job, try to be the worst developer on your team.

Comments (View)
Jun 7 2014

Comments (View)
Apr 23 2014

Comments (View)
Apr 3 2014

Dispelling Mythical Holacracy

Journalists and bloggers have sensationalized Holacracy in the past couple months with headlines like “How Zappos is getting rid of managers to retain a flat startup culture”. In the process, they’ve spread a lot of misinformation, and a lot of people now mistakenly believe that Holacracy is way to flatten a company into a non-hierarchical, leaderless, ambiguous collective.

A few quick examples…

"In November at the [Zappos] all hands meeting, [Tony Hsieh] announced that the 1,500-employee company would be restructuring into what is known as a ‘Holacracy’. That means a flat structure, with no job titles and no managers." — Christina Farr, Venture Beat

"The absence of structure is a structure in and of itself. When you allow a power vacuum to emerge someone will fill it, and it’s usually the people who have traditionally held power (rich white men). That’s how you end up with stories like this coming out of GitHub." — Catherine Bracy, Code for America

"Holacracy is about flatness. Think hierarchy and then think the opposite for holacracy." — William Tincup, fistful of talent

Dev Bootcamp adopted Holacracy last October. We’ve been using it as our organization’s operating system for 6 months now. I’d like to share some of what I’ve learned about Holacracy, starting with the aspects of Holacracy that clearly contradict the dominant narrative floating around about it.

Holacracy is inherently and explicitly hierarchical. There is a Board, whose leader (aka Lead Link) appoints the leader of the company. The company leader appoints all leaders of the next layer of leadership. Those leaders can appoint any leaders of sub-divisions (aka Circles) under them. We use software called Glassfrog to work with Holacracy. The default page in Glassfrog provides a nice visual representation of our hierarchy.

Holacracy has job titles (aka Role names). The most significant difference between typical job titles and Holacratic roles is that a job title typically corresponds to a 40 hour/week set of responsibilities, whereas Holacratic roles are typically much more fine-grained. For instance, one of my co-workers energizes 17 different roles, such as Event Staffer, Local Onboarding, and Office Manager. Since roles can be fluid, we did get rid of our former titles and replaced all of them with a simple and consistent “Partner” title. And yet, each of us tends to identify with one primary title. I used to call myself the Director of Chicago, and now I call myself the Lead Link of Chicago. Teachers still call themselves Teachers.

Holacracy’s power structure is explicit and clearly visible to the whole company. As I already showed you, Holacracy has a very explicit power structure. It’s a hierarchy, but Holacracy adds something special to it. For every divisinon head, aka Lead Link of a Circle, there’s a corresponding representative elected by the Circle. This person is the Rep Link, and this role’s purpose is to raise any unresolved tensions up the hierarchy to the parent Circle. This role provides a balancing effect against any domineering Lead Links. Rep Links operate in the parent Circle, just like Lead Links, with the same authority to propose, reject, and process governance.

Holacracy lets you refactor your organization. Software development has a term called refactoring. It means to improve the internal design of your code without changing its behavior. About 3 months into working with Holacracy, we started applying principles of Object-Oriented design to our organization, such as Don’t Repeat Yourself and Single Responsibility Principle. Unleashing our programmer brains on the structure of the company and the roles that we work in every day has resulted in far greater clarity of our roles, responsbilities, and authority (aka Domain).

Holacracy is autocratic. When a role has the authority (aka Domain) to make a decision, the person in the role doesn’t need to consult with anyone. They can simply, autocratically, make that decision. For instance, Lead Links have the domain to assign people to roles and our Chicago Office Manager role has sole authority over decisions about our office space. This is wonderfully freeing and efficient, because as the late, great Grace Hopper used to say, “It’s easier to ask for forgiveness than to ask for permission.” Being autocratic requires a couple things: lots of trust, and tight feedback loops between the autocrat and the people affected by their decisions.

Holacracy feels biological. One of the core features of Holacracy is its tension processing protocols. These happen in periodic (usually weekly) Tactical meetings. I won’t go into the details of how these work, but when facilitated effectively, they can be amazingly effective at processing tensions. It’s helpful for me to think of tensions as food, and our Tactical meetings as our digestive system. The poop is the action items and projects that result from the Tactical meeting. And just to force the metaphor, those action items and projects act as fertilizer, growing us toward the company’s purpose. The work that creates this progress tends to create tension among the team, and the circle of life repeats!

I’ve described my unique experience with Holacracy. I’m not a Holacracy expert, but I’ve learned a lot about it as we’ve been running it at Dev Bootcamp every day over the past 6 months. I imagine Holacracy can look quite different at different companies, but it does have a single constitution, and so I’m confident that the attributes I’ve described above will be shared across all implementations of this innovative way to organize a company.


Comments (View)
Mar 5 2014

Sexism and Oppression: From Oblivion to Action

This post is going to be a stream of my consciousness about my gradually increasing awareness of the oppression that exists around me, specifically sexism. This is my personal blog and I’m using this post to remind my future self about where I stood on this day.

Almost every day of my life has been spent surrounded mostly by caucasian people who aren’t super worried about paying the rent/mortgage or putting food on the table. Being a boy, particularly a shy boy, I’ve spent a lot of my life surrounded by boys and men. There have been exceptions, like when I spent 4 years working as a therapist and earning my master’s degree in marriage and family therapy. Those years were spent mainly around women. Those years ended when, at the age of 26, I decided I wanted to become a software developer.

I grew up in the lily-white suburbs east of Seattle. In 1992, I chose to attend Wheaton College in Wheaton, Illinois, a similarly caucasian suburb of Chicago. I’ve lived in that same suburb for 20 of the past 22 years. It is historically a very conservative, religious community.

I played American football in high school and college. It was a huge part of my life for those 8 years, and has had a lasting impact on my work ethic and goal-orientation. I loved that sport. It has been over 18 years since I played my last game in 1995, and I still miss playing football. Football is (almost) exclusively for men.

When I switched from “family therapist” to “programmer” in 2000, I moved from a field of mostly female practitioners to a field of mostly male practitioners. I noticed this gender-ratio difference, but I didn’t think much of it. I just knew that I loved solving problems with programming languages and I wanted to get better at it. And I got a lot better at it. I took all of the work ethic, obsessiveness, and tenacity that made me a successful (small-time) football player and threw it into becoming the best software developer I could be.

In 1997, a few years before I made this career switch, I married Staci, a feisty, charming, athletic woman who I met when I was 21. Both of us were just 23 years old when we married. My daughter Rose was born in 1999, when we were 24.

My self-induced immersion into the world of software development started a pattern of neglect between me and Staci. I would frequently pull all-nighters and while I still “showed up” as a father and husband, I was often a zombified version of myself, operating at about 25% of my capacity, most easily evidenced by the consistent loss of my short-term memory.

Our family was growing. My sons Ricky and Charlie were born in 2001 and 2004. We needed more space to live in, and we were burdened by a ton of credit card and student debt. I kept working hard to get us out of financial stress. Up until 2001, Staci worked part-time. After our second child was born, Staci stayed home with the kids. Since the day we were married, she has been the primary caregiver for everyone in our home. I’ve tended to be a grown-up kid when it comes to caregiving.

In 2009, I was a partner at a software consultancy named Obtiva. The company was doing well and I was now being compensated at a level that the financial stress in my life was starting to decrease. This is when I finally looked up from the trenches of my obsessions and started becoming more aware of injustice and disparity. Up until that point, I felt like I was sprinting. It’s almost impossible to be aware of anything other than the finish line when you’re sprinting.

Since then, I feel like I’ve been running a marathon. I’m still moving along at a steady pace, but I notice a lot more around me. I’ve noticed lots of things over the past few years.

When I was helping lead Obtiva, we were incredibly male-dominated. Since I had been there since (almost) the beginning, this realization crept up on me and it wasn’t something I had many feelings about. I tried to recruit female apprentices, but also noticed that they struggled more than the male apprentices. It wasn’t until we were acquired by Groupon and I looked around at the Chicago engineering team (circa 2011) that I was blown away that while we had over 100 engineers, I could count the women on one hand. I knew all the people hiring people, and I realized there was something systemic at work, something beyond anyone’s direct control. I knew for a fact that the hiring people weren’t a bunch of dudes consciously trying to keep women out.

I met an interesting guy named Paul Baker around 2009. On the surface, he looked like any other white guy in tech. He was the CEO of his own web design firm, but Paul had a very strong sense of justice. He kept reaching out to me with ideas we could work on together that would help disadvantaged people. Despite my passivity, he was relentless about this, and through the ideas and connections he kept throwing at me, I stopped running so hard and started conversing with people about injustice and what’s broken in our society.

Around the same time, I completely stopped running and stood still for a while. I had reached a very dark place in my personal life and I had to take some time to consider where I was headed. That’s when I discovered one of my life goals: to decentralize education. A few years later I asked myself Why? Why do I want to decentralize education? The answer came immediately: to unleash latent human potential! A year ago, I stopped and thought about the demographics of humanity’s latent human potential, and it doesn’t take a statistician to tell you that when it comes to developing software, there is an incredible amount of latent human potential in women and underserved minorities.

As I launched Dev Bootcamp in Chicago, I was very deliberate in recruiting women onto our team. I had previously failed to create an apprenticeship program that worked for women, so I figured that if we had strong female practitioners involved, that they could help create a great environment for women to learn in. As the applications poured in for our program, they were overwhelmingly male. We soon had 60 students in our space and I was sprinting again. Issues around justice and diversity blurred by as we tried to get our program off the ground and give our students a great experience.

A year later, the program is now cruising along successfully. We’re still improving and adapting, but we’re no longer sprinting. We have more time to stop and think about how to engage the tremendous latent potential that exists in the segments of our population that are currently not actively participating in technology. We’re working closely with Girl Develop It, Levo, Close the Divide, and more recently, YesWeCode.

One new aspect of our program this year is a workshop on oppression and sexism. I’ve run this workshop twice now, and it has had a powerful impact on me. There are a series of exercises that I take our students through that have helped me recognize the enormous privilege that I’ve lived with since the day I was born. The workshop gives me brief glimpses of what it’s like to be oppressed, which has actually left me feeling nauseous by the end of our time together.

The most concrete takeaway from this workshop is this: institutional oppression is rampant in our society, and what keeps that oppression going isn’t some malignant rich white dude pulling levers in an ivory tower somewhere. What keeps institutional oppression going is passivity and obliviousness. Ignoring oppression is an act of supporting oppression. I am increasingly facing oppression. I am still very ignorant. I am stumbling around, clumsily trying to be an active participant in unleashing the latent human potential that surrounds us in every city in this country.


Comments (View)
Feb 28 2014

Comments (View)
Feb 27 2014

Comments (View)
Feb 11 2014

An Old-School Solution for Today’s Skills Gap

apprentice-us:

My blog post about apprenticeship over at Wired’s Innovation Insights:
http://insights.wired.com/profiles/blogs/old-school-solution-skills-gap


Comments (View)
Dec 31 2013

3 Phases of Beginner Software Developers

One of my biggest takeaways from launching Dev Bootcamp in Chicago in 2013 was the realization that Dev Bootcamp exists to efficiently transition people from paying to learn to paid to learn. There are few things more life-changing than that transition. I remember how profoundly it changed my life when I started getting paid to learn to be a programmer when I was 26.

Using what I learned this year about the “transition from paying to paid”, I came up with the following 3 phases that many successful beginner software developers are transitioning through in today’s software development education ecosystem.

Dabbler phase

The learner has enough context to begin to see the things they need to learn. They know the tools necessary to run programs, though they may not truly know how to use them yet. They can speak “tech” to a certain extent and are able to cobble together solutions to technical problems. They’ve completed online tutorials.

This phase is typically free or nearly free.

Examples include: Khan Academy, MOOCs, Codecademy, and Treehouse.

Immersive phase

This is an intense period of learning where the learner gains initial fluency through immersion in the software development ecosystem. When I think about this phase, I imagine my sister dabbling with French for years, but not gaining fluency until she spent a summer in France. She didn’t come back and write epic French literature, but she could speak like a native.

In this phase, learners are typically paying or scholarshipped.

Examples include: Dev Bootcamp, Hackbright Academy, and Launch Academy.

Apprenticeship phase

These learners now have the context and fluency to allow them to enter the world of professional software development. This phase is characterized by working on the job with a real software team delivering software. Apprentices are one-on-one with a more experienced mentor, pair programming for most of their hours together.

In this phase, learners are typically paid.

Examples include: apprentice.io and 8th Light’s apprenticeship program.

Some Thoughts

Not all of the current offerings on the market fit neatly into these phases. For instance, bloc.io costs money, but is not immersive in the same way that Dev Bootcamp is immersive, since bloc.io is a remote mentoring experience while Dev Bootcamp students spend 40+ hours/week face-to-face with instructors and many additional hours face-to-face with each other. Another example is gSchool, which lasts 24 weeks and aims to get beginners through the apprenticeship phase before graduation. Finally, there are those people who can make the transition from “free to paid” without ever paying much of anything along the way. This was my journey, and I co-wrote a book to help others make that same journey.

Your Thoughts

Head over to Quora to weigh in on which programs fit in which phases…

Learning to Program: In which of Dave Hoover’s Dabbler / Immersive / Apprenticeship phases do each of the “learn to code” offerings fit?

Thanks to Dan Croak of Thoughtbot for some helpful edits of the 3 phases.


Comments (View)
Page 1 of 9