It's like the movie Ratatouille: Not everyone can be a good coder, but a good coder can come from anywhere.

While they may receive an impossibly large number of candidates, in the end, they will boil it down to roughly 15 students. That means that as long as their application process is sane, they will have found 15 good candidates who are going to be 'coding for the right reasons', whatever that means.

This is different from codecademy, which says that anyone and everyone should learn to code. Instead, they're claiming that you don't need a CS degree to be a professional programmer. That doesn't mean they're also saying you don't need to be dedicated, and analytical. Ultimately, the people who enter these programs are the kinds of people who would have made it on their own, albeit on a much longer timeline. I don't see any problem with jumpstarting it with careful curation and guidance.

"We're having computer problems onsite."

Is that a problem, underpricing the competition if the market bears it? Dev Bootcamp's cost has risen meteorically since they first opened their doors in February of this year. It is now roughly the same cost as a year's tuition at a UC. Apples to oranges, sure, but it gives the number some perspective.

The difference in the pricing model here is that you don't have to pay it back should things go pear-shaped after the course. Obviously, it's in their interest to secure 100% placement, but at least it's not a financial burden on a student if it doesn't work out. This is an important consideration for some people: these bootcamps are sometimes a last resort for people jump starting a new career after long bouts of unemployment in the current economy. As good as any of these schools are, the risk of dedicating months to a program and taking on additional debt with no guarantee of a job is a tough thing to swallow.

In 2005, I worked support for a company with a mobile offering. At the time, app purchases were handled exclusively by the carrier and were completely opaque. A little while prior, we had partnered with a shady marketing company, netting us a bunch of unintentional signups that I had the displeasure of fixing.

Since we didn't handle billing, I had to call AT&T with the customer on the line and talk them both through the process of removing the charges(AT&T was feeding customers a line about not handling billing either, for some reason). After doing it a few times, I realized I could do it without the customer, all I needed was a name and a phone number.

It never came down to impersonating the customer, instead, I would just say I was calling on behalf of a customer. Once, a call got escalated to a higher support tier, with the miscommunication that I was a VP of a partner company, which made the agents more responsive, making the process easier, so I just kept reusing that line.

Eventually, I just asked, "what do I tell the next agent I have to deal with so we can just bypass all the lies?" (regarding their inability to modify billing charges). This was happily given to me, and I could now call AT&T support and say, "I'm calling for user X with number Y. I need you to go into the tool and click on Z and then remove the charge from such and such service." Again, when delivered with authority, the rep would do it, no questions asked.

It's hard to fault them, I probably would have done the same in their position. Still, it's scary knowing how little it takes to get customer service to reveal/modify things without hard verification.

San Francisco: Fulltime

Do you like talking about code as much as you like writing code? Hackbright Academy is looking for instructors for our ten week code school. We teach a blend of practical engineering skills and computer science theory to a small group of aspiring engineers. More information on what we do can be found here: http://www.hackbrightacademy.com.

We're looking for engineers who really know their stuff and are looking for something different. Generalists or specialists of any discipline are welcome; we value communication more than any other specific skill. We write and teach in python and javascript, but that shouldn't matter to you.

Alongside teaching, your responsibilities will include designing curriculum and writing internal tools. We're offering a developer's salary, equity, and an absurd amount of vacation time.

We're not building earth-shattering software here, but we're empowering a new generation of engineers to do so. If that interests you, email me at c@hackbrightacademy.com.

They had a guest list and all my students were on it. This particular student was also on it, along with a note to exclude her specifically from entering the office.

The story was abbreviated: I talked to several people to figure out what was going on before they insisted we were blocking the entrance. By then she had decided it was not worth the trouble and wanted to leave.

I had another 9 students inside, and the talk was worthwhile for them. Furthermore, the problem was not with the organizers (who were generous and accommodating) or the speakers (who were similarly generous), but with the venue. Nothing would have been solved by protesting: I'm not important enough that anyone would have noticed.

It had everything to do with her name: she was turned away by the person with the guest list, but not by the security guy checking for fake IDs. That was the only piece of information they had.

And no, she's got a down-home 'good old American' type name, if I've ever heard one.

It's wrong to offer up the idea that women somehow are biologically averse to tech. You need only look outside the US to verify this: Malaysia's tech sector is almost evenly split between men and women.

It's a cultural thing, which we're loth to admit. We look around and say, "We treat women the same around here", not thinking for a second that maybe that's the problem.

I run the Hackbright Academy, a hacker school for women, and I ask all applicants what compels them to apply to our program. Invariably, part of every story is the idea that they were intimidated out of the field in college or high school by their male peers. Whether or not that's the grand reason for the disparity, it's still something that shouldn't be a reason at all.

Repeat after me: programming is not computer science.

Got it? Good. Now, for actual advice.

Contrary to the prevailing sentiment, there actually is a career path in engineering that starts at the bottom and takes you to the top, all classical-like.

It goes something like this: Customer Support/QA -> QA Engineer -> Support Engineer -> Junior Developer

QA is very easy to get into. If you play your cards right, you can get into QA at a place that encourages automation and whitebox testing, which will expose you to a lot of the fundamental skills.

From there, it's a short hop to QA Engineer, which is exactly the same as what I just said, except they expect you to be more than a warm body clicking on things till they break. You'll be required to write code here.

A support engineer is someone who's midway between dev, QA, and customer support. Here, your customers are developers, so the discourse is a little bit more elevated than a normal customer support role. Support engineers are often asked to produce sample code for customers learning to use the product. Take this opportunity to write it yourself rather than sending canned samples.

(Optional) Dev Evangelist: This is much like the previous role, except you spend all your time at hackathons being cool and showing off how cool your API is.

Do well at these, and it'll be a little more straightforward landing that junior dev job. Congratulations, you're a programmer.