Alex Payne quits Twitter, moves to Portland, cofounds BankSimple, an attempted game-changer if there ever was one. - http://techcrunch.com/2010/05/17/alex-payne-twitter/?utm_sou...
"Wow. @banksimple just leveled up. In the last 24 hours we signed on four of the best engineers I know. Can't wait to announce the team." Alex Payne - 8/11 - https://twitter.com/al3x/status/20905067927
"What comes next for me? Something truly awesome and even more challenging then Engine Yard, but that will allow me to work from home in Portland. I cannot yet reveal where I am going to work next but I can promise it will be another game changing project and I am chomping at the bit to get started." Ezra, 8/13
I'm interested in education, hiring, and matters of accreditation. Those last few paragraphs really got my attention. I'm glad I read all the way to the end.
As of July 2010, unemployment rate for college grad was 5.0% while for HS grad was 9.9%.
And even though I only have my GED I am still very familiar with how computers work, memory management, building virtual machines, etc. I have a small scheme here that compiles to rubinius bytecode and then gets JIT'd by LLVM into machine code that I will release one of these days and I have read tons of papers and feel like I know as much or more then your average CS degree grad.
Everything you need to know is on the internet nowadays. All you have to do is spend the time to reach out and grab it and you can learn anything you want to learn and eventually get any job you want to get if you only apply yourself hard enough.
I did not mean to disparage college degrees, merely to make a comment that you can learn as much or more then you would learn at your average CS degree school by just applying yourself and reading online, then practice, practice, practice.
EDIT: Actually, thinking about it further, I haven't come across many bad developers without a degree. This is surely selection bias: bad devs with a degree can hide in the bowels of BigCo with HR departments who don't actually know how to hire good people, but absolutely require a degree. The bad devs without a degree can't get these cushy, hard to be fired from positions, and therefore don't last very long and probably find another line of work.
HN users value education a great deal, many just refuse to let school interfere with it, especially when school == java school.
I'd guess we're beating college grads.
Beside, 4 hours of tv watching a day is practically a part time job. Might as well spend that free time on something more relaxing and brain stimulating.
This is a man with his head on his shoulders. My only comment is I wish that more people had this level of dedication to their families.
Yes, sometimes it's necessary. Yes, sometimes team spirit takes over and spending fourteen hours a day at work feels like fun. Yes, sometimes there's a creative burst and one could easily pull of a fourteen hour session. But I cannot believe someone could consistently put in an honest day's work and pull off those hours for more than a few months.
I felt pretty productive since I could intermix the kind of work I was doing. 11AM-6PM would be meetings, interviews/recruiting, etc. Dinner break w/ hulu from 6-7. Then program myself for basically a full day (~7PM-2AM).
Yeah for sure, we all have to work and feed our families but we can do so with 40 hours a week and not 100.
Kudos!
[edit] looks like I cannot change the url myself. if a moderator can change irt I'd appreciate it.
This is a really hard problem IMHO. Obviously it depends on your business model, but I've found it at times an unsolvable problem...
I think I'd prefer to pay less for hosting, and have some experts on retainer for when they're really needed.
They're cool people in any case, and I wish them good luck.
B. You will ultimately either pay more, or get less value, if you decouple your expert support from the specific hardware platform that your expert support understands best and lives with every day.
C. If you only pay your experts when there is an emergency, there is no incentive for anyone to help you avoid having emergencies. Nor will there be anyone but you to look out for emergencies before they happen, or prevent emergencies by doing routine work like testing and applying patches. And you will have to get really good at finding freelance experts and convincing them to drop everything, reorient to your system, and fix your problem in a matter of minutes as your server is in flames; you may have to pay premium prices for that. It might be cheaper to just pay the insurance bill.
Disclaimer: I work at Acquia on Acquia Hosting, a product which is like an EngineYard for Drupal.
I have more latitude when I put the pieces together: hosting here, retainer there.
> C. If you only pay your experts when there is an emergency, there is no incentive for anyone to help you avoid having emergencies
That's a fair point, but on the other hand, it also seems that if you're paying an 'expert surcharge' on your hosting, your incentive is to get as much out of that as possible, whereas the experts, getting a flat fee, can't act as de-facto consultants without eating up all their margins that way. There's something of a conflict there. How do you guys define exactly what your role is?
Also, presumably someone is developing the code to be hosted there. The better they are, the more likely it is that they'll be able to do a good deployment and monitor it on an ongoing basis.
I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?
EngineYard brings a premium service, but none of my customers have been interested to pay the premium. They all go on SliceHost, Joyent, or home-hosted machines.
Sidepoint: around me, most non-rubyists developers don't deploy their apps themselves, whereas all the people I know who work with Rails or Sinatra do deploy themselves. I believe this may be thanks to Capistrano et al, maybe.
Big, heavy traffic apps require special attention, but then that's the same for all big/heavy apps.
That WAS my experience with Rails, but I'm pretty sure that the problem wasn't due to Rails, but rather the way that our system ended up being architected.
An intelligent setup would have been to have each child site a separate, service-backed (i.e. no ActiveRecord -- that scaled abysmally, and I don't know whether or not it's improved enough for more than prototypes since then, so that part might be outdated now) Rails application. The company common resources like custom Javascript, authentication (ours used a pretty hefty RSA server setup) and style sheets should be hosted in their own Rails app.
Do it that way, and ensure that your developers aren't idiots like the blithering idiot that thought he was an architect (without nepotism he'd have been fired instead of promoted to architect, as his only previous industry experience was as a gopher at accidenture), and you can make a Rails app that's not only robust, but also scales well.
It also avoids the tight coupling problem that the gen-y's and sweatshoppers all seem to love so much.
You decide to add a new feature? Spin up a new Rails app. You need to change the styling? No problem, update them in one place.
Not that any of that is specific to Rails, but even back in 2005, that approach worked well... and the company I was working for might have been successful if we'd stayed that course.
There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard.
There was a time when administering a Rails app was a much more hairy proposition than it is today, though.
Merb was a lightweight, modular framework made up of a small merb-core and then merb-more, a collection of 20ish gems that provided various bits of functionality, most of which were problems that Rails solved in its core. Stuff like merb-helpers. If you wanted fancy helper methods, you required the merb-helpers gem. If you didn't care, you would not require that and have a slightly more efficient app. Similarly, it didn't have an ORM baked in--you'd use some gem like DataMapper (with an additional merb_datamapper gem that told Merb how to integrate with DataMapper).
Padrino seems to have the same setup of a minimal core with lots of modular plugins, but its equivalent to merb-core is sinatra. Which is awesome because sinatra is great and this way they don't have to reinvent the wheel.
"Oh the stories I could tell if only I could. But I feel that telling this positive story of the history of EY is the classy way to go out and I wish Engine Yard all the best in the world"
Any unrest?
True story: in the early days of Merb, before it had really gotten a lot of attention, I once hit a show stopper - hopped on IRC, told him about my problem, he found the bug, fixed the bug, pushed a new release in something like 15 minutes IIRC, and stayed cool about it the entire time.
Best of luck to him!
I wouldn't assume that there's some hidden reason for him leaving. First of all, leaving right before his stock is about to vest just means that he's leaving a little bit of stock on the table. As he said, the vast majority of his stock has already vested (as one would expect after 4 years), and he gets to keep that. It's the 5%, or whatever, of his stock that hasn't vested that he's losing.
I read this as "I've been working startup hours for way too long, and I'm tired of it, especially now that I have a kid I want to spend time with".
