Pointer math and date conversions
Like sorting and hash algorithms, all math functions were left up to the developer in an era when CPUs were limited (until the '90s). You might need to emulate 16-bit math instructions on an 8-bit processor. You wrote code to determine if the user's PC had an 8087 math co-processor, which gave a serious performance improvement only if code was explicitly written to exploit it. Sometimes you had to use bit-shifting and lookup tables to "guesstimate" floating-point math and trigonometry routines.
It wasn't just straight-up math, either. Every developer had to do date math (what's "three weeks from today"?) using Julian date conversions, including figuring out when Easter falls and adjusting for leap year. (Not that every developer has figured out leap year even now).
Hungarian notation and other language limitations
Credited to Microsoft's Charles Simonyi, who hailed from Hungary, Hungarian notation is a naming convention that was used primarily by those writing for Windows.
It added a prefix to an identifier name to indicate its functional type. For instance, "pX" indicated that the function was a pointer to X. If you changed the identifier's type, you'd have to rename the variable; that caused some ugly patches.
Although some developers continue to use Hungarian notation today, it's generally unnecessary; most text editors instantly tell you the variable type.
Honorable mention:
- Fortran's formatted input and variable names bound to types (variables beginning with I, J and K were always integers)
- BASIC code requiring line numbers
- Initializing all variables to known values
- Null-terminating C strings
Doing strange things to make code run faster
Throughout programming's (relatively) early history, it was common to rely on undocumented features, such as with the early Windows API. Visual Basic programming required poking at Windows' internals, many of which were undocumented hacks. Naturally, these hacks regularly broke every time Microsoft released a new version of Windows, or sometimes just because of a security patch.
Nowadays, everything is well documented and trustworthy. Yeah. Sure it is.
Honorable mention:
- Writing your own utilities to search for where you'd used functions or procedures and where you'd called them
- Manually optimizing the compiler's generated code to meet a project's performance goals
- Using one-letter variable names in a BASIC interpreter because you could see the increase in execution speed
Being patient
It's hard to explain how slowly programming happened back in the day. You started a compile and went to lunch. When compile time took several hours, you wrote as much code as possible and then dove into a multipart debugging session.
Unfortunately, as most programmers know, the more things you mess with, the harder it is to find the bug causing the problem. Instead of writing and debugging one routine at a time, it took weeks to get the code written and tested.
To speed up development time, programmers would arrive at the office at some ungodly hour in the morning to get dedicated time on the mainframe (if they weren't paying per CPU cycle on a time-sharing system).
The only benefit of the long debug cycles was that it made programmers think about their code rather than slapping it together. And we had time for lunch.