So which developer would you rather be?
The one that writes a line, hits run, tests / fixes it, repeats.
Or, the developer that writes everything in one go and then hits run once?
The first one relies upon fast compile times… The second one relies upon understanding and planning your code and not just hacking. I know which one I’d rather be. Would you turn off that turbo button to make your compiles so slow that you actually then start thinking about what your writing rather than hacking?
Robin
I’ve never need fast compile times. Like Robin mentions above, I’m one of those programmers that writes 90% of what is needed up front with very few bugs. I’m not like those programmers that rely on constant iterations to get things right.
Those kinds of programmers really bother me. They really don’t know what they are doing and are likely just shooting from the hip most of the time. The ones I’ve known in the past that worked like that were the worst programmers I’d ever worked with.
I entirely agree with Robin and Matt. I code to the next milestone, test, and may or may not encounter a bug to fix.
Merry Christmas Jeff. Keep up the great writing.
Funny you mentioned this. We do development at my work using Eclipse and Java, and we all had PCs running Windows on our desktops. That meant it took Eclipse two or three minutes to open, and about 15 minutes to open our Subversion repository.
I installed Ubuntu and VirtualBox to run Windows under Linux in case I needed access to some Windows only piece of software. I am using Evolution for access to our Exchange Server and Open Office. Now, Eclipse opens in a few seconds and I can download the repository in under 2 minutes.
Heck, I think even Windows runs faster under VirtualBox under Linux than when it was directly on the box. It’s like pushing the ol’ Turbo button (or is it taking the PC out of Turbo mode?).
So far, I haven’t had much of a need to use my Windows install. I suspect that the other developers will soon also want to switch to Linux desktops too.
There’s no appreciable difference between running Wordstar on my old 2 MHz Z80 and running any other text editor on my new G5. Maybe I should type faster…
Those were the days!
Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand…
… write good code, no matter how slow their tools go.
Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand…
I agree.
Fast tools allow more bad code to get developers by sloppy programmers. So instead of getting frustrated and choosing another profession, they stick with it and give us all headaches.
I had to work with one imbecile that actually somehow convinced management to tell the other developers not to bother him with details like the fact that his code didn’t compile or work - he had a deadline, goddamnit and he had to get it done.
There is some asymptotic limit to how fast good developers can code and the responsiveness of a keyboard input buffer or the compiler is far in front of that limit.
One of my programs displays a line of progress *'s across the screen as it does lengthy recalculations. After the last *, they get cleared away. Over the years, I improved the algorithm and machines got faster.
One year a user complained that the recalculation function was not working, since she did not see the progress bar.
I asked her to hold down the recalculate key. It turned out that what had once taken about 40 seconds was now taking less than .1 second. Once she held down the recalculate key, she could see the progress bar flicker as it recalculated everything at the keyboard character repetition rate.
I then changed the program to display a calculation complete message instead of proogress *'s.
I saw an article that compared the performance of a 1986 Mac and a 2007 PC
Perhaps this one?
http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
many times it allows weak minds and weak developers to compile and check in bad code without understanding anything they were doing
Bad programmers will write bad code, no matter how fast their tools go. Good programmers, on the other hand…
Tim, see this:
http://www.codinghorror.com/blog/archives/000427.html
–
So let’s get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code. RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.
So let’s get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code. RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.
Jeff Atwood on December 26, 2008 01:22 AM
I tend to agree, yet … this ain’t nothing to do with hardware performance.
The turbo button got really useless in later years when it continued to, in every PC I saw, halve the clock speed. Halving the speed made sense when the turbo button was introduced on PCs that ran twice as fast as the original. Now when you had a PC running 40 times as fast as the original, cutting the speed down to 20 times as fast didn’t really buy you anything.
At that point it was just an annoying button that did nothing good and would occasionally get pressed (by mistake or by some joker) and cut your speed in half. What a horrible feature, and what an example of inertia compromising future designs.
That’s so funny you posted this. I asked the same question on StackOverflow.com if anyone else misses the Turbo Button. After 3 negative votes on the question I eventually deleted it. There must have been a Turbo Vibe in the wind recently.
The turbo button came in handy talking to POS systems. The poor old registers couldn’t keep up duing com’s. Indeed so much so we had a combination of the turbo button set to off and software written to slow down coms.
I had a constant argument with a friend of mine back in college in the late 80’s. He insisted on running his computer with the Turbo button in the off position. First thing I would do when I used it was to turn it back on and he would freak out! He feared running it on Turbo would burn out the processor somehow. Nothing I said ever changed his mind.
What a bunch of geeks!
What’s keeping you from going as fast as you can?
It is this attitude that keeps many developers from writing fast applications:
http://www.codinghorror.com/blog/archives/001198.html (Hardware is Cheap, Programmers are Expensive)
Why trying to optimize, when users can optimize by buying a faster HW?
Turbo Pascal 6 (and perhaps previous versions? I believe they stopped supporting it in version 7, which was renamed Borland Pascal) had a pretty cool feature when compiling: it could build directly to RAM, bypassing the harddisk. When developing on 286 machines with painfully slow drives, this sped up the develop/test cycle tremendously.
Of course the code generation sucked (which is typical of Borland), and even in the later 486 days you often needed to code routines in assembly to make things run fast enough.