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.
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.
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...
-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.
-Catered meals, smart team-mates, good pay.
Incidentally, we're hiring too (Allston Trading).
Has Joel ever worked for a Wall Street firm?
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.
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?)
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.
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.
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.
- 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.
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.
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.