Practicing What You Preach

Recently I found myself arguing in favor of automated deployments and builds (from both the Database side and the code side).  In of itself, this is not new. I’ve been an advocate for this as long as I can remember.  Before you somehow think me a principled man, remember that I embrace the three virtues of a good programmer:

Laziness – The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.

Impatience – The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.

Hubris – Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

I admit, I’ve strayed from the fold. When I bought my Macbook Pro, my first task was to set up my development environment. Besides the normal pain of having to have Windows 98SE, WinXP, and Win7 discs for this install, I needed to pull down the Source code for my projects and get IIS and SQL Server set up for local development.

Enter: Giant Gaping Flaw In My Plan.

As it turns out, the twiddling I’ve done with local builds to ensure that SQL Server runs (instead of just throwing error 40) doesn’t translate well across dev environments. Neither does the database. My database isn’t in source control.


So this week I’m taking the time to put my database under source control and working on scripting out the settings needed to bring any development environment I’ve built up to speed using Powershell. 

I can hear some of you now, wondering Why the hell is he doing that for his personal projects? The answer is simple. I need to practice what I preach. Yes, it’s overkill, but it’s also beneficial. I can’t tell you how many times I’ve dealt with a new hire who has had to spend time setting up their own development environment.  Doing this will give me the experience necessary to automate that for any future work.  Plus, building ladders is fun.

Downtime: Borderlands

Gaming is my second favorite thing to do with a computer. It’s surprising then that I spend very little time writing about it.

That ends here. Line.

Borderlands has been out for a while now, but I’m just now getting into the meat and potatoes of the game.  Last night a friend and I reached the New Haven Portion of the game — approximately 2/3rds of the way through the game.  At this point I’m confident that I can make a ‘buy’ recommendation for the game. It has Diablo-inspired loot mechanisms, and it provides an avenue for PC players to play cooperatively online, both ‘musts’ in my book.  If you do buy it, do yourself a favor and do all of the side-quests.  Too many times people buy a 40-hour game and finish it in 3 hours.

As they say: Getting there is half the fun.


30 Days of Blogging

. I first started blogging oh so long ago, it was witchcraft. You posted words on the internet, preferably in some sort of form, and people read them. Some people even took to the internet as a sort of public journal. My involvement in this matter continues to be disputed. And I categorically deny (much the same way a guilty politician would) any involvement in “Livejournal” or any of its derivatives. I have standards, you know.

But this post is not about my alleged trangressions against the internet body. 

I come today to celebrate thirty twenty-eight days of blogging.  Indeed, for the entire month of February, I blogged. They weren’t all winners (this isn’t Lake Wobegon), but they are there.

I was apprehensive about blogging for thirty days straight. It’s not as if I haven’t done this before (cf: Livejournal), I just haven’t done it before on anything more than naval-gazing. 

It turns out this fear was unfounded. Blogging and forcing my thoughts onto paper begat more thoughts. I have 10 or so topics that are written down, waiting for pen to be put to paper. 

I didn’t expect that.

It is one thing to blog for thirty days straight, it is wholly another to be enriched for doing so. It’s tempting to throw things up here and see what sticks, it’s far more difficult to prune each post to just the desired length and forcing it to yield just the right statement. 

I guess that’s for the next thirty days.

Mac Impressions: Minute Zero

My Macbook Pro arrived today. 

I got a feeling that tonight’s going to be a good night…

I’m typing this entry out on the new keyboard while Windows 7 is installing on Parallels. 

If other laptop manufacturers could just nail the presentation of the user experience, I submit that they may have a chance once a user opens a Macbook Pro.

Presently, they’re collectively screwed.

I’ve *never* felt good about opening a new laptop or Desktop. Too much packaging, too much cruft. 

With the Macbook, I have a warm fuzzy from minute zero.


Making Change Happen

I generally refrain from pontificating. Unless the day ends in ‘-y’.  Today happens to fall into that category.  Being young and naive of failure brings its own special quirks into my daily routine; mostly having to do with fixing things. Things that make us go. This invariably involves changing the status quo; but unless you’re running on a campaign promise of change, people hate changing the status quo.

I can only assume speechwriters help.  On a more constrained budget, we are left with proving that our change is necessary, proper, and that the i‘s are dotted just so.

Dealing with the devil is also an option.

If you’ve got a change you need to make happen (e.g., automating a manual process like deployment), there’s going to be, let us say, internal inertia against it. .


1. Do nothing. 

2. Adapt, improvise, overcome. : If you can’t make change happen, you can at least try to modify your processes so that they aren’t affected by the roadblock. This requires that you aren’t ‘set in your ways’. I can hear the religious weep.

3. Make change happen. : Don’t wait for it to happen. Don’t wait for someone else to make it happen. Take it upon yourself to make it happen. How?

In a business, it call comes down to two things: 1) Costs. 2) Revenue. Lower the first, improve the second. Any change you make better do one of the two, preferably both.  Need automated deployments and builds? That lowers cost (Developer time = money). Need Unit Tests? That also lowers costs and can potentially increase revenue. 

So long as you think about your change in terms of Costs and Revenue, there’s no reason why you can’t get them enacted.

Delete that Code

When you were making a change recently in code, did you delete the code or comment it out?

The answer, not surprisingly, has a lot to do with what type of place you work in.

Work in a startup? You probably deleted it.

Work in a corporate environment connected to the government? Yea, you commented it out.


The Working Programmer’s library

I like programming books. I daresay I’m obsessed with them. I collect them, they adorn my shelves and workspace as if they were trophies of the knowledge contained within them. The battles they fought are hidden in their dog-earred pages, marred by late nights and tossing them to and fro as I research them, commanding them to reveal their secrets.

On command, they relent to the pressure, spilling their secrets and marching back to my bookshelf, available at my beck and call. They are my fellowship, our common quest is to make me the best programmer I can be. This knowledge takes many forms, but the dead-tree book is the most basic.

It is strange then that I should recommend Safari Books Online. A virtual library available at your fingertips, so long as you are connected to the Internet.  This presents a problem, vis-a-vis being disconnected from the ‘net. Sacriledge, I know. Bear with me.

Safari Books solves the ‘OMG my boss needs me to write code in a language I’ve never seen before’ which usually happens at just the wrong time. I know Perl, but since our build servers don’t have Perl installed (gasp) I’m writing the script in Powershell.  Except that I’ve never written Powershell before.  Enter Safari books. Within minutes I was able to pull down Powershell in Action and Windows Powershell Cookbook immediately. Within ten minutes, I had the script written. 

It’s not the right tool for every job, but Safari Books Online is an indispensible part of your toolkit. Use it.

Attracting Talent – A Response to Eric Lippert

Eric Lippert posted a blog post today about attracting talent. He posed two questions:

(1) When you read a job posting on a career site, what are the things you look for when deciding whether you’re interested or not? Are there “red flags” that immediately make you unlikely to follow up? Are there more subtle indicators that discourage you? What encourages you?

(2) What would you find particularly attractive or unattractive about an opportunity to work on a developer tools team? (at Microsoft or elsewhere, though I am particularly interested in “at Microsoft”.)

I only answered the first question (quite simply, I was too nervous to even consider the second question), but I want to answer both in more detail. I was just nervous because Eric is a Smart Guy™, and people like me simply do not walk up to Smart Guys™ and start chatting as if I’m on his level. I am not. 

Things that Turn Me Off

1. If I get a generic, “We think you’d be a great fit…” I don’t apply. I’ve seen enough of those to know that they haven’t spent more than a few seconds looking at my resume. They saw a keyword and sent it based off of that. Thanks, but no thanks.

2. Trendy words: “Ninja Coder” / “Guru” / “Think outside the Box” .  My mom tries to use ‘cool words’ too. I try to use them with my younger brothers and sisters. It doesn’t work. You don’t know the lingo, you don’t watch the movies. Stop trying. 

3. No, I’m not sending you an updated resume when you send me an email with the words “We think you would be a great fit.” On Linked In or Stack Overflow Careers. In fact, I may just send you an email to gauge your interest. I’m going to ask questions in this email. As the knight said to Indy in The Last Crusade: Choose Wisely.

4. In the interview, Don’t try to stress me out. It’s just going to annoy me. I was in the Army. I trained for battle. I slept very little. I know what stress is. 

Things that Turn Me On

1. Companies that are known for treating Software Developers well. Google, Microsoft, Fog Creek Software, Amazon, SAS. I know that if I worked there, I’d be treated well and be around people that are the best and brightest. Every day would be a challenge for me to outperform the previous day. That turns me on, programmatically speaking.

2. Make me write code in the phone screen. Make me write more code in the interview. Ask me intelligent questions (no, I don’t know how to Move Mount Fiji, but my answer would include hiring foreign cheap labor). 

3. Good processes. I swoon when I see automated builds. If you have a CI build, I’m probably going to get all geeky on you. Unit Tests? I may just ask your CI server out on a date. That’s hot stuff.

4. Being able to make a difference. In Eric’s question, he talks about the Developer Tools team. That’s the team that makes the tools that you and I use to make our software. That’s like being the team behind the team! It’s definitely not headache-inducing crap line of business software. 

Ultimately, just like I said with regards to Amazon: I’d love to work at Microsoft. I’d move across the country to work at Microsoft.