If you truly believe in Mongrel2, start your own company. Don't wait for the company that's going to truly open source it, it won't be the way you want it if it's not your company.
The problem with starting your own company is that you end up owning a company. That means you have to run a company which means you have less time to hack Mongrel2. I totally understand and respect wanting to get hired by a bigger company like the guy who developed Redis did. Basically being able to completely focus on your code without having to hunt for funding or worrying about where your next paycheck is coming from is a much better proposition for most people.
yeah, stop working on Mongrel2 and get a business off the ground. Then maybe possibly one day when it's making money you can work on Mongrel2 again, your way.
There are still some companies left idling along from a group 10 years ago that sold commercial event-driven webservers / reverse-proxies / caches / load-balancers that were much better than Apache, but are heaps of shit compared to the nginx ecosystem.
Agree. Just starting to learn pre-programming - unlearning bad habits from school where every year we wrote the same bunch of programs, once in BASIC, Pascal, C etc. The only thing I had liked then was Logo. :)
I read the thread. What I wrote was unclear though, sorry. What I meant was, it's stupid that you'd have to do that, because people shouldn't be starting rumor mills in the first place.
Well, it's stupid but I learned the hard way if you don't shut down people who slander in the tech world then the rumor mongers take it to mean you're weak and the slanderers are right. Sucks, but the alternative is to give folks with no integrity a way to tear you down.
In other words, there really is no higher ground in tech unless you're already rich.
Right now I'm the only guy working on it. I like starting my projects that way since I can lay down the playground for other people and avoid the bikeshedding. Once it gets stable I then write up documentation and start letting interested folks at the code to help me.
As a guess I'd say getting it out there in front of enough people that Zed is no longer writing 99% of the code. Getting real community effort on improving it. Although he might just mean in context of the company not keeping any aspect of it proprietary.
They're doing a great job with their clients... and have a very strong group of sysadmins so if they thought Zed was a good fit he'd surely be able to focus on writing code.
No it's not you, I do get asked to be a sysadmin quite often. I have no idea why. It's not something I'm good at. I did for a short time in college to pay tuition a decade ago. I don't enjoy it. I never apply for it. For some bizarre reason, people ask if I want to be a sysadmin out of the blue. Drives me crazy.
It's not that bizarre, you write software mainly used by systems administrators. I used to work with one of the guys who wrote apache, and now work with a guy who wrote most of one of the popular NOSQL engines. And they both work as systems administrators. Not "useradd" systems administrators (although they are technically in that part of the org chart) but more like what Google calls "SREs." Rather than explaining what it is, this guy's google groups post does a better job:
If they just want you to add user accounts, that's weird. But SRE style jobs are where a lot of guys who write famous open source systems software end up.
from the google groups post:
"Yes, sysadmin skills are essential here, however we also require a very strong skillset in development, automation, high-level systems architecture, networking, statistics and general problem-solving."
Google says something like that for every job. From what I know about SREs, the "programming" you do is basically shell scripts to automate sysadmin stuff. Programming, sure, but the most boring type possible.
Yeah, SREs don't do all that much hard-core programming, but they need a skill that's almost harder: the ability to quickly evaluate whether a change is likely to bring the system down or otherwise cause reliability problems. SREs get consulted very often by engineers for questions like "Do we have enough capacity to burn 15% more CPU for the next week?" or "Is this change likely to cause an unacceptable risk of serving bad pages to users?" They also do code & design reviews.
In that respect, the job description is pretty accurate. You do need a strong skillset in development, automation, high-level systems architecture, networking, statistics, and problem-solving to perform well as an SRE. You need to be able to think on your feet and evaluate the suggestions that engineers are throwing at you before somebody does something stupid, as well as the ability to figure out how to avoid having problems recur.
"SREs don't do all that much hard-core programming"
On the contrary, some of the code I've seen written by SREs has been among the most delicate, finely tuned, and "hard core" (by my definition) I've seen.
That's because the odds that a sysadmin is an absolute nut for delicate, finely tuned, hard core code are orders of magnitude larger that the odds for a standard programmer.
It's not required, but that pedantic nature seems to help make a good sysadmin.
Personally, I cannot stand the type of programming which is encapsulating a bunch of "BUSINESS LOGIC" in code. I.e. "apply this much tax unless we are in florida or new york, then apply this much. except on the day after christmas..." or even worse, "restrict these parts of the site to the accounting department, except for gary because he's in fiance, too" etc.
You know how Clark Kent's boss, in the first Superman movie, says "A good reporter doesn't get great stories — a good reporter makes them great."?
Same thing with programming. If you are given enough freedom to do the job right, and you can find a way to motivate yourself, there are no bad programming jobs.
Zed Shaw himself has bragged about a system he wrote which does the kind of business logic you mention -- except by his description it's a meta-programming system that can add rules almost as fast as they can think them up. That sounds like some sort of constraint solver, which is among the fanciest kind of programming around.
I actually find that pretty interesting because it allows me to learn about different types of businesses I otherwise wouldn't be exposed to. I guess the key is to work in a field you're interested in.
"This role is in no way fitting for failed developers, it is for developers/engineers that have outpaced their career path. One that has a deep understanding of how things work: a complete systemic view of general site architecture."
Ah, nice downvotes, I guess a good lesson to not comment on smartass one liners who can later edit out the entire theme and content of their original post.
The original post I commented on: "Maybe because you write software used by sysadmins?"
Right now, find a company doing something bad ass with HTTP and then make Mongrel2 blow their socks off. Then repeat it again and again until I've got something.
Zed, you do not want to go anywhere near an education graduate school. All these opportunities are yours except D.Ed. — Attempt no landings there.
If you think you've been a poor fit at some companies, you ain't seen nothing yet.
Education departments attract some of the very worst students, people pathologically stricken with know-nothingness. The graduate schools then take the more craven among them, the ones that realize that their school-system contracts give them huge automatic raises for getting higher degrees, often paid for too. They often come out as worse teachers after having had the recently recycled fad pedagogies pumped through them, which they then regurgitate in a game of telephone onto their students.
If you want to work on some stellar CS education stuff, try to talk your way into Kay's VPRI. Stay the hell away from Ed schools, they'd make your blood boil.
Say what you like about the tenets of Constructivism, Zed, at least it's an ethos. I'm surprised that you'd have beef with it — you don't even like Papert's Constructionism?
As easily misinterpreted and misapplied as liberation pedagogy can be, at least it gives the non-subject-matter-experts something to apply themselves at, something they could actually help children with even if they're as dumb as a bag of rocks. It's definitely not a good fit for you, but it's far from worthless.
I'm a scientist mostly, so I prefer Direct Instruction from Siegfried Engelmann and Wesley C. Becker and learned quite a bit about how to teach effectively from them. What's interesting is DI is the only method with solid evidence backing its success. Lots of it. The others are mostly just bullshit rhetoric.
Would you like it if you weren't the author, director, and performer of the script?
DI does have it's merits — it does keep bright assholes like us from dominating the classroom as students in a mixed setting. You can also get through the material a lot faster without getting mired in repetitive interactivity, but the script has to be perfect, or you can skip past a crucial facet without noticing, and there's very little opportunity to get back on the rails, especially because from the lecturer's perspective the resulting complaints are difficult to distinguish from the usual whining.
Part of the problem with curriculum design is that trials generally only occur with either uniformly high-achieving or uniformly delinquent students, both of whom can abide nearly any method if it's intentionally delivered.
What's your sales pitch for mongrel2 against things like Unicorn & Passenger. The new features of mongrel2 seem awesome (particularly multiple protocols over the same socket) and given the success of mongrel, I think we all have high hopes for mongrel2. But I'm curious what your thoughts are on what the "killer apps" are for mongrel2 that make it the superior solution to the alternatives.
Operations guy: Mongrel2 is a ops wet dream. Totally automatable and you can use it to easily carve your infrastructure up as needed to scale and deal with all the random crap programmers throw at you.
Programmers: Mongrel2 is future proof and gives you want you need with low friction. Wanna do sockets? Got it. Use any language? Got it. Change up the request flow to work around a bug? Got it. Drop Scala for Rails? Got it.
I'm not that jazzed about the idea of reminiscing about a Smalltalk. How about instead of making esoteric references, you just say what's on your mind?
Alan Kay's talks aren't only about Smalltalk ... they are often about education, and the part computers might play in children's lives. The man is a genius.
Hello Zed. I find myself doing some sysadmin work, not by plan, but it happens that way. Something needs to be working right now, it is easiest to just do it, etc. Also, scaling and deployment issues come up, and best to just deal with stuff. The question is what fraction of time is spent on sysadmin vs. development. BTW, I look forward to checking out mongrel2, and I think using the AGPL + optional commercial licensing is a good plan.
Another comment on AGPL: I both wish that the AGPL became a often-used license and that when required commercial options would be affordable. Obviously developers control the licensing and costs of their creations, but as a for instance, if I could not use AGPL on a customer project: I would be happy to pay about $25 for a VPS license or perhaps $100 for a single server license for good bits of infrastructure software that work better, are more efficient, etc. On the other hand, the neo4j AGPLed project is awesome, I will use it for my own AGPL projects, but the $1000/server cost will probably keep me from being able to use it on customer projects (but maybe not, depending on their budgets).
Sorry for the long rant here, but I would like to see a healthy atmosphere for developers producing quality AGPL projects and the community accepting that they need to pay up reasonable fees for non-AGPL use.
That's a very good comment, and thanks. I mostly went with the AGPL to hedge my bets. It's much easier to reduce a license's restrictions than to increase them later, and I'd like to go with whatever the market wants at the time.
The interesting thing is, other people have had the same sentiment about the AGPL. It seems they actually prefer it plus some small commercial license option. I hadn't really thought people would like the AGPL for servers, but it seems that's what people are liking.
At this point I have no idea which direction it'll go, but I'll make a decision once it's more stable and actually runs stuff.
And that's the problem with Rockstar Programmers. They know they are rockstars, they know that they can get funding for their own product at a moments notice, they know that they can always go on a speaking tour.
You need them, but they don't need you, and they know it. So they walk in and want to do what they want to do, they have no intention of doing the shitty stuff. But work in a company has a lot of shitty stuff to be done.
The problem with Zed is that though he is a good developer, he's also a good writer and probably a good talker. Those last two are important to him, and when people work at companies, they should not be having two big side projects (writing and talking). It distracts from the work.
All the rockstar programmers of the last few years all seemed to have entered CTO roles, have started their own companies, or are important people in very big companies. Very few are still just slugging away at code at small startups.
This story is basically why you should not hire rockstar programmers. Hire normal people who depend on you for their income.
First off, you don't know me, so don't presume to know how I am to work with, or what kind of employee I am. In fact, what you wrote here is borderline slander, as you're basically telling people to not hire me. You and everyone else needs to quit that shit because I don't do it to you, and it does have a major impact on my life.
Second, who the hell are you to say I shouldn't have a life outside of your company? This is not a damn salt mine, or a factory. Programmers are hired based on their visible experience. The projects they do and the things they write are now a major deciding factor on whether they get jobs. To then tell someone that all of that stops because you're paying them a piddly little 100k/year compared to your massive ownership in the company is down right abusive.
Third, in the valley the trend of firing people at the drop of a hat because they aren't a "good fit" cuts both ways. If you show no loyalty to your employees then they owe you nothing. Expecting them to stick around and be loyal, but then fire their peers for having a bad day with no warning is completely unfair.
Basically, I think your entire comment smacks of business douchebag who has no concept of worker's rights, fairness, or even basic capitalism.
Let me put it this way: You're a talented singer, songwriter, guitarist, and producer. The company needs a person who plays bass. They could hire you as a bassist, but that's not where you belong. You're a rockstar. You belong in the front.
What I'm saying is not slander, it's the opposite. YOU are putting yourself in the wrong spot, because you should not be playing bass when you have all these other talents. You should form your own band and create your own vision.
Imagine you are casting a band and you put Carlos Santana as the guitarrist of Britney Spears. Sure, he's an excellent guitar player, but that's now where he belongs. He should not play guitar in Britneys band and dabble in experimental rock music, he should be focusing on his own thing.
That's what I mean - many companies simply need a cog. They need some small piece that will keep the machine turning smoothly. They need a pawn - and though you could stick a queen in there to do the job of the pawn, it's not where it belongs.
And when someone says the queen should not be used as a pawn, the queen should not be arguing that it should be a pawn.
"Hire normal people who depend on you for their income." yes! that's it! Be sure you're the one in control, ensuring your ability to treat them as less than human!
Sorry for the snark, but that last line may be pretty unintentionally revealing. employer/employee relations are a complex relationship which requires a delicate balance of power. Having the employee be entirely dependent on the employer is just as damaging (to both parties!) as having a keystone employee who knows he can't be replaced. I'd replace your last line with "Hire equals who you can treat as equals."
You make it sound like you can only be "important" if you are not programming anymore. I say: go to hell.
I have never seen a manager winning a Nobel Prize - scientist are respected in our world, except in our field. Go figure.
I, for one, like to work for people who are smarter than I am. I believe many good programmers (here refered to as rockstars) feel the same. Therefore, they will not want to work for you and you can stop worrying about them.
Rockstar programmers are not the problem, inexperienced, insecure middle-managers who feel threatened by the fact that they have no idea what the rockstar programmers are talking about half the time are.
Why don't you see your argument through to its most logical conclusion and say "only hire people who depend on you for their worker's visa?"
If I had the money, I would hire Zed because I think he would bring a lot more into play for me than just "slugging at code" for me.
I think he's smart enough to contribute strategically to the project and the direction it takes.
I think he's knowledgable enough to teach me and other people in the group things we don't know.
I think he's good enough to bring in other good people when we need to expand.
And I think he'd just be an awesome, fun guy to be around.
Hiring a cog doesn't get me any of that. If I have to pay Zed two-three times what it costs me to hire a cog to get all those skills, I'd consider it a bargain. And I'm guessing he'd be pretty happy at that rate too.
This phrase has appeared multiple times in response to comments on this story, but I think it misses the point entirely. The parent poster has a point at some level, but he delivers it with no tact.
The point is that you need more than money to hire really talented people. It sounds as if Zed left Dropbox because the problems he was solving there weren't the type of problems that he was passionate about solving. The pinhead, middle-manager response to this is to get pissed off and rant against hiring "rockstar" programmers, but that just shows how little they understand about what motivates really talented people.
I can't speak for Zed, but I know a few talented programmers myself. I've brought them in on projects and seen them hit the door in short order. The #1 reason was never money. Great coders are artists. Their greatest work will always be works of inspiration, not portraits they're paid to paint by narcissistic clients.
The bottom line is, if you want to hire talented people, set out to solve interesting problems, or build interesting projects. And don't be upset if the "rockstar" programmer you hired doesn't want to keep doing what you're doing. Go out and find someone who is interested in solving those problems and pay them what they deserve.
You are talking bollocks, "rockstars" programmers changed the way that you are living now! You should hire people that are good on what they do, that are passionated and not that they go to work just to buy food!
