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