chriszf

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 [email protected].

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.

Actually, nuclear power plants are designed to withstand failure. Typically there are multiple backup plans to safeguard against failure of any one system. One comment I sometimes hear is, "They had to pump seawater in to cool things down? That's crazy! They should have had a backup plan." It turns out that nuclear plants are intentionally built near bodies of water because external cooling is a backup, should the primary cooling systems fail.

Nothing, however, is designed to withstand systematic catastrophic failure of all of your backup plans.

Twilio's twice-monthly hackathons were explained to me thusly: how much money would you pay annually for someone to scrounge up 300 good use cases and 100 really excellent use cases for your API product? It turns out $24k is cheap for this kind of data.

It's not about buying developers off and chaining them to your platform (in their case, anyway), it's more about evaluating the boundaries of their product in service of making it better.

Two things.

You can build a product but until you manage to sell your product to someone, it's not a company.

'Salesmen' are not the only way to get people to buy your product.

I think it's important to start making a distinction between sales and marketing. At one place I worked, the marketing team resented being lumped in with sales and were actually in direct competition with them: organic signups nibbled away at a salesperson's commission.

People are becoming more comfortable with the idea of purchasing a product without ever having spoken to a human being in the entire sales cycle, and that's a marketing job. For some companies, it obviates the need for 'sales'.

Having made that distinction, I would not go to war, so to speak, without a great marketer by my side. A salesperson, on the other hand...

The problem with traditional sales is the pay structure. For mediocre salesmen, working on a commission means "any warm body will do as long as they don't churn before I get paid". This translates into having problematic customers who will thrash and cause you grief before inevitably cancelling your service or returning your product.

Mostly I agree, except for his introduction of %r very early on in python the hard way. What %r does in the context of the lesson is clear, but many students ask why and what it's for, and the complete answer is much more difficult.

Frequently, I just settle for "it adds quotes around strings" because the truth is a bit much to handle at that point.

When you're teaching something completely new to someone, at first you won't even have a common vocabulary. This is true no matter what you're teaching, and you have to dedicate some time to establishing the language (English, not computer).

One thing that makes coding a little harder is that many of the analogies we make for non-coders aren't especially clean: A hash is like an set of cubby holes, each can be named and filled, and the set can be infinitely expanded. Packet routing is like trying to find your way from New York to California, only stopping at major cities to ask for a general direction. Memory is like a big sheet of paper, and x = 5 is like writing 5 somewhere on the paper, and x somewhere else, and then drawing an arrow between them.

I'm not saying these are the best analogies (or even any good), but I have yet to hear ones that aren't riddled with holes. The average non-coder doesn't have the context to back-fill these holes. As an instructor, you need to realize this and take the time to lay more of a foundation than you think.

Freeswitch and Asterisk are both written largely in C, although it's unclear if that's representative of industry practice.

It seems to me that you're talking about modularization for managing complexity, which FP does just fine. OOP doesn't have a monopoly on that. It takes discipline, but you can write well-structured code in any paradigm.

To say that functional is the same as procedural programming is a complete misunderstanding of both. To say OO tried to solve the pitfalls of the other two paradigms is a misunderstanding of OO on the entire spectrum, from Alan Kay's original vision to modern implementations.

Even forgiving those confusions for a moment, if it takes discipline to prevent your OO code from degrading to procedural code, how is it any better from just enforcing discipline on procedural code? If OO is quantifiably better, the default state of the code should be obviously better than with other techniques.

I did some work programming a sequence for a Siemens magnet, and while I can't comment on the quality of the code driving the hardware, the OOP API they exposed for sequence creation was as bad as it gets. There was no sense of abstraction at all; it was very much like someone took an old C-style library then systematically hid all the functions in different classes for fun. Now, I could imagine that someone somewhere declared the magnets would be cutting-edge C++, and that's exactly what happened.

The point is that OOP is not necessarily the obviously correct way to manage the complexity of an MRI sequence. Any other style could have easily been substituted and not done worse.

If you read the Google paper, you'll notice that they actually refer to this and other work by Liu et al. The overall technique is the same, estimate the original camera path, calculate an optimal camera path, retarget the input frames to a crop window that fits the optimal path.

The primary difference seems to be estimation and calculation technique. Liu's work does a structure-from-motion reconstruction, ie: rebuild a 3d model of the original scene. Google's work uses something called pyramidal Lucas-Kanade to do 'feature tracking' instead. This is sort of localized reconstruction, it seems to only care about the viewport differences from frame to frame. They then feed it through some linear programming voodoo to get the best path.

I don't understand either well enough to say why one is better than the other, although I'd guess it's because Lucas-Kanade is temporally and physically localized, it's easier to farm out to a parallel cluster than an SfM technique.

There also seems to be a difference on the rear end of the technique, having feature detection allows them to add 'saliency' constraints, ie: retarget based on the inclusion of certain features, like a person's face. Again, the math is beyond my understanding, but it seems like this isn't part of Liu's work.

You can't be perfect but you can at least try to reduce complexity. Saying "just paint over it with pretty colors when you're done" invites unchecked complication. That attitude is what drove all the monkey/ninja patching that we saw with some early Ruby modules. They were beautiful, yes, but it made some code impossible to reason about.

Fair enough, but it's interesting to note that a person with little-to-no CS background can be made to resemble, in all respects, a junior-to-mid level engineer in such a short time. It suggests that the industry notion that a CS degree is needed to be a good engineer needs to be challenged. Why it exists at all baffles me, when some of the best software engineers around are mostly home-grown: John Carmack, Shawn Fanning, Ken Silverman, Bram Cohen, etc.

I disagree.

A computer science degree means you've spent 4 years learning computer science, it doesn't mean you know anything about software development. In fact, at a university with a good CS program, it almost certainly guarantees you know nothing about software development: UC Berkeley's CS program has a single optional elective on the subject of software engineering.

Now, there is a high correlation between computer science aptitude and software engineering aptitude, but I wonder if it's just because we've conflated the two because the field is so young. I believe that one can be taught without the other, and that's what we're seeing with these academies.

Consider: on one side, you have someone who spent 720 hours over the course of four years learning Delaunay triangulation and LALR recursive descent parsing, but has never written or architected a greenfield application from scratch.

On the other, you have someone who spent 300 hours over eight weeks building applications, being exposed to good industry practices, learning how to deploy systems, how to use source control, how to use an IDE. Maybe afterwards, they could spend two weeks covering fundamental theory.

Let's be honest, when I go out to interview I do the same thing anyway.

As an employer, the latter would be more immediately useful to me. So you're right, the comparison is ridiculous, and an intense course is not a substitute for a multi-year degree. But stop and ask yourself: is a CS degree the right criteria for admission into the industry in the first place?

I don't think having a school for women necessarily gives an unfair advantage. I'm not even sure it's an 'advantage' at all in a male-dominated discipline, especially given the degree to which engineering is male-dominated.

You're right that girls don't think tech is cool. I've heard this anecdotally from high school teachers and friends running Girls in Tech programs. I'm not sure I know how to tackle that specifically.

One problem might be the phenomenon that occurs when you walk into a room full of people who look nothing like you. As a minority (I know I look Chinese, but I'm a Samoan-born Filipino), I feel this a little bit all the time. But when I walked into a local Women Who Code event to meet someone, it was downright alarming. After experiencing that, I can't blame women for not wanting to participate in tech at all.

Regarding your last statement, I want to point out that I've never worked with a woman who was a bad engineer, and seemingly, neither has anyone else. Conspicuously absent are the unremarkable, or even poorly performing female engineers, while their male counterparts are everywhere. One expects a more normal distribution, and I think this indicates some systemic problem, but it's not one I know how to solve without more data. Right now, I think the best we can do is address the symptom and add more women into the tech pool directly.

I spent about an hour looking at noir (the clojure web framework) and here are some terribly shallow and scattered thoughts on the matter.

I learned scheme some 12 years ago and have always liked it, but somehow have never felt comfortable with either clisp, elisp, or even arc (sorry PG). Clojure, on the other hand, makes me pretty happy the way scheme did. It is a joy to use, except for the jre startup time.

To put things into context, the reason I learned scheme was to be able to learn computer science without any particular language getting in the way (yes, it was a SICP course). Scheme was as close to 'no language' as it gets. It is infinitely flexible in its simplicity. Imagine, in a language where the only native data structure is a linked list, adding object-orientation without metaprogramming trickery. It's madness! Well, it's unthinkable if you look at it from an algol-derived language background at least.

So where was I. Right, noir was pretty good. For the rubyists out there, it's very much like sinatra plus haml. As a side note, when explaining lisp, I like to use html as an example of how XML is essentially a bad lisp. Seeing lisp actually being used to generate html gives me the heeby-jeebies, though, and I don't know why. I'm sure it's fine though.

Enough of the niceties, here's where crankypants grandpa programmer comes out. You preface your question with the notion that you want to learn lisp to become better at your craft, which is great. However, when it finally comes out, your question reads, "is it worth switching away from the commercial viability of my current environment?" The answer is, of course, no, as Lisp is so rarely used in the wild that it doesn't make commercial sense. My problem is that you are conflating the value of a language with the value of learning that language.

At this point, learning lisp will likely make you a better developer. But to be honest, learning any other language, or even just another framework will make you a better developer. Think of it like vision. If you look at software development through the lens of RoR, you have only one perspective. Learning python gives you a slightly different second perspective, and thus you perceive depth. The farther away the viewpoint, the better your understanding of its depth. The viewpoint from lisp just happens to be very far away.

The key word here is learning. Even if you don't use it because of limited commercial adoption, the act of learning lisp improves your skill and understanding of your craft. If you have pride in your work, then that is always worth it.