At a small on site lab, we had a centrifuge that was fitted with a head rated for half the maximum RPM the base unit could deliver. I pointed out that it should probably be hard locked to prevent settings beyond the head rating and even pulled up a manual showing how it could be done. This was left with the lead maintenance technician before I took a much needed holiday.

When I returned, there was a shiny new centrifuge in its place. Apparently, the technician had verified that the centrifuge could indeed be set higher but had then gone off to track down that pesky manual. In the mean time, a sample had been run and the head unit gave way. Fortunately, the shell contained the chunks but it apparently made quite a bang.

In my younger days my employer used a big-ass centrifuge to dry out acetyl salicylic acid in mass.

It had a diameter of 4m, all stainless steel, and was quite heavy.

I would not like to be near that thing should its governor decide to pack up and allow it to overspeed out of control....

... was the one I wrote half a year ago. More or less. It happens less often as I got better. I think it is mostly ok now, except for the bits of code that I know I should have written differently and not under pressure, and I definitely should revise the code rather sooner than later.

Cheer up - even at my advanced age I can still take two days tracking down what I thought was a serial communications synchronisation issue, but turned out to be that I'd forgotten a '\r' on the end of a string...

I used a little USB board that could be hooked up with a PC floppy drive to recover some Amiga formatted disks. These held source code I had written a very long time ago including an unpublished game and a couple of published games that ended up on magazine cover disks.

When I looked at the source I was actually surprised that the code wasn't completely abysmal - it was pretty legible for the most part and I could follow it even though it was invoking Amiga APIs. But I was shocked by how few comments there were in it compared to how many I write now. One of the games had a lot of vector geometry going on in it and it was almost impossible to figure out what was going on without any comments.

almost impossible to figure out what was going on without any comments

One of mine is currently "doing Python" in GCSE Computer Science. I've been impressed with how well it's been picked up, though of course I still get the occasional "hey dad, what have I done wrong here?".

But they haven't been told how (or why) to comment code. Everything written so far is almost completely comment-free. Granted, most of it is self-explanatory at the moment, but a few well-placed comments inserted now would get them into good habits for later methinks.

I have a similar gripe about keyboard skills. Nobody seems to teach "touch typing", despite the fact that most (all?) school leavers will be going in to jobs where typing is a major part of their daily lives. Recipe for RSI, carpal tunnel problems and the like.

M.

That was the problem I had when learning to code. My dad (a university lecturer) taught me first in Pascal, then in C and always expressed the need for comments. As the code I was working on originally was so simple and self-explanatory, plus each exercise was pretty-much standalone, it seemed pointless to me adding comments that explained code which was simple and obvious, and which I had never needed to refer back to so far.

Of course over time, the code steadily becomes more complex as I learnt new commands/functions and more advanced algorithms and techniques. Then we get onto the topic of reusing code when tackling a challenge that is similar to some code I'd written a month or two earlier. Being faced with a fairly complex algorithm and zero comments suddenly made me understand why comments are so useful.

These days I probably end up over-using them if I'm honest, but it doesn't half help when I rip-off some of my old code from previous years.

Then we get onto the topic of reusing code when tackling a challenge that is similar to some code I'd written a month or two earlier. Being faced with a fairly complex algorithm and zero comments suddenly made me understand why comments are so useful. ... Dave K

Would anyone else/many more agree that such is very true here on El Reg which makes the exercising of fairly complex algorithms here invaluable, and indeed much appreciated. It is a service par excellence.

I learned the hard way. Coming from BASIC on a 32K micro, there were no comments as comments took space and execution time.

I started writing C like that.

Until I came back to revise a project several years later and eventually figured that rewriting chunks rather than try to figure out what was actually going on would be a quicker solution.

Gone are the short 1-2 letter variable names, and hello lots of commenting. It'll help down the line, especially if something is being done in an unusual way and you leave a note to explain why.

When I was doing some particularly involved kernel mode code on a VAX, I ended up with approximately a 80x24 screenful of comments per line of code. I also had a preface explaining what the code was meant to do, why a particular approach had been taken, and why other 'obvious' approaches had not been chosen, with links to extensive documentation elsewhere. When you are doing counter-intuitive stuff, you have to work hard to prevent other people making 'obvious' simplifications to improve what 'some idiot' (including previous versions of myself) has written.

There's a very dangerous trait to consider comments a "code smell" and to remove them because "good code should be self-commenting".

I don't hold with that. Good code has good comments, and the comments act as signposts. They're your guides, especially in those fraught times when Something Has Gone Horribly Wrong and you're rooting desperately in code while They Who Must Be Obeyed are standing behind you, tutting, and calculating how much this is costing the company every second it's not working.

Icon because I think we all need it after the PTSD trigger I've just dropped.

When I was coding I often laid out the structure of a function/whatever just in comments, then went back and wrote the code to do what the comments said should be happening. That practice came from writing stuff that interfaced to a number of slightly weird libraries which it was easy to mis-remember parameter order/purpose - coding usually meant frequent reference to API documentation. Unless I laid out the structure in comments first, then by the time I was a few lines in I'd started to lose track of what my actual logic was.

Anything that has nested if-statements gets comments put in from the start, otherwise there's no way I can keep track of those curly braces or indents.

Many is the time I've had a compilation error that's pointed to mis-formed loops, even though code looks OK on visual inspection. Select the offending code, count instances of "{", get a big number. Count instances of "}", get big number minus 1. Put head in hands and weep while mumbling "oh, FFS - not again..."

Why do programming languages always choose between begin/end and {/}. On some keyboards curly braces are more painful than begin/end and I'd like the option to use either please.

As soon as an {} section is more than my (large) screen can display I add a comment at the } to make it clear to which { it belongs to.

if (a -eq b) {

# 80 lines of stuff

} # if (a -eq b)

I'll admit to having been lax in commenting code for a while - only I'm going to read it so there's no need, is there?

Well, yes there is! I've got to understand it if I have to revise it and as I wend my way towards retirement UI have to bear in mind someone else *will* have to support it in the future. Cue a rush of commenting as I migrate code for a new plant.

>"Some idiot," he writes, "had put an add-update where there obviously should have been an add."

... of fixing the problems you cause. And collecting brownie points into the bargain.

While some organisations will instantly sack the individual deemed responsible for such ballsups, there is a better way!

It is said that experience is the lessons learned from mistakes made. So what better way to gain that experience than by making mistakes. Combine with the other cliche of that which does not kill you, makes you stronger and a convincing argument can be made to retain all but the worst problem-makers: the people who always seem to be in the middle of every corporate disaster.

And in this case, had "Francis" been given the heave-ho, what are the chances that the replacement, would not have also spotted the same idiotic add and changed it to the obvious add-update?

You want to keep the ones who learn from their mistakes, but get rid of the ones who don't. If you can find ones who learn from other people's mistakes, hang on to them as long as possible.

And quick thinking enough to blame the previous programmer. "It was like that when I got here!" I wonder what position Francis holds now?

This loop looks fun - do it again!

....This loop looks fun - do it again!

........This loop looks fun - do it again!

............This loop looks fun - do it again!

*** Out of memory ***

Nah! Never happens!

To understand recursion you must first understand recursion!

----------> Mine's the one with the jacket in the pocket of the jacket in the pocket .......

Thanks for the feedback for the feedback for the feedback...

You need to put a stop condition otherwise you get stack overflow eventually!

To understand recursion you must first understand recursion, until you understand recursion!

Always a good idea to have a "brake" clause in a contract when doing upgrades, and force things to slow down, or pause for a couple of hours or days.

Because people will make mistakes when under pressure.

But beancounters don't like this as it'll make projects run over budget.

But mistakes make projects run far more over budget plus the extra costs involved should any specialized knowledge be required to fix things should it be required.

Currently shoveling large piles of stuff on a project which was procured with the exact opposite - a rigidly fixed delivery schedule that just keeps piling on more trouble while we try and recover from the flaws which should have been sorted on day minus one. Just another day in the public sector.

A lot of my code is now open source on github. The horror...

Don't worry, you'll live. And also eventually get over the horror.

Wait until you get hate-email from somebody lambasting code you wrote 40 years prior that hasn't been used for at least thirty years to your knowledge, and only runs on a processor that has been out of support for about as long.

"Never waste a crisis" - Attributed to Bill Clinton, though I suspect that he learned it from others!