Joel is super strong advocate of : 1) private offices for each programmer, 2) free, nicely catered lunch every day (everyone eats together and bonds), 3) usual internet stuff - comfortable office, dogs, flexible schedules etc.
On one hand, a little voice inside of me cries, "Yes! This is what it takes to produce great software: a programmer-appreciative environment."
On the other hand, another little voice claims, "This stuff is all well and good, but nothing more. It's cosmetic, not functional, like putting perfume on a pig."
I have been in many situations with Class A office space, private offices, catered team-building breakfasts and lunches, etc., etc., etc. and was ready to jump out the window. Why? Because the work sucked and all the window dressing in the world wasn't going to change that.
Then I think back to some of my most favorite projects and remember the great work that we did. Sometimes in squalor-like conditions, sharing cubicles or tables, sitting in the server room with too much air conditioning or in the warehouse without enough, eating vending machine garbage and drinking old coffee because that was all there was.
Bottom line? The work itself is 100 times more important than the working conditions. Sure, everything being equal, I'd rather have nicer digs. But everything not being equal, I'll choose the better project every time, no matter what the environment is like.
I suspect Joel gives the programming environment more credit than it deserves. His people are probably happy, and the office helps. But the real reason is the work itself, and they'd be almost as happy no matter what the office was like.
"But everything not being equal, I'll choose the better project every time, no matter what the environment is like."
Really? Don't get me wrong, I largely agree with the spirit of your post, but... there are some real shitholes out there. At one job my chair was so bad that I could barely move at the end of the day. I had to exercise more often than usual to ease the back pain. The office was often dirty because the owner was too cheap and would only send a cleaner when he really had to. I don't care if you're working on an OS kernel or movie special effects, doing something you love should not come at the expense of your health or personal hygiene. Now I don't particularly care for free lunches or private offices (I prefer shared offices myself, with 3 or 4 developers per office). But the reason Joel's message resonates strongly with so many people is precisely because most developers work in conditions few professionals would put up with. Even in software companies where software is (or should be) a profit center, the accountants, office administrators, etc. often work under much better conditions than the developers.
Actually, it's not only about making programmers happier. That's a large part of it, but private offices also make programmers more productive, because they have less interruptions.
The way Joel figures it, programmers are your most important asset, not to mention a huge expense (salary-wise). Paying extra to make them more effective is usually a winning strategy.
I almost feel bad for posting this link, but it does provide some evidence that even at Fog Creek - the Holy Grail of great engineering environments - employees become burned out due to the fact that, hey, a lot of software problems need to be solved in a business are just as boring as the ones that the rest of us cube farmers have to solve.
You worked in great conditions but on a bad project, and you hated it.
You worked in poor conditions, but on a great project, and you loved it.
I think you jump to conclusions saying that therefore the work is more important than the conditions. Joel isn't saying that conditions alone suffice, but that it's an input of worth.
Please, for the sake of HN, work at a place with great conditions and a great project and report back on whether it was better than great.
Screening process: Resume screen, phone screen, web based Etherpad code test, then fly/bus in and day of interviews and whiteboard code test.
As a programmer currently looking for work, I find this screening process to be draconian and insulting.
I cannot vouch for it's efficacy as I've never used it when hiring people.
However, the problem I have with it is the rigidity with which I've seen it enforced. I've a number of open-source projects that I've started and contribute to and a plethora of code examples I can send upon request. I like to think of it as a portfolio of code. I've sent links to these projects and made sure the recruiter knew that I could provide further code samples as required. Yet each time I walk into the interview, the interviewer hasn't read a single line of my code and hands me a dry erase marker. I then get the sense that I'm just another number and they could hardly care about who I am or what I do.
I don't know what writing code on a whiteboard is supposed to show the interviewer. The person they're interviewing is not in the normal state of mind they are in when they're doing they're job. What good is a pressure test other than to keep very good, capable people out of your organization?
Certainly a production artist wouldn't walk into an interview with a portfolio and be asked to draw a puppy. The gall of the interviewer would force the artist to walk out unless they're especially desperate. The same is true for programmers, IMO. If a candidate sends you code to read, take the time to read it before you interview them. Otherwise why should they even bother sacrificing their time on this Earth to your benefit if you won't even consider their work and effort?
As a programmer currently looking for work, I find this screening process to be draconian and insulting.
As a hiring manager, I look for someone who gets things done. No surprise that this takes many things: knowledge, skill, smarts, creativity, experience, team work, and maybe most important: attitude. You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long.
I cannot vouch for it's efficacy as I've never used it when hiring people.
I can. Nothing works better. Period. If I have 30 to 60 minutes to find out how well you'll perform, I'll have you code and teach me what you've done. I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road.
I'm not trying to insult you, just give an honest answer to your (very good) question. This comes up so often, I've responded to it before. A little more light shed here:
I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its probably not efficient, and can probably go wrong.
When a developer is screened with tests like that, you are not evaluating them on their product, but rather on some set of skills that might overlap.
I cant believe I'm using a sports analogy, since I hate team sports, but think of it this way. What if a football or basketball recruiter went to colleges, and looked at only how fast somebody ran, and how high they jumped, but never looked and how they played the game! Don't laugh, that's exactly what you are doing. You may have some success because you are screening out some dopes, but that's all you are doing. If I was the MVP on a team and some jerk took me aside and asked how high I could jump I'd be insulted.
As the OP suggested, looking at the candidates past code is more like looking at how they play the game.
If you suspect plagiarism, then have them explain it, beat them over the head with every design decision they made, have them rewrite something with your suggestions, it will become obvious if they wrote it or not, and you'll have a better idea if they know how to actually code, where it counts, at the construction level.
Unless you've got a body of work that inspires a manager to recruit you with a stack of spicy magazines and a basket full of candies and fruit, there's a specific dance when interviewing.
It's like an audition. At issue isn't whether you can do a task. Instead, whoever is hiring wonders can you do a task with me.
So there's some jumping through hoops. The hope is that in the process of evaluating and sailing through the hoops, the interview group can establish how you solve problems, how you approach interaction with others, how you take direction, how constructively you can disagree, and maybe, as a smidgeon of the evaluation, how well you actually know your thing.
In the end there's plenty you can teach about how to do the job to best suit the task and the company that's hiring.
No one can teach you how to be a person, so the fit has to work.
It's miserable working with jackasses who are technically competent but personally toxic.
Sounds like a college-hire interview. With years of experience and sound references, having an interviewer insist on this "baby step" IS demeaning. And it breeds a bad attitude, sure.
How about Reading the code the candidate provided? Asking questions about that? Invest some effort in a mature candidate, instead of treating them like a fresh-faced kid.
Imagine the difference between interviewing a business-school graduate (What is accounts receivable? How do you track inventory? ) vs interviewing for an executive position.
You sound like someone I would not like working for. And that, maybe, is just as valuable as anything else. You've got a process that identifies the type of person you've had good luck with in the past. Your process also identifies you as the sort of person I've had bad luck with in the past. It works both ways. You're missing some excellent developers who maybe are not articulate at the whiteboard but do fine at the keyboard, even under pressure.
If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long.
How many times do you have your customers in the office, throwing out arbitrary programming challenges for your developers to solve on the spot at the whiteboard?
It's fine if your methodology works for you, but you might consider that it's not the only approach that could work.
Thank you for the honest reply. I was hoping someone who uses these techniques in their hiring process would explain what they find so useful about it.
I've hired many programmers before myself and I've never used such a rigorous process. I'm just curious why it has become so popular, There's got to be a reason, right?
You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long.
Actually my bad attitude has left me with a list of references from customers and managers who'd be happy to tell you that they've been satisfied with my work. Some of them are my best evangelists.
What I find insulting is ignorance. In my original comment I mention that it's the rigidity with which the process is enforced which is insulting. I think it's ignorant of the interviewer to not bother reading a candidates' source code when they offer it (the same for their website, etc). You validate that by saying that it doesn't matter what code a candidate has written prior to the interview. That is exactly the ignorance I have a problem with.
I suspect that if the goal of this process is to understand what a person's attitude, knowledge, skills and such are really like then reading their source code and blog posts would be the first step in getting to know them.
I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road.
I find that reading someone's commit history in a project can be very illuminating. The logs alone can give you a sense of their commitment to a project, what kind of work they prefer, and even a cursory glance at their skill level (are they fixing small bugs, introducing bugs, reverting a lot?). If you have time to sit down and read a few patches you can certainly see how well they follow coding conventions, whether they understand control and data structures, and perhaps even algorithms if that's what you're looking for. You can learn a lot from the code a person writes.
What I was having a hard time understanding is what kind of things can white-board (or pencil and paper) problems tell you. After reading your other comments, I think I have an idea. You want to know if they can talk freely about time vs space constraints, optimization, basic control structures, and data structures. You want to know if they know the fundamentals. I can appreciate that.
What I still don't understand about your process is how the candidates' previous code contributions and experiences do not matter. Can you not get the answers you seek from reading their code? If it wasn't just Joe Programmer but Larry Wall or Peter Norvig, would that change your opinion?
I just don't think it's a universally applicable tool, but I find many companies that seem to think it is the only way to screen candidates. I think that some flexibility is necessary because you're dealing with human beings. The hiring process isn't an exact science IMO. Just like Agile isn't the ONE TRUE WAY to develop software I don't think you'll find a single process that will find you the best employees.
>>I've never used such a rigorous process. I'm just curious why it has become so popular, There's got to be a reason, right?
I think the feature is the speed and standardization of the screening process -- the code writing on line probably clears out a lot of incompetents. (Trivial parallels with CPU instruction queues etc inserted here.)
>>how the candidates' previous code contributions and experiences do not matter.
They'll look at open source contributions in a later phase, or they are idiots.
>>my bad attitude
There is nothing wrong with your attitude -- that was way out of line. Don't work for people who doesn't like if you ask questions. (And don't judge the GP as an idiot either, he made some good points but might have had to explain some simple things once too often. :-)
Disclaimer: I'm not an expert or even a good amateur at the hiring process.
Any test can fail in two fundamental ways: false positives and false negatives. The primary purpose of a screening test is to filter out unqualified candidates (that is, to not certify as qualified someone who is not). The process Joel describes is very effective at this.
Your complaint, essentially, is that it will incorrectly label as unqualified some qualified candidates (or that they will elect not to submit to the process, essentially putting themselves in the no-hire pile). I think Joel would tell you that this kind of error is much less costly to an organization than the other kind.
Suppose he relaxed the constraints enough to get you to pass (we'll posit that you're in the false negative group). This would necessarily imply accepting some lower-qualified candidates who would have been filtered out before. Is the company better off now? Do you think you are that much better than the people they were getting under the old system to risk also hiring lower quality candidates?
I hear you, but if I'm looking at your code that I didn't see you write in front of me, how do I know that code really came from you? You could have copied and pasted most of it from somewhere else and only made slight changes.
Well if it's an open source project, you could just google some of the code snippets and find out.
Plagriarism isn't hard to detect unless the code is proprietary.
Then I suppose you either have to be paranoid and suspect everyone or accept that most people you talk to are pretty much like yourself and not lying cheaters.
Certainly a production artist wouldn't walk into an interview with a portfolio and be asked to draw a puppy.
No, but I could imagine someone being asked how they might go about starting a new assignment or piece of work (art might be a bad example to use here since the process is likely not as important as the end result).
These coding exercises give the interviewer a chance to gauge how the candidate goes about solving problems, if he/she can think on his/her feet, their problem-solving strategies, etc.
Code that you have already written is great but it doesn't tell the interviewers much about the process that led to it.
The most recent graphic designer to apply at my workplace was asked to demo his Photoshop skills on the fly ("Can you make me look thinner?"). He did great and we hired him.
Also, I've worked with programmers who definitely should have been asked to write "Hello World" at some point in the hiring process. If they'd felt insulted and walked out, so much the better.
Would you rather be judged on your ability to write some sample code in the interview.
Or on the more traditional, quality of suit, firmness of handshake, where you went to school and ability to answer "what are your greatest weaknesses" type questions?
> I notice that if you have the door to your office
> closed, you get more work done today and tomorrow,
> and you are more productive than most. But 10 years
> later somehow you don't know quite know what problems
> are worth working on; all the hard work you do is
> sort of tangential in importance.
>
> He who works with the door open gets all kinds of
> interruptions, but he also occasionally gets clues
> as to what the world is and what might be important.
> ... there is a pretty good correlation between those
> who work with the doors open and those who ultimately
> do important things, although people who work with
> doors closed often work harder. Somehow they seem to
> work on slightly the wrong thing - not much, but
> enough that they miss fame.
Adapting this to programming, intra-team communication is already hard enough to establish and get flowing. Don't put stuff in the way. Yes, programmers do need quiet environments, but the gains from good and easy communication will out-weigh the losses. If you really need silence for a bit of hard-thinking work, take your laptop and go somewhere else for a bit.
> I notice that if you have the door to your office
> closed, you get more work done today and tomorrow,
> and you are more productive than most. But 10 years
> later somehow you don't know quite know what problems
> are worth working on; all the hard work you do is
> sort of tangential in importance.
I think Joel's office will avoid this problem because they have scheduled interaction time each day. The daily all-company lunches prevent the employees from becoming isolated and out of touch. I don't think he intended for the free lunches to be a balance for the private offices, but that seems to be the function they serve.
I found it interesting that he claims Wall Street offers dull problems compared to most startups. I've never worked there myself but I know people who do (and in London), and they tend to work on awesome and seriously hard core projects. Stuff right on the cutting edge of math, CS and technology and often far beyond what most start-ups deal with.
Sure I'm not doubting that there are plenty of dull jobs on Wall Street as well, but I'm surprised he writes off the entire sector.
I work in finance (for an investment management firm that's a household name in the CNBC world) and can confirm that the synopsis re: working for finance, "Lots of money but crappy environment, dull projects etc." is correct.
Here's a summary of the work environment:
- no office (hah!) or cubicle, just a space on a long desk, hardly conducive for concentrating on programming
- dress code is shirt and tie, but on Fridays you can drop the tie, and every quarter or so you can wear "jeans for charity" if you pay $10 (yes, I'm serious)
- C++ is the standard language, but it's C++ as written by physics PhD quants who have obviously never taken any classes in software engineering, and have no interest in doing so
- hours are long, 10 - 12 hours a day
- as much as possible technology is done by contractors or is outsourced
Generally speaking the attitude is nobody got fired for buying Oracle, so "awesome and seriously hard core projects" are few and far between if non-existent.
On the upside, the pay is good, so if you're disciplined and don't get stuck in the trap of living the Wall St. lifestyle you can save a lot and at some point take the money and run far, far away from the financial industry.
FWIW, my experience has been different (I work at a proprietary HFT firm in Chicago).
-Open office space (no one short of C-level gets an office). We all work together in a large open space to collaborate better. We have reasonable sized desks though, with 4-8 monitors each
-No dress code (I'm wearing jeans and t-shirt, and shorts/sandals/t-shirt isn't uncommon).
-A lot of C++ and Java. But more Python, Haskell, and Erlang every day. If you can prove your solution is better (mostly faster), we'll use it. It is true that some of the people writing code are physicists/mathematicians, and don't get some SE best-practices. But they're pretty damn smart and will learn if you teach them.
-Best hours I've ever worked (<50 hrs/week). Home by 5PM most days.
-You have access to any tech you need. If there's an expensive piece of hardware or library that will help, it's no problem.
After watching the original Wall Street again last night, and looking forward to the new one I'm thinking these days its guys like you who are at the cutting edge, not the actual people on the floor. Your job sounds great!
What are the projects that you are working on? HFT strategies? Statistical Arb trading strategies? Those kinds of projects seem extremely math and CS hardcore to me.
I worked on Wall St (for a large Commodity-trading company).
Only a small percentage of the IT people worked on those. Mostly we built and maintained systems to track and report on trades, keep track of credit, figure out profit/loss on books, make sure traders didn't bet the company on risky trades, scrape numbers off of websites and put them in a db. We also pulled a lot of numbers into spreadsheets so analysts could make charts to email out to the traders.
It was much as the GP says... long desks, lots of noise and distractions, poor technology base (they upgraded to WinXP with IE6 in 2009). On the plus side, the pay was good (high 5, low 6 figures), multiple monitors, lots of snacks and drinks in the kitchen, catered lunch, good healthcare...
Roughly 30 - 40% more than you could expect to get working as a programmer outside of finance. But considering that the hours are longer, it's not much more on an hourly basis on a straight salary basis. However, if you're an employee, you can also get substantial annual bonuses.
Bank in the 90s I worked for a small derivative shop in NYC. The lowest bonus we ever got was 100% of annual salary. This was not a boring project either - we had a network of Suns and all code was written in Eiffel and C.
That's what I thought so too. Remember that Russian programmer who worked for Goldman Sach (or was it Morgan Stanley) that got caught for stealing his own code when he moved to a firm in Chicago? He's coding in C++, Erlang and a bunch of other things doing hardcore Math and CS.
That surprised me as well. I really respect Joel for
a) treating his programmers well
b) not taking external funding for something that doesn't actually require (I suspect points a and b are connected too).
but writing a bug tracking system in ASP.NET seems a lot less
intellectually challenging compare to what's involved in a high frequency trading system (even if you don't get to use Erlang, Haskell, OCaml and C++ -- and you frequently do). Of course that's also nothing compared to many Silicon Valley companies (you get to work on hard problems and you're in a place where core competency is software). I'd imagine, this is related to his point about Stanford (or any other Bay Area school for that matter, even San Jose State): if given other choices, graduates will tend to work on projects that are more interesting or "hard-core" (to borrow a phrase Joel himself has used in terms of of what sort of he experience he looks for on people's resumes).
(Edit: Had a point about GPA, but since others are talking about this, I'll remove it. That said, does Joel (or anyone else) have any hard data on this, in a statistically significant sample?)
The fastest way to make your bug tracker into a challenging project is to approach it with the idea that it's not a challenging project and therefore unworthy of serious developer time or energy.
We had one of those where I work. It just got its ass decommissioned and replaced by virtue of being too challenging to work with.
Every non-trivial program has significant challenges in it; if you can't see them, it's probably your lack of experience or your casual assumption that it must be easy, not the fact that the task itself is that easy.
Of course, that challenge may be hidden behind other problems. You may not be allowed to actually address the challenges; a code monkey making the same change to 50 webpages instead of writing the proper code to do it all in one fell swoop is doing something challenging in the sense of difficult (more difficult than it has to be!), but not the right things. This is a far more common cause of "unchallenging programming" than the actual lack of hard problems; most of the time, most programs completely fall apart under their own complexity load before the true challenges even come into sight. This is, however, the fault of the system building the program (programmers and management), not the problem domain. Wherever there are people to interface to computers, there is challenge.
> Every non-trivial program has significant challenges in it; if you can't see them, it's probably your lack of experience or your casual assumption that it must be easy, not the fact that the task itself is that easy.
I remember Joel talking about Wasabi, purpose built language for making their main product cross platform. I see many business software vendors doing this e.g., SAP with ABAP, but I'm curious as to whether there has been a significant ROI from it (I heard mixed things about its current status of both Wasabi and ABAP and since I have no background in business software I'll refrain from commenting further on this practice).
I agree that are there are significant UI/UX challenges in a system like a bug tracker (and quite frankly, most of the existing offerings are a disaster in that space). There's also a whole slew of fairly interesting problems you could do in the greater space (integration with a VCS/code-review/diff tools in comprehensive system like Github, Google's internal tools or some of Atlassian's offerings).
It's also far from a trivial problem, which is why most companies are willing to pay for bug tracking systems rather than write their own (although, it used to be common to use heavily customized versions of Bugzilla): problems don't have to be "hard-core" to be non-trivial or extremely useful (much like Joel advices, I'd refuse to work in a company that didn't have a bug tracker). If I ever gave an impression that I considered a bug tracker trivial, I apologize for it.
What I should say instead is if you're looking for a "hard-core CS" challenge (systems, networks, data structures and algorithms) -- and certainly only a small minority of people are both qualified to and are interested in working in that space, in reality these topics involve lots of fairly unglamorous work -- a bug tracker seems like the wrong thing to work on.
I wouldn't make the whole point, if Joel didn't spread the whole "we're hiring best programmers to solve the most difficult problems" aura and has instead stated "we may not be the most hard-core, but we build great products and treat developers as more than just cogs". The latter point sounds a lot more honest and still suffices in terms of recruitment. There are many people (including many hackers I know and respect) who are passionate specifically about development tools and they're the people you want to be working on development tools who aren't going to be interested in Wall Street (or any other place where building development tools isn't a core competency, which excludes most other software and Internet firms with exceptions of the largest, who have custom needs) in the first place.
One thing which is surprising with bug tracking is how crappy most of the products are, especially the open source ones. This strikes me as odd a priori since open source is generally pretty good at core programming tools - and bug tracking certainly fits that category.
That's why he needs the fancy Manhattan office, business class flights for interns and catered lunches.
He is competing for programmers with grad school (cool projects no money), google (cool projects good pay) and wall st (cool projects* awesome pay)
And he is offering a bug tracker written in a home grown asp.net language.
* He paints Wall St as boring but remember he isn't competing to hire Oracle/Sharepoint back office devs. He is competing to hire C++/CUDA/Erlang/maths realtime quant types.
Probably a selection bias. He doesn't want the types frequently found on Wall Street firms. He found good people who do NOT want to go there, and assume every good people does not want to go there. Or the kind of programmers he's looking for.
I kinda have this prejudice too. If you're doing Wall Street job, it's probably some boring stuff, 100% focused on money and enterprise, with crappy UI and thousands of slices of the same dozen reports.
I work in the equities group in an investment bank. Joel's probably right about a lot of wall street jobs but certainly not all of them. I'm not even involved with the most math/CS intensive stuff but I still work on:
- Creating/consuming "real-time" data feeds with thousands of events per second
- Custom pub/sub in-memory databases
- Complex event processing on streaming data
- Homegrown data structure libraries designed for low-latency applications
Honestly, it's a lot more interesting than what I used to do at large public websites. The hours are no worse and when you include the bonus I bring home 2x as much. The cap is also insanely high, even for people who want to stay coding 90% of the time.
Sure, it's nothing like working at a startup. There's lots more meetings, you're a cog in a giant machine and no one outside of the company ever gets to see what you do. I bet working at a small hedge fund/prop shop approaches the best of both worlds.
It gets frustrating when so many otherwise knowledgeable folks write off an entire industry.
Joel is pretty spot on with his assessment of being a dev at a wall street firm. While the pay can be immense, it is clear that software is not their core business, and you are treated as such.
Also for every really cool cutting edge internal project, there are a ton of uninteresting internal systems (order management, reporting, accounting, compliance, etc...) that have to constantly be maintained and updated. Some of which have been around for years.
I worked with ex-traders for a while helping them try and develop real time approaches to VaR calculations (note this was 15 years ago) for an investment bank.
Not only was the area intellectually fascinating, costs weren't a big problem in terms of infrastructure (Sun Enterprise kit all round) but the people themselves were very interesting - probably some of the smartest people I've ever worked with.
I respect Joel for sure and he's got way more experience than I do, but I strongly disagree with private offices for developers. I had that while at MS and at first I thought it was just amazing. It didn't take long before I realized how much it stifles communication and even how territorial it can make people. Sure cubicles or even big rooms with open desks aren't nearly as glamorous or prestigious, but in my experience they foster teams that talk to each other, constantly, about the product. The overall team knowledge goes up dramatically. It also fosters an environment where people are more on the ball and productive, instead of sneaking off to some vice website every 5 minutes.
At GitHub we use conference tables that everyone sits around, along with a couple of couches if you wanna chill out somewhere else. We spent our first two years working out of coffee shops, so we replicated that environment without all of the additional noise and distractions.
If there's something that truly requires uninterruptible concentration, you just stay home and work there, or put in your noise-canceling headphones and zone everyone else out at the office.
When you work with people you consider friends, the last thing you want to do is sit in an office. For that reason alone, I'm not convinced offices make people more productive. I'd rather keep people happy and the productivity will follow.
In my experience, private offices foster increased communication because a small gropu can get together and talk without having to get a conference room or pissing everyone else off.
A lot is going to depend on how really difficult the work is. If you must establish and maintain flow then you need a quiet, no distractions environment (unless you're one of the rare sort who can ignore your environment ... I can when I'm doing intense debugging).
I hope you're statement is based on more than your experience at Microsoft or at least them as of late, it's pretty clear that they've become seriously dysfunctional.
Open spaces "foster teams that talk to each other, constantly, about the product".
Well, that's nice, but when does the actual creation of the product occur? And how truly difficult are the products developed in these sorts of environments? E.g. are you just bolting together existing "parts" and the user visible stuff is overwhelmingly critical? ADDED: or are you doing something like ViaWeb (the extreme level of store customization that was never replicated in C++).
If you have people who absent a panopticon are "sneaking off to some vice website every 5 minutes" then you've got much greater problems than anything related to your environment. They're not dedicated to the project, perhaps because they don't have what it takes, perhaps because you've failed to create the necessary conditions. Either way, I don't see any good alternative to solving the root problem (and if your company is a really bad and dis-motivating place, why are you still there???).
These are all good points. Perhaps the reality is something like physical layout of the office doesn't influence things as much as the team itself. However, something as simple as physical layout still will affect things at least to a degree.
I know that there's a well established rule of thumb that states close collaboration just doesn't tend to happen beyond 30??? feet or a single staircase (i.e. people further apart just don't tend to collaborate). This is of great interest to universities and other places that do research, you should be able to find something, maybe in Peopleware (which if you haven't yet read you want to anyway).
True. However they also say: "...enclosed offices need not be one-person offices. The two- or three- or four-person office makes a lot more sense, particularly if office groupings can be made to align with work groups."
I think there needs to be a balance between private/semi-private team space and individual private space within the team space.
Indeed. It was, however, written in a very different period of software development and one could argue that it may be less applicable to the the "bolt things together", MVP consumer product/site sort of project that is the greatest?/primary?? focus of HN/YC/today's angels funding.
(To emphasize how different, we can be pretty sure that very few if any of the programmers studied had a memory budget even close to what's been in mainstream CPU caches for some years.)
For another example, see MIT's termination of SICP/6.001/Scheme with extreme prejudice and replacing it with Python based "bolt together" course(s) (I don't know anything about 6.02, but the initial 6.01 robot project is just that ... which is not to say that it's easy, e.g. it requires the use of differential equations and its labs are very instructor intensive, to the point the department is recruiting upper-classmen to help).
MIT believes that things have fundamentally changed....
I prefer an office, but for those without I think there should at least be "quiet time" or consideration given to where different types of workers are located.
This helps avoid the "talkers vs. typists" problem--don't mix the two. For example, don't put me near the support guy who has loud and frequent speakerphone discussions about resetting passwords, his personal doctor visits, etc. ;)
The 'we have no heirachy - the owner doesn't have an a office' open cubical farm where you are stuck between chatty secretaries and shouting salesmen.
And the private offices where one office = one person = one module and the only way to talk to somebody about 'their' part was a request up the management chain.
Best was a 'programmers only' room with one huge desk for three programmers on the same project.
I used to think that programmer needs to work in a very quiet room because they need ultra-sharp focus. Turned out there are bad side effect from this situation.
This is one of the reason why programmers tend to be weirdos and outcasts.
This is also a reason that you often found crazy complex code. As you mentioned it before, they become territorial. I often met with programmers whom you can't just disagree with. It's like they live in their own world and everything they do is right according to them. Coincidentally when you write your own program, you're a god in that universe.
The stories of "a small group of great developers working together on a great product" were often being told in HN threads. Please understand that we should emphasize more on the word "group" and the phrase "working together". They don't work alone.
By the way, I had experienced private office too before. Boring.
The more I think about it, the more I'm starting to believe in shared offices or small, isolated cube farms. Noise is minimized and there are people around for ease of communication.
I worked for a fairly large company (Gemalto). Developers had shared offices, two to an office. The office had a partitioning wall through the middle, but it did not extend the whole width of the room, so it was semi-open space. There was also a fairly strong open-door culture, so you could hear, softly, the conversations happening in the other offices. That really worked for me. When I needed serious focus time, I just popped on some headphones.
I hope dogs don't become an "internet standard". I don't want to work in an office with dogs. Maybe it would repulse me so much that I would even reject to work for Google.
Besides, I thought the internet standard is LOLCats.
The GPA thing always bothers me to hear it admittedly because I wasn't a great student in college. I typically always had my own thing going on that I cared about more. I can see where he's coming from though and I consider high GPA to a good sign when I'm looking at a resume. Often when I look at resumes I'm just looking for anything good.
My career outside of school is considerably better than that my work in school would have ever suggested. Before I started my company I was always the programmer who everyone hated to see leave and who was offered a lot of money to stay. I was glad to hear people talking about my younger brother who is also a programmer the same way. I figure that's the final measure of how good you are.
I never really cared much about what I worked on though. I always just wanted to be kept busy. Part of why I wanted to start my own company was to stay busy.
What interests me is if there's any correlation between objective ability (as in programming 'skill') and GPA. I'm not surprised that programmers with good GPAs make better hires for Joel - it means they're more likely to do work on somebody else's project even when it doesn't particularly interest them (which is good for an employer in a small/medium size firm like Fog Creek, as opposed to an early-stage startup).
But is there any correlation with programming ability? Or is GPA just an indicator of 'obedience'/employability?
Nonetheless - great insights, all of them, as is only to be expected from Mr Spolsky.
If the courses were rigorous enough, then I'm sure the correlation between grades and programming ability would be meaningful and fairly reliable. It's hard to imagine someone doing well at courses like algorithms, statistics, and compilers, and not being a decent programmer too.
> It's hard to imagine someone doing well at courses like algorithms, statistics, and compilers, and not being a decent programmer too.
Sure, but are those who did poorly in those classes less likely to be good programmers?
I aim for slightly over a 2.0. I limit myself from going lower because that puts me on probation, which does irritating things like prevent me from being on paper as a club officer (I'm unofficially the president of our LUG for this upcoming year). I don't aim for higher grades because I find that the amount of work required is on an exponential order - the difference between a D and a C is far less than a B and an A. Doing fewer assignments gives me time to work on all sorts of projects that there aren't any classes for. As a result, I've got a basic understanding of quite a few different things, enough to realize if one of them is a good solution for a problem.
But that's what I am - the guy who knows a little about a lot. My role in a recent team project was essentially that of technical advisor: when my teammates weren't sure of how to approach a problem, they came to me for suggestions.
Now, will this bite me in the butt later? Quite possibly.
Edit: I suppose my question is this: would you rather hire someone with a good GPA but little programming experience outside of school, or someone with a rather poor GPA but contributions to open-source (with code quality being roughly what you would expect in order to achieve the first candidate's GPA)?
There is a correlation between GPA and working hard.
Yes there are awesome programmers who have terrible GPAs because they dropped out of high school to found their own company, or who refused to do any non-programming subjects since kindergarten.
But you want to hire somebody he has been working their hardest on everything they have been given to do - however uninteresting - since the age of 11.
> But is there any correlation with programming ability? Or is GPA just an indicator of 'obedience'/employability?
When we were looking at entry-level resumes in a big consulting company we looked at the following:
1. Did they complete college? If not, have they shown that they can stick with something over months and years?
2. Did they have a good GPA? If not, do they stand out from their peers in other ways?
3. Have they chosen a path that takes dedication to master? We found that music majors could do very well on I.T. projects with some coaching. They were used to committing time and creativity to mastering difficult tasks.
>>>GPA is really good predictor of good programmers (this surprised me). You can have great programmers who have bad GPA but that often means they are great only when working on super interesting projects which won't always be the case in real life.<<<
I think that this is a bad line to draw. Sometimes, it's about bright kids getting bored with dull teachers, but more often it's about troubled kids who need to escape. This is quite important because I would hire someone who has crawled his/her way up through adversity in a heart beat. As compared to someone with a cushy resume with an equally cushy life.
Think about it in this way. Person A has never had anything to take for granted and has to fight for every inch s/he has gained in life. Person B has a much more impressive resume, but grew up in a comfortable life with an entire army at their beck and call. Who would you choose for a startup fighting against the odds?
[edit - I haven't judged someone on the basis of their financial background, or something like that. In fact, what I was trying to say is that until you understand the context of what a person has achieved you cannot judge them. Kids who have parents with large bank balances can also face a far from ideal childhood. Moreover, kids whose parents struggle to make ends meet can have the perfect environment to grow created by their parents.
It's my observation that you can't judge if someone will be good, or not on the basis of what lies on the surface. You need to truly understand the struggles of the person in front of you to make that decision.
So, as a rule of thumb I would pick someone who has struggled more in life vs. someone who hasn't felt the world crash around them.]
Are good GPAs a predictor of good programmers, or good employees? I would argue the latter, though they certainly aren't mutually exclusive.
My take on it is that those with good GPAs are probably more likely to work well within a structured framework (show up 9-5, work, go home) and with more feel-good rewards ("here's an A+" and "here's a $5000 bonus this year for consistently working 50 hours/week"). Those who don't care about things like GPA are more interested in what they're getting out of it (what they actually learn, making FU-money, working for themselves, etc) than rewards bestowed upon them by others for their great work.
Of course that's a huge generalization and entirely anecdotal but I don't think it's all that inaccurate.
You make quite the leap from GPA to a person's financial background. I would still lean toward the individual with the higher GPA, as it really is a solid indicator of how hard someone is willing to work. Joel makes a great point that academic projects are frequently uninteresting, but a high GPA indicates that the candidate can complete these tasks regardless.
Judging someone on their financial background instead is heavily subjective, prone to all sorts of prejudices and pre-conceived notions, and doesn't actually tell you anything about the person's abilities.
After all, a driven and motivated person from a troubled financial background can achieve a high GPA. Your theoretical 'Person A' who lived a cushy life yet isn't motivated won't be able to achieve a high GPA without working for it.
My point wasn't to make the case for high or low GPAs. Or, for checking the parents bank account, but it was just an observation that lines can't be drawn without context. It's only when I understand someone can I judge his/her accomplishments.
However, when you are trying to hire someone on a massive scale then this isn't always possible. So, that's why, I think, it's better to throw the resume into the dustbin and look at what they've actually built on their own.
So, this way you don't throw false negatives, while having a lower false positive layer.
I definitely agree with you that lines should not be drawn without context. However, I don't think anyone here would choose someone solely on GPA either.
Still, I'm not going to hire someone who has poor grades and personal problems over the smart kid, as in your example. No matter how you cut it, someone who can complete college with a solid GPA has already proven that s/he can set goals, handle deadlines, deal with multiple managers (professors) all while learning the material and completing the homework and tests.
Your aversion to the 'smart kid cruising through' is a bit perplexing. I usually work hard to get and keep the smart kids on my side.
It's not an aversion. Or anything like that. I make a point to never judge anyone. Ever.
Yet, I sincerely think that the kid that struggle to put him/herself through college and fought against all the odds to sit in the interviewee chair should be hired. It's about determination to make things work no matter what.
Person B has shown that s/he can work within those constraints, but they haven't known perpetual hopelessness with fear about their future. They haven't fought to make things work no matter what. They haven't faced repeated failure and crawled their way up from there.
So, in a lot of ways I will respect person B, but person A is a determined survivor and I would prefer to hire him/her.
I think the issue was that your original post could be interpreted to mean that GPA is determined primarily by the amount of adversity in one's personal life and very little by academic ability. This is contrary to what I've observed: those with hardships still do fine academically, only a very small step below those with everything going for them, whereas those with genuinely bad GPAs typically aren't putting much effort into their coursework or are simply in the wrong major.
I just talked to my friend who's been running the MIT EECS undergraduate program for the last 3 decades and she says the breakdown in graduating students goes roughly like a quarter each in:
Postgraduate education (12% Ph.D., the rest law school, med school, etc.) Quite a few do some sort of postgraduate education some years later but MIT has no hard numbers on them.
Finance/consulting (their math skills will earn them a much higher salary on Wall Street than they can get anywhere else).
Established companies (e.g. as of a few years ago Oracle was the best for starting salaries, $95K then).
Startups.
So with the current per class enrollment of ~200 students that means Joel has a pool of 50 students who might want to work for him.
Maybe they don't work to work on .NET and/or in NYC???
Note that all the above are "official", public and current, straight from the source.
The problem is, you don't know which 50 it is. I mean, we're talking about 22 year olds here, they probably don't even know. You end up having to "advertise" to all of them, which then leads to you interviewing some of them who are 90% sure that they're going on to a PhD, but just want to do the interview [for experience|to make their parents happy|to see if it might change their minds].
Full disclosure: I work for Fog Creek, and went to Stanford.
Well, that certainly sucks, and I e.g. in 1997 worked for a new grad who had interned at Microsoft and either had an offer there or had accepted it before his elder brother convinced him to work full time at the brother's startup, for which he'd programmed their prototype. (The other guy they really wanted was in SV and still happy their, until his company went poof much later).
Anyway, what you're staying is that it's difficult to qualify your sales leads at MIT and that results in a lot of critical wasted effort. So much it's not worth trying (hard)?
Exactly; it just doesn't make sense for us to go to them and recruit. Of course, that doesn't mean we're going to ding them for having gone to MIT or Stanford if they come to us. We're a small company, so we need to focus our recruiting efforts where they'll be most effective.
I had a similar experience - I interned at a government organisation that only recruited at Oxford/Cambridge because they wanted "only the best".
But it was such a crap place to work they their actual hires were from 3rd rate institutions. They would have been better focussing their recruitment on them. But that would mean admitting there was a problem - so much better to convince yourself that the Oxbridge grads all went to do PhDs instead.
I wonder if those programmers typically do better on their own projects or in their own startups. I would suspect the answer is yes, and they're probably a similar class of people to those who are good programmers with mediocre GPAs in school.
It's interesting to tie that in with the 5-10x productivity claim - what about your working environment? If you're working in a negative environment motivation is staunched which inevitably affects motivation.
Another point about productivity - if you're working in an environment where people want crap shovelled out as soon as possible, then the people who care about maintainability are likely to take longer on software (though once you factor in support, something often shovelled under the carpet, you will often out-gun the 'put out crap then fix it up' approach), and thus appear less productive than mediocre colleagues.
Don't get me wrong, I do agree with Joel on most of these points, and I think he's probably talking about 9-5 developers who have little motivation to improve rather than passionate but burn-out or disillusioned developers.
Motivation to work on what Joel will pay them to work on.
I've known a few really bright developers who would be highly motivated if you were asking them to produce a streaming media server or debug a problem with the Linux TCP/IP stack (real examples) but who would probably die of boredom working on a bug tracker.
Yeah, we've all had times where we're just burnt out... That would look to an unenlightened observer like "motivation problems" and it is completely recoverable from.
>Programmers with motivation problems: Joel has rarely seen successful "turnarounds".
Hmm, this is properly a more specific example of the general point that you can't change people, only people can change themself - I would imagine that the successful turnaround would be a lot higher for those who themself perceive this to be a problem (and not just claiming so to avoid problems).
Boy, I gotta tell you from personal experience that Joel's right on. My GPA was OK, not perfect, and motivation is something I've been fucking fighting for over a decade.
I've finally even gone to a psychaitrist but it's still a massive struggle and no magic bullet.
So I have to agree with you, Joel. But damnit, I wish I could prove him wrong. I fight this every day.
You know, I once went to a doctor to ask about ADD, and was told I didn't have it. Fast forward a couple years later, I was diagnosed with ADD. I used to have motivation problems, and don't anymore because of the ADD medication. My (maybe unwelcome) suggestion: talk to a lot of psychiatrists.
If you're talking at least in part about procrastination, this is one book I've recently gotten good mileage out of. It's a quick but useful read though, as you say, there are no silver bullets:
On one hand, a little voice inside of me cries, "Yes! This is what it takes to produce great software: a programmer-appreciative environment."
On the other hand, another little voice claims, "This stuff is all well and good, but nothing more. It's cosmetic, not functional, like putting perfume on a pig."
I have been in many situations with Class A office space, private offices, catered team-building breakfasts and lunches, etc., etc., etc. and was ready to jump out the window. Why? Because the work sucked and all the window dressing in the world wasn't going to change that.
Then I think back to some of my most favorite projects and remember the great work that we did. Sometimes in squalor-like conditions, sharing cubicles or tables, sitting in the server room with too much air conditioning or in the warehouse without enough, eating vending machine garbage and drinking old coffee because that was all there was.
Bottom line? The work itself is 100 times more important than the working conditions. Sure, everything being equal, I'd rather have nicer digs. But everything not being equal, I'll choose the better project every time, no matter what the environment is like.
I suspect Joel gives the programming environment more credit than it deserves. His people are probably happy, and the office helps. But the real reason is the work itself, and they'd be almost as happy no matter what the office was like.