The productivity gain that everyone ignores

Posted on December 6th, 2010 in productivity by Jon Kruger

Your team can become much more productive today! And the cost is very small relative to the cost of your developers!

You think that managers would be very interested in this sales pitch, yet almost none of them will buy it.

What am I talking about? Buying your development team new hardware. This especially applies if you’re developing in a language in .NET or Java where you have to compile your project.

I was excited to read this post today because this team gets it. One of their big improvements was to get solid-state drives for their code.

I’m trying to figure out how this doesn’t make sense. If you’re paying your developers $70-90k a year, why wouldn’t you spend a couple hundred dollars for a solid-state drive to help them get things done faster? If your team needs a profiler or ReSharper or some other software package, that request is almost always approved.

Compilation time on big .NET projects (even medium-sized .NET projects) is brutal. It totally slows down your momentum. There really isn’t much else you can do during this time (most developers check email, check Twitter, surf the web, etc.). Wouldn’t you like that to be productive time?

Go faster

Posted on November 10th, 2010 in productivity by Jon Kruger

Go to a software conference near you and you will probably hear talks on new languages, new frameworks, how to design code better, how to test better, and the like. What no one ever seems to talk about is how you can go faster.

We need to get faster at what we do, because it just takes too long. Why do you think companies and managers are always pressuring people to get things done faster? This is a tricky situation though — the challenge is to find ways to get faster without cutting corners, ignoring unit testing, and writing poorly designed code. Anyone can get things done faster by deciding to not write tests or not think about how to design code well, but that’s cheating. That just leads to more bugs and more work down the road.

Don’t ignore the importance of getting things done in a timely manner. I got to be a project manager on a project once, and every day I was looking at our feature wall to see how we were doing and if we were on schedule. I guarantee that your manager or project manager is doing the same thing. That experience and awareness helps keep me from not wasting time adding non-essential features or spending too much time over-analyzing things (be especially careful of this one if you’re pairing). I try to work with a sense of urgency, as if I’m competing with someone else who is trying to complete the same project faster than I can (without cutting corners).

One way to get faster at something is to practice. Find a simple coding problem, like the ones mentioned here. Pick an easy one (nothing with crazy math algorithms, complicated recursion, etc.), or maybe take a complicated one and simplify it. Try and find something that you can do in 15 minutes or less, but still involves writing tests and creating multiple files.

The first time through, go through it like you normally would. Think about design, write good tests, and make sure you understand all the nuances. Then go back and do it again and time yourself. Do it over and over, and try to beat your previous time. At this point, you’ll know how to design the code pretty well, and in order to get faster you’ll have get faster at moving around your IDE, find ways to generate code, or learn new tricks. This is what you’re trying to learn. Remember, you’re not allowed to cut corners! You still have to write tests and write well-designed, readable, clean code. Check your code each time you’re done and make sure you didn’t compromise in these areas.

In sports, there are the teams that are good on paper and there are those who execute during crunch time. You may be good at writing well-designed, well-tested code, but if you can’t get it done on time, no one is going to care. So take time to hone your skills and become a faster developer.

What’s in my AutoHotKey file

Posted on September 7th, 2010 in AutoHotKey, productivity by Jon Kruger

I was asked awhile back to blog about what is in my AutoHotKey script file. If you don’t know what AutoHotKey is, it allows you to remap keys on your keyboard or create macros that are associated with keystrokes or key combinations. So here’s what I got.

#SingleInstance

#SingleInstance says that if I load up my AutoHotKey script and there is already one loaded, then just use the new one without prompting. If you make changes to your script file, you can double click the file to reload it. This way you won’t get annoying prompts when you do so. This has to be the first line in your AHK file if you use it.

SetKeyDelay, -1

By default, AHK puts a slight delay between each keystroke in a macro. I have no idea why you would normally want this, so the above line removes that delay and it will execute the keystrokes as fast as possible.

CapsLock::
Send {End}
return

Remaps Caps Lock to End. The Caps Lock key is in such a prime location in the home row, and you don’t usually need to use it. So I remap it to End, which I use a lot when I want to go to the end of a line of code. This way, I don’t have to take my hands off the home row and stab at the End key (and often miss). This was my first AutoHotKey shortcut and it still my favorite.

+Capslock::Capslock

Shift-Caps Lock will now toggle Caps Lock. Because sometimes you actually do need Caps Lock.

#j::run explorer c:proj

Windows+J opens the folder where I keep all of my code. The “run” keyword allows you execute whatever you want.

!^Up::
Send {Up}{Up}{Up}{Up}{Up}
return
 
!^Down::
Send {Down}{Down}{Down}{Down}{Down}
return
 
!^Left::
Send {Left}{Left}{Left}{Left}{Left}
return
 
!^Right::
Send {Right}{Right}{Right}{Right}{Right}
return

When I hit Ctrl-Alt-arrow key, it will go 5 characters/lines in that direction. This really helps you move around faster in a code file. Ctrl-left arrow or Ctrl-right arrow will go to the beginning/end of the current word, which is nice, but sometimes you want to go to a spot in the middle of a long word, so the Ctrl-arrow doesn’t really help. This is another favorite of mine.

:*:ssf]::
SendEvent select * from `
return

When I type “ssf]”, it will change it to “select * from “. The tick at the end of the second line tells AHK that the space at the end of the line is important and should be included.

:*:ietable]::
SendEvent if exists (select 1 from sysobjects where name = 'TableName' and xtype = 'U'){Enter}  drop table [dbo].[TableName]{Enter}{Backspace}go
return
 
:*:ieview]::
SendEvent if exists (select 1 from sysobjects where name = 'ViewName' and xtype = 'V'){Enter}  drop view [dbo].[ViewName]{Enter}{Backspace}go
return
 
:*:ietrigger]::
SendEvent if exists (select 1 from sysobjects where name = 'TriggerName' and xtype = 'TR'){Enter}  drop trigger dbo.TriggerName{Enter}{Backspace}go
return
 
:*:ieproc]::
SendEvent if exists (select 1 from sysobjects where name = 'ProcName' and xtype = 'P'){Enter}  drop procedure [dbo].[ProcName]{Enter}{Backspace}go
return
 
:*:newproc]::
SendEvent if exists (select 1 from sysobjects where name = 'ProcName' and xtype = 'P'){Enter}  drop procedure [dbo].[ProcName]{Enter}{Backspace}go{Enter}{Enter}create procedure dbo.ProcName{Enter}({Enter}{Enter}){Enter}as{Enter}begin{Enter}{Enter}end{Enter}go{Enter}{Enter}grant execute on dbo.ProcName to EdwardsSteelUser{Enter}go
return

Prints out the following code when I enter “ietable]”:

if exists (select 1 from sysobjects where name = ‘TableName’ and xtype = ‘U’)
drop table [dbo].[TableName]
go

I put this at the top of the file every time I create a new database table. Also included are similar macros for views, triggers, functions, and stored procedures.

:*:se]::
SendEvent ShouldEqual(
return

When I write tests, I’m often writing things like “employee.Name.ShouldEqual(”Jon”);”. When I’m typing this stuff, I can just type “se]” and get “ShouldEqual(”. Sure, Intellisense could do it for me, but AHK is a lot faster than waiting for Intellisense to figure out what I’m doing.

:*:c:|::
SendEvent c:
return

Because I often screw up when typing “c:” and type “c:|” instead. You can do similar things for common misspellings that you often find yourself typing.

I have some other project-specific macros in my AHK file too. If you find yourself typing the same class name, database table name, or anything else over and over, create a macro for it. It’s a small thing but it will help you go a lot faster.

I wanted a way to add stuff to my file quickly because I knew that I would be more likely to do it if it were easier. This led to the AutoHotKeyShortcutAppender, which is a small console app that takes in two arguments: the key combination for a macro and the output. Now I can hit Windows-Q to bring up SlickRun and type “asc scn] SomeClassName” and instantly it adds the macro to the end of my AHK file and reloads it. (If you use the code, you have to edit the app.config file and set the path to your AHK file.)

Have any other AHK favorites? Please post a comment and let me know!

Slides from my Productivity Boosters talk at CONDG

Posted on July 22nd, 2010 in productivity by Jon Kruger

Here are the slides from my Productivity Boosters talk. Some other links you might be interested in:

Create a plan of how you are going to be a productive and effective developer!

Why your company should buy you a new dev machine today

Posted on May 11th, 2010 in productivity by Jon Kruger

When you go to work and write code, you have one main tool that you use - your dev machine. The power of your machine will partially determine how fast you can get things done.

How often does your company buy you a new machine? Every 2 years? Every 3 years?

I don’t know many companies where developers get new machines every 2 years or less. I’m here to show you why waiting longer than this makes no sense.

It makes no sense because hardware is cheap, but developers are expensive. I’m currently on a project where I’m working on dev machines that were purchased in early 2008. I’ve worked on other projects with machines that were 6 months old that were considerably faster.

On my project, it takes about 45 seconds to compile the solution. But what if I could reduce that to 40 seconds per compile by buying a brand new top-of-the-line machine?

Let’s say that I compile every 5 minutes. So in an 8 hour day, I compile 96 times. Each day, I will save 480 seconds, or 8 minutes. If I work 1900 hours in a year (which equates to about 11 months of work days since most people have about one month of work days in PTO), I will save 1900 minutes, or 31.6 hours.

Let’s say that the average developer on your team makes $75,000 a year. If that were the case and you worked 1900 hours, you are making $39.47/hr. This means that if you save 31.6 hours of this developer’s time, you are essentially saving $1250 over the course of the year.

For $1250, I can buy a pretty good dev machine, especially if I don’t buy monitors to go with it and use existing monitors. I think I used pretty conservative numbers here too:

  • I think I could probably cut compile time by more than 5 seconds by replacing a 2-year-old machine with a new one.
  • I probably compile more than every 5 minutes (especially when I’m making failing tests pass or making little changes in the app and running the app to see if it worked).
  • I only looked at compile time — I didn’t look at how long it takes for a machine to run tests, how long it takes to run long-running database queries, or how long it takes for your app to start up.
  • I didn’t account for the productivity hit developers take because they switch their focus on to something else for 45 seconds while they wait for the solution to compile.
  • Some developers make more than $75,000, and if you’re dealing with consultants, you have higher hourly rates.
  • Many developers work more than 1900 hours a year.
  • I didn’t take into account the feeling your developers get when you reward them with shiny new hardware, which will make them feel like you really care about them.

Even with my conservative estimates, I would say it is definitely worth it to buy new machines at least every 2 years. You might even be able to argue that you should buy machines every year. You would have to do the math and see if it’s worth it.

Convincing IT managers to go for this is difficult for some reason, even when you show them the numbers. So many IT managers will tell you that spending is frozen, or that they don’t have money in the budget for hardware, or that it’s not fair to buy the dev team new machines but not buy <insert team that doesn’t really need it> new machines. Are you serious? You would rather have your developers, who are expensive relative to the cost of hardware, have to sit and wait longer for the solution to compile? This is short-sighted thinking. You’re pretty much guaranteed some level of return on that investment within a year.

If you’re going to hold your developers to a high standard, empower them to meet these expectations and make sure that you’re giving them the best tools available.