Friday, August 7, 2015

All good programmers are lazy


I'm going to let you in on a secret: good programmers are lazy.  You want them to be lazy.  Don't hire a programmer that isn't lazy!  Everything I've learned about making programs better is about being a more lazy developer.

Variable and function names

float bob(float bob1) {
const float bob2 = 1209381902312;
float bob3 = bob1 * bob2;
return bob3;
}
float bobble = bob(98123);
If you see this function call, it's immediately obvious what it's doing...no wait, it really isn't.  You see it and have to go find the definition, read through it, and try to make sense out of it.  This is why you use descriptive names for everything: to be lazy.
float createPrivateKey(float seed) {
const float secretMultiplier = 1209381902312;
float ret = seed*secretMultiplier;
return ret;
}
float privateKey = createPrivateKey(98123);

Comments

Comments in code exist to let you be lazy.  You don't want to have to read through code every time you call a function.  If the name isn't descriptive enough add a comment.  If there's a block of tricky code add a comment.  Read a simple complete sentence instead of dozens of lines of code.

Code Reuse

You find yourself typing the same code more than once?  Why are you doing that?  You are supposed to be a lazy programmer!  Wrap that code in one place and call it wherever you need it.  Then for bonus laziness you can fix any bugs in one place and not 400.

Interfaces

The project spec changed and now you are using OpenGL instead of DirectX?  Time to change every file in the project.  It changed again and now you are using DirectX?  Go back and change every file in the project.

If you were a good lazy programmer you'd have an interface in place already.  Switching between the two should involve changing one line of code.

Spaghetti Code

You have a 10,000 line function and have to make a change in it.  Enjoy spending the next 3 hours reading through it all.  The lazy programmer next to you has their code broken into functions that do one thing each and can easily find the place to change.

Source Control

SVN and Git were invented to let you be lazy.  Make a bunch of changes and suddenly nothing works?  If you have no backups you could spend months trying to get back into a working state, or you could revert.  A bug showed up last Thursday?  You could look at the whole program, or you could look at the SVN logs to see what changed that day.

Asserts

A function can't be called with a value less than 0?  Make the function argument an unsigned int.  It can't be called with a value less than 10?  Add an assert!  If possible add a compile-time assert.  Now you don't have to spend hours debugging a crash because you passed an invalid argument.

Unit Tests

Unit tests exist to allow you to be lazy.  Does your change break the math library?  You could spend your time trying to make sure everything works, or you could hit compile and let the unit tests tell you what is broken.

Continuous Builds and Integration

You just made a bunch of changes and checked in.  Did you break anyone else?  Did you drive home and get a phone call that you broke it and have to drive back?  Also, your whole team wants to be lazy with you.  They do a get and find that they can't compile and have to go around and find who can fix it?  This is why continuous builds were invented.  Check in and wait for the green light.

Conclusion

Always ask how lazy you can be when programming.  Are you adding work down the line when a bug shows up or the project specification changes?  Are you adding work now that won't pay off later?  More importantly are you adding work for other lazy programmers to have to deal with?

Calling someone a hard working programmer is almost an insult.  No one with a clue is impressed by a programmer who works 14 hours a day accomplishing what a lazy programmer could do in 2 hours.


No comments:

Post a Comment