Caught this little gem in the comments section of a Slashdot posting:

---

Windows Made Me This Way

How Software Companies Die

Windows Sources, March 1995, p. 208

By: Orson Scott Card

You can domesticate programmers the way beekeepers tame bees.

The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it.

Beekeeping

Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their fathers' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Geez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.

Out Of Control

Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.

Smoked Out

The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it.

---

Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already.

I know this feeling...well, minus the fat, smelly part.  And I have to admit, I haven't felt it in a while :(

I am definitely in a funk of some sort.

I've just been completely out of it ever since I pulled a 110+ hour week at the beginning of November working towards the release of the project I'm working on: FCG's FirstPoint.

Now that we're nearing the end of the year, we're getting ready to prepare a release.

I think what I've learned from this process is, surprisingly, the importance of process in software development.  That's something I thought I'd never hear myself say (or see myself type).  Having gotten my start during the tail end of the startup era in 2000, I've been used to small teams with light processes to promote speed and efficiency.  But I think often times, people who don't have experience putting together large projects are all too willing to sacrifice "doing it right" for "doing it fast".

I've always been an advocate, but this go round, I think I might have been too soft and let off of it too soon.

One has to insist on some level of process that defines an overall workflow from conceptualization to realization, even more so for remote teams.  Certainly, these processes and workflows should not be set in stone, but they must be considered and they must be documented for the better of the team and progress.

Cooking a meal for 2 is easy enough; most recipes are written this way and most cookware is designed for preparing such meals.  But how about preparing a meal for 200?  All of a sudden, the scale of it all changes dramatically.  One needs larger infrastructure to support the ingredients, larger cookware, larger utensils, more manpower, and most importantly, there must be a process and a "glue" to hold all of these components (cooks, prep stations, servers, dishwashers, etc.) together now and ensure that the components work in unison.

Without process, planning, and infrastructure to support it, such an undertaking will surely be painful and the dishes will likely be served slightly late and a bit cold.

In writing software, the boundary between cooking for 2 and cooking for 200 is a very fine line.  It's not so much as how many concurrent users the software will support (although that does increase complexity), but how many features must be included in the software package.  When preparing a dinner for 4, preparing a two course meal will be significantly easier than preparing a 7 course meal simply due to the lesser number of ingredients to prep, store, and cook. 

With software engineering, all too often, it is simply too easy to go from preparing a 3 course meal to a 7 course meal if scope and feature creep isn't controlled.  I think process can help this by ensuring that the introduction of new features isn't simply "hey, I need this new feature, can you add it?" but more involved and includes a thorough evaluation of how the feature fits with the existing feature set, whether it is a "must have" feature (of course the boss always says yes :), and planning to consider whether it is part of a larger featureset that can be slated for a later release.

Process defines milestones and encourages visibility to the timeline of the project.  It makes the future more tangible.  If you know you have milestone 1 in three weeks and milestone 2 in 5 weeks, it makes it easy to schedule a task estimated at 4 weeks of work for milestone 2 instead of trying to shove everything into one giant release.  Process defines the workflow for introducing new features in a controlled manner such that features are not introduced in one module that breaks another module since, with the right process, those involved will have long since had a chance to review a rough design specs and will know ahead of time, the changes needed to adjust.  Process ensures that code that is commited is well written and written to a common standard.  This is done through mandatory peer reviews and knowledge exchanges on regular schedules.

But in any case, 'tis a lesson learned.

Day two was pretty busy, so I didn't really get a chance to take any pictures.  Towards the end of the day, I was definitely feeling a bit high strung.  I'm goal oriented and I abide by the saying: say what you will do; do what you say.  This doesn't fly so well with everyone I guess.  Certainly, sometimes you do underestimate the task at hand and you simply have to live with "good enough", but this just causes all sort of anxieties with me.  But regardless, we made some really good progress; got lots of big pieces working.

The hard work contiuned on day 3. 

Man, just look at everyone hard at work.  Damn, look at that concentration on Jim's face.  That's what I like to see.

Dave (front right) was giving a quick presentation on some of the ComponentArt libraries.  I'm not a big fan of these things (I prefer the raw web services and AJAX.NET), but I guess not everyone wants to abandon the ASP.NET model so quickly.

We had lunch in the office because we were all in the groove.  But I hear it's Thuy's birthday tomorrow and we're heading to Hooters .

Gray cells continue to churn after lunch.

For some reason, the thought occurred to me that I hadn't had a corn dog in, oh I dunno, 10 years?  Not only did we end up with any old corn dogs, these were freshly battered!  Pretty awesome with some squeezed lemonade.  You may have noticed the supersized drinks (in this case, lemonade).  But you really can't begin to imagine how much caffeine these guys consume on a daily basis.  Rare is the day that Brady or Brad will wander into the office without their 64oz. diet Coke in the morning (and then continue to order diet Cokes throughout the day..amazing that they sleep at all).

Still more work to do.  Day 4 awaits!

So this morning, a FedEx Express (redundant?) truck showed up at my front door promptly at 9:00 to deliver a little bundle of joy: a new workstation.

For as long as I've worked, I don't think I've ever received a new development machine from any of the companies I've worked for.  To cope with the invariably crappy, last gen machines that I've been assigned, I've always ended up buying my own.  I bought my own laptop after a few months suffering on an NT4 workstation with something like an 4 GB harddrive and only 100 MB were left for me to work with (this was in 2003, mind you).  I bought my own desktop (a screamer of a machine in its own right) after my laptop became too outdated to handle the resource hungry 2005 suite of software and servers from Microsoft.

The importance of good hardware can't be emphasized enough.  Fast hardware helps shorten compile times, helps shorten debugging cycles by offering better runtime performance, helps shorten development times by allowing for more installed tools (think ReSharper), and I think, in the big picture, help reduce developer stress and frustration.

As trivial a gesture as this may seem, for the first time, I feel appreciated and I feel like my employer takes my job and tasks seriously.  It's a truly special moment  It's as if he understands my pain (well, not so much mine since my machine is less than a year old (dual core @ 3.2GHz, 4GB RAM, 3x10K RPM HDs), but my pain in working with the rest of the team who are still on first gen. Centrino laptops with 4200RPM HDs).

I'll have to add some pictures later and some screenshots.  For now, I am beyond ecstatic that, finally, our entire team will be able to really be much, much more productive.  I can't say enough about our once CEO and now VP who really went the distance to make sure that we got some quality hardware.

The following are the contents of an actual email that I received this afternoon:

Hi cchen

I have a very hot Java Developer rek with a direct-client in Manhattan. Please send me candidates with rates and contact-numbers.

Interviews this week.

Thanks
-Priya M.

I would be shocked if Priya lands any candidate this year.

Let's dissect all of the ways that this email is completely ineffective:

1. I am a .Net developer.  I know Java and worked with it for 4 years on college, but I have not worked with it in any sort of significant capacity since then.  Assuming this email was generated based on my profile on either Dice or Monster, you'd think that the recruiter would attempt to filter the candidates...
2. "Hi cchen"?  Why am I being addressed by my email account name?  I'm pretty sure that I have my name listed on Dice and Monster.  If this were to have come from some third party database somehow, wouldn't it make sense to just use something like "Good afternnon,..."?
3. "rek"?  Take some time and type out the extra keystrokes and spell it out.  A little professionalism goes a long way.
4. No.  I am not doing your job for you.

Contrast this with another email from a Bradley G.:

Dear Applicant,

My name is Bradley and I'm an IT recruiter at [XYZ]Technologies Corporation. Our records show that you are an experienced IT professional with experience in .NET. This experience is relevant to one of my current openings.

The opening requires ASP in addition to the above skills.

It is located in Pittsburgh, PA.

If you are qualified, available, interested, planning to make a change, or know of a friend who might have the required qualifications and interest, even if we have spoken recently about a different position. You may also send me an e-mail with a copy of your current resume. If you do respond via e-mail please include a daytime phone number so I can reach you.  In considering candidates, time is of the essence, so please respond ASAP.  Thank you.

Sincerely yours,
Bradley G.

If you are not currently seeking employment, or if you would prefer I contact you at some later date, please indicate your date of availability so that I may honor your request. In any event, I respectfully recommend you continue to avail yourself to the employment options and job market information we provide with our e-mail notices.

Much more professional and much more likely to actually attract a candidate, but it still gets a few items wrong:

1. I did not apply for any job.  It would have been better to use use a simple greeting like "Good afternoon" or "Greetings" or perhaps even something creative like "Hello from IT land!"
2. I would have added "please responsd ASAP"...seems like a bad sales pitch.

Just some random afternoon ranting...

I stumbled on a post by Don Demask on the subject of tech/IT recruiter etiquette. Or rather, I should say, the lack thereof.  I've touched on a similar topic in the past (in fact, one of my first posts on this blog!) after I was simply driven mad by rude headhunters (one that kept asking me to doctor my resume) and many that implicitly discriminated by age by asking my graduation date (this is a very dirty tactic that they use to figure out where to bracket you in terms of rate, salary, and position, irregardless of your actual skill and knowledge level).

Since I graduated from Rutgers in 2003, I’ve already worked for six companies (that’s including my current employer, Zorch Software). Of those six, three of them were acquired through recruiters and there were many other times where I’d come across these sometimes very curt “professionals” as I was searching for better opportunities.

Of the many, many recruiters that I’ve come across, I would have to say that only one sticks out in my mind as being truly a professional: a Mr. Seber, who helped me obtain my first position out of college. He offered me great career advice, guidance on proper behavior on the client site, information regarding education, and was always open to listen to me bitch and moan from time to time.

These days, I’ll drop by and listen to his band play once in a while and we are still in contact.

While there have been a few other very courteous and polite recruiters that I’ve come across, the vast majority of them are simply rude, unprofessional, and lazy. One of the laziest and most annoying tactics that this type of recruiters use is to simply spam email lists with random positions; as Don calls it, “trawling” for potential respondents.

“Hot .Net Position in Chicago!”

No thanks!

I’ve seen worse though as I’ve even gotten emails that didn’t completely populate the formatting fields in the subject line and emails with bountiful spelling mistakes (what a terrible professional statement that makes).

Perhaps what annoyed me the most is that many recruiters simply didn’t bother to read my resume. In order to cut down on responses from jobs offering salaries below my desired range, I explicitly stated, in bold, the minimum salary and rate I would consider. And yet, I’d still get calls and emails about positions obviously outside of the range. I added a location restriction so that recruiters wouldn’t call me about positions in PA or Chicago or Alaska (yes, I once had a call about a position in Alaska, I shit you not). And yet, I’d still get calls and emails for positions all over the country. I added explicit descriptions of the types of positions that I was interested in. And yet, as my resume would pop up on the keyword ".Net", I was contacted regarding any position that required .Net.

After a while, it was clear that I couldn’t leave my cell phone number in the resume as I was getting calls on client sites even after explicitly stating that the cell phone was for after hours contact only. Beyond that, I finally wised up to the spamming by recruiters that didn’t read my resume by using a “code word” and adding a simple request on the last line of my email: “Please add the text ‘DICEREF’ anywhere in your email message to bypass my spam filter; thank you for taking the time to read my resume!”

In the end, I can’t help but feel like…a piece of meat to these people. The sad thing is that, invariably, someone will respond to these low-lifes, which simply acts to encourage the continued practice of trawling for candidates.

It’s a lose-lose-lose situation for the recruiter, the employer, and the consultant. The recruiter loses potential responses from top candidates by not putting in the effort to sort through the resumes and use more refined searches. The employer obviously loses out because many top candidates simply will not put up with this type of recruiting (I truly believe only desperate developers respond to these emails). And consultants lose out as--who knows--the employer on the other end may be the perfect match.

So what can be done to fix the system? One idea I had early on was to implement a recruiter rating system much like Amazon z-shops and eBay have seller ratings so that potential candidates can see how other candidates were treated and perhaps even create a personal blacklist of recruiters. If you continually get spammed by a particular headhunter, you can enter a negative review and add them to your blacklist. The number of people who blacklisted the recruiters would be visible on the job posting and sortable in a recruiter listing so that candidates could simply find the cream of the crop recruiters and reward them for their practices. Not only that, you would be able to put a threshold where if a recruiter has a certain number of blacklist entries, they won’t even be able to see your profile in searches.

While such a system would invariably cause an initial revenue drop for Dice due to recruiters boycotting them after being blacklisted too many times (good riddance!), I think it would ultimately lead to more quality job posts, more thoughtful recruiters (even if superficially), and happier candidates.  As it is, to me at least, craigslist has become perhaps an even better way to connect directly with employers (it's how I got my job at MediaWhiz).  Dice would be wise to act on this proactively and try to help candidates connect with the quality recruiters out there.

So what do you think? Any stories to share?

Welcome to the inaugural "Developer Life Lessons" post!  Like my DevTools posts, I hope to make these a series which contain little developer life stories, tidbits, and advice (at least whatever I'm qualified to offer).

So what shall our topic be for this first post?  How about the most crucial and perhaps most overlooked (by some) tool of all: the developer workstation.

Lesson 1a: Always have a backup machine.  Hardware fails, catastrophes happen.  Be prepared by having a second dev machine which is fairly capable and has most of the necessary software already installed.  If you need to, take a day to do this on some project down time...most managers will understand and will be supportive as having a backup in place and ready to go with a few updates could be a life saver come crunch time and your workstation refuses to boot.  Of course, this goes hand-in-hand with having a good backup strategy for your code and source control to get your working code onto the new machine (we'll cover this in later editions, I guess).  If you work in a team, you should have at least one backup machine for every 10 team members (random number ).  It just makes sense, you know?

Lesson 1b: Never buy Compaq or HP.  Never.  I would not use their top of the line machines even if they gave them to me for free and paid me to endorse them.  Compaq and HP are truly pieces of turds that should have no place on a developer's desk.  I have never had a single good experience with either brand and refuse to buy anything made by these two terrible hardware manufacturers.  Be it printers, laptops, desktops...whatever, stay away, stay far, far away from these two brands.

As in all cases, a true geek never trusts his/her machine to the unknown by buying a retail PC (different story with laptops as DIY is still not as common and accessible as with the PC market).  A true geek will always hand build his/her primary machine (and of course, use the old machine as the backup (see Lesson 1a)). 

The big benefit of course is that as you pick your own components, you can optimize the pieces for what you plan on doing and you can ensure that every piece is from a known manufacturer with a good warranty.

Indeed, it requires more research, possibly more work, and possibly more money, but in the end, you have a fine tuned tool that you can be proud of, that you know inside and out, and that is far, far better than what you'd otherwise get from a retail PC manufacturer.  With the amount of resources on the web these days on building PCs, it's really quite trivial and I think it's something that everyone should do at least once.

If you absolutely must buy a retail PC, then go with Dell.  Dells suck hard as well, but not nearly as hard as HP/Compaq.  Of course, having the luxury of building your own workstation is not always possible and is in fact quite rare, but if you do have the luxury, dont' settle for a retail PC!

Lesson 1c: When interviewing for new jobs, always make a point to check out the machines and monitors that people are using in the office.  If they're using machines from 2002 with Celerons, 512 MB of RAM, and stuck with Office 2000 and still using CRTs, it's typically a sign that the company is tight with the purse strings.  This can be a good thing in general, but when it comes to development machines, it's always a bad sign as having good workstations (don't even have to be top of the line) shows that the managers understand the needs of the developers and they've invested in making sure that they've done everything they can, from a hardware perspective, to help make the developers as efficient as they can be (who wants to sit through lenghty compiles?).  After all, time is money and slow machines bog down the developer and those seconds and minutes add up over time.