<CharlieDigital/> Programming, Politics, and uhh…pineapples

9Aug/06Off

Developer Life Lessons: #001

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 :-D).  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.

Posted by Charles Chen

Filed under: DevLife Comments Off
Comments (0) Trackbacks (0)

Sorry, the comment form is closed at this time.

Trackbacks are disabled.