Way back in the day when lines were first being painted on roads. The early lines were painted by hand. In those days, a painter was hired and given a stretch of road to paint. The first day he got on very well. In fact, he was one of the best line painters they had ever had. His lines were perfectly aligned, there were no unpainted areas in the space where there should be paint, and he managed to get 500 yards of road painted. The average line painter normally did 250 yards in the first day. The managers who had hired him were quite pleased.
Well, the next day, he came to work and set off on his task of painting the road. He still had another 500 yards of road to paint. And yet, for as fast as he was, he was only able to get 350 yards painted that day. Not quite what his managers expected given his performance on the first day. But still, better than their average painter, and so they reasoned to themselves, “Maybe he hit an extra hilly patch of road or some other unforeseen obstacle got in his way.”
Finally, the third day, he came in and finished the patch of road he had been given.
Continue reading “The Parable of The Road Line Painter”
I’ve been asked to train a group of developers in the use of SpecFlow so that they can use it to write Selenium Tests. So, in an attempt to “kill two birds with one stone” I thought today’s post would cover how to get the SpecFlow environment setup. Not only will it help me prepare for the training session I will be leading, but it will help me when I need to set this up the next time because it tends to be a bit confusing when you setup a new project. You’ll see why in a bit.
Continue reading “Setting up SpecFlow”
A long time ago, in a galaxy far far away, we were forced to name variables and methods with very short names. When I started my career, I was programming Clipper and C. Clipper was a dBase compiler, so it only had 10 characters available for variable names. You could write longer variable names if you wanted, but only the first 10 mattered. I think at the time, C gave us 32 characters. But now, we aren’t so limited. And so the argument goes, if you use long variable names, you shouldn’t need to comment your code. I’ve argued as much.
Of course every time you bring this subject up, you will inevitably find someone who will say, “But don’t we need comments to at least explain what the code was supposed to do? After all, code is generally hard to read.” Well, yes I guess it is if you are new to the language. But should every foreign movie have subtitles? Would you want native language movies to have subtitles because other people in the room might not understand it? Must we dumb everything down to the lowest common denominator? If so, where will it stop?
Continue reading “Code Comments & Agile Programming”
Several comments this week contribute to this week’s post.
The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking the Coding Interview” where I made the following statement,
Coding interview? Really? I wouldn’t bother. This is right up there with working 60 hour weeks for me. Yes, I know all the big companies do this, but it doesn’t make it right. “Just because you can, doesn’t mean you should.”
I’ve been programming now for 27 years. I started with DOS 3.1 for anyone who’s trying to figure out when that was.
I’ve NEVER had to do a coding interview and I make really good money so it isn’t that I’m working for minimum wage.
Here’s the deal. I can tell in about 10 minutes if another programmer knows their stuff. I expect that any company worth working for (and yes that includes even Amazon, Google, Microsoft, and the other big boys) should have someone on their staff who can do the same.
Now, if I ever did run into an interview where they wanted me to write code on a whiteboard, I’d probably pseudo code it out and explain that I’m a huge fan of Intellisense, particularly ReSharper, and Google and that I rely heavily on those two to get the syntax right.
If you want a guy who can write code in notepad, I’m probably not the guy you’re looking for. If you want a guy who can solve problems, who understands how to write testable code, write unit test, can mentor younger programmers, understands what it really means to be agile, and can say “no” to power when it is appropriate, then I’m the guy you want.
Continue reading “Cracking the Programmer’s Interview Code”