The question presents itself: why would someone that good want to work on project management software with such a funky user interface and oddball feature set?
That's the same sentiment I had. The software guys I've worked hated FogBugz so much they scared the crap out of our CEO. I watched Aardvark'd and once longed to work for The Great Fog Creek, but I've already moved onto bigger and better things.
In 15 years in the industry I have met many people who like to quote Joel Spolsky, but I have not come across one single person who actually uses a Fog Creek product. Kinda like lots of people have read ESR, but no-one is using his code...
1. They have a stable base of corporate microsoft shops using fogbugz -- which is why none of us knows anybody using it. My guess is their other products make little if any revenue.
2. They don't pay most of their people very much. They probably only have a dozen or so people on staff full time and everyone else is an intern.
3. Their job board does pretty well. Quite a bit of passive $$$.
Fog Creek seems like a stable and profitable business. That said, there are thousands of profitable small boutique software companies out there.
Why not? I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. Some "sexy" areas of programming (data mining, high scale apps) can be an enormous grind. Some CRUD business apps can be very rewarding. What matters is having a very good effort->reward loop. You can get that loop from building project management software. The specifics of the organization and the development process matter more than what you are actually building.
Indeed. The interesting programming problems are almost always independent of the business problem domain. I work for a company that writes HR applications. Very boring. The programming part, though, is very interesting.
Things like Moose, KiokuDB, and so on all came out of this work.
"I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. .... The specifics of the organization and the development process matter more than what you are actually building."
This contradicts my personal experience.
I worked for a great organization (ThoughtWorks) which had a great development process (Extreme Programming with "lean" elements, with a lot of tailoring and flexibility, the team could do almost anything really) and I worked with great, awesomely talented people, but I got bored to death with the enterprise apps we were building (the domains were all incredibly boring to me, and I could switch off 90% of my brain and still deliver successful projects) and so I left.
Now I don't have an "organization" (I often work alone or with small groups of people assembled for a project and that too virtually), but my domains (AI/robotics/ Computer Vision/Planning software) are so much richer than what I used to work on, (and so is my toolkit - C, erlang,lisp etc vs java/ruby-on-rails) that I wouldn't exchange the "grind" bits of these projects for the "cool" bits in my old work.
I suggest that just as working in lisp maybe in general more pleasant than working in COBOL, (there will always be exceptional situations where COBOL is more pleasant, or the odd person who prefers working in COBOL), programmers would in general prefer some fields of programming to others.
You say,"What matters is having a very good effort->reward loop. You can get that loop from building project management software." .
I agree totally, but I'd also say that unless you are running your own startup making such software, this would be a rare experience.
In my experience the "reward" in enterprise software comes from understaning customers in depth and satisfying them. In a non startup enterprise coding effort, this is hard (but not impossible - see jrockway's example in his answer - I am just claiming this is more the exception not the rule) to do?
What Steve Blank calls "Customer Validation" remaining equal, maybe there are levels of "blub" in domains and/or projects too?
EDIT: This quote from PG expresses this idea much more clearly than I could
"
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers."
from PG's "Great Hackers" essay.
PS: I don't claim to be a great hacker but I am probably a good one.
So that they don't get abused and mistreated like they do at most startups and large software companies?
Depends on what you want from your life really, but if you're given a challenging environment where you get to perfect your craft and learn from other equally intelligent people - what more could you ask for?
Comments
The question presents itself: why would someone that good want to work on project management software with such a funky user interface and oddball feature set?
That's the same sentiment I had. The software guys I've worked hated FogBugz so much they scared the crap out of our CEO. I watched Aardvark'd and once longed to work for The Great Fog Creek, but I've already moved onto bigger and better things.
In 15 years in the industry I have met many people who like to quote Joel Spolsky, but I have not come across one single person who actually uses a Fog Creek product. Kinda like lots of people have read ESR, but no-one is using his code...
How are they so profitable then?
A few things to consider...
1. They have a stable base of corporate microsoft shops using fogbugz -- which is why none of us knows anybody using it. My guess is their other products make little if any revenue.
2. They don't pay most of their people very much. They probably only have a dozen or so people on staff full time and everyone else is an intern.
3. Their job board does pretty well. Quite a bit of passive $$$.
Fog Creek seems like a stable and profitable business. That said, there are thousands of profitable small boutique software companies out there.
Why not? I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. Some "sexy" areas of programming (data mining, high scale apps) can be an enormous grind. Some CRUD business apps can be very rewarding. What matters is having a very good effort->reward loop. You can get that loop from building project management software. The specifics of the organization and the development process matter more than what you are actually building.
Indeed. The interesting programming problems are almost always independent of the business problem domain. I work for a company that writes HR applications. Very boring. The programming part, though, is very interesting.
Things like Moose, KiokuDB, and so on all came out of this work.
"I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. .... The specifics of the organization and the development process matter more than what you are actually building."
This contradicts my personal experience.
I worked for a great organization (ThoughtWorks) which had a great development process (Extreme Programming with "lean" elements, with a lot of tailoring and flexibility, the team could do almost anything really) and I worked with great, awesomely talented people, but I got bored to death with the enterprise apps we were building (the domains were all incredibly boring to me, and I could switch off 90% of my brain and still deliver successful projects) and so I left.
Now I don't have an "organization" (I often work alone or with small groups of people assembled for a project and that too virtually), but my domains (AI/robotics/ Computer Vision/Planning software) are so much richer than what I used to work on, (and so is my toolkit - C, erlang,lisp etc vs java/ruby-on-rails) that I wouldn't exchange the "grind" bits of these projects for the "cool" bits in my old work.
I suggest that just as working in lisp maybe in general more pleasant than working in COBOL, (there will always be exceptional situations where COBOL is more pleasant, or the odd person who prefers working in COBOL), programmers would in general prefer some fields of programming to others.
You say,"What matters is having a very good effort->reward loop. You can get that loop from building project management software." .
I agree totally, but I'd also say that unless you are running your own startup making such software, this would be a rare experience.
In my experience the "reward" in enterprise software comes from understaning customers in depth and satisfying them. In a non startup enterprise coding effort, this is hard (but not impossible - see jrockway's example in his answer - I am just claiming this is more the exception not the rule) to do?
What Steve Blank calls "Customer Validation" remaining equal, maybe there are levels of "blub" in domains and/or projects too?
EDIT: This quote from PG expresses this idea much more clearly than I could
" It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers."
from PG's "Great Hackers" essay.
PS: I don't claim to be a great hacker but I am probably a good one.
So that they don't get abused and mistreated like they do at most startups and large software companies?
Depends on what you want from your life really, but if you're given a challenging environment where you get to perfect your craft and learn from other equally intelligent people - what more could you ask for?
More money.