Sometimes it’s hard to believe that we were able to create code without the help of Stack Overflow and other programming support forums. I have a personal pet peeve about, what I call, “Frankenstein” code where projects are patched together piecemeal from Stack Overflow comments and forums resulting in a Frankenstein’s monster-style codebase. My coding approach has generally been to try and work out the solution to problems myself. I say “generally” because we all need help from time to time, and there’s no shame in asking for it.
For 2019, my suggestion is to try and work out some coding problems yourself. Trust me, the knowledge will never leave you and you’ll have a lot of fun discovering!
I was reminded of the fun of puzzle-solving by Microsoft’s recent release of the MS-DOS source code on GitHub. I still enjoy coding in x86 assembler (perhaps the strangest use of the word “enjoy” that you’ll ever see!), so I sat down with a cup of tea (and biscuits, of course) and trawled through the different modules of MS-DOS 2.0 – particularly FAT.ASM.
FAT.ASM contains the code for handling File Allocation Tables (FAT for short). File Allocation Tables were how DOS tracked where files were on the disk. There were two copies of FAT on each disk for redundancy, and it came in several different flavours. The one that my first PC used was FAT12. You’ll still come across FAT on USB sticks and some hard drives.
As a teenager, just graduating from machine language programming on the ZX Spectrum, I was fascinated by the how DOS kept track of files – especially large ones that might be non-contiguous which means they’d be broken up into several fragments on the disk. I couldn’t afford a DOS reference book, so I decided to figure it out for myself.
I formatted a 5.25” floppy disk and opened up the FAT in a disk sector editor. When I knew what an empty table looked like, I started adding files to see how it changed – firstly a file that occupied a single cluster, and then larger ones. I corrupted a lot(!) of floppy disks, and documented everything in a notebook (picture attached – forgive my writing, this was 31 years ago!). Most of what I had worked out was correct, but it took me a bit longer – and a lot more trial and error – to understand why DOS would use three bytes to store two entries, and how bad sectors were handled.
The information I gleaned from all of this was invaluable and fun to discover. It helped me when I had to manually rebuild the File Allocation Tables on a corrupted hard drive for a client who was more than a little distressed! He was the accountant for “A Very Well-Known Band”, and the hard drive contained all of their accounts – there was no backup! Using what I’d learned, I also wrote some small assembly language routines to check and rebuild the FAT. Going through the recently released FAT.ASM module, it was gratifying to see that some of my routines for FAT handling were similar.
Since then, I’ve always tried to see if I can work out a coding problem myself first. It is great training for the brain, and can give you valuable insights into every side of a problem. Even if I do use a Stack Overflow solution, I always make sure that I understand exactly how and why it works first.
So, the moral of the story, and the advice that I always give to my students is: it can be fun to find things out for yourself. Take some time, break some code and who knows where the knowledge might take you?
