>The “most advanced” people often use simple solutions indistinguishable from people who don’t know what they are doing. Average people are often in the “knows enough to be dangerous” category by over-thinking and over-working and over-processing everything out of lack of more complete experience to discover simpler and cleaner solutions.
The article was worth reading just for the above gem.
I once had to design an error-message display for an office machine with an 8-line, 40-character wide LCD. Errors could only be shown on the bottom line and if they were more than 40 characters long (I'm looking at you, German language!), they had to scroll.
I spent hours trying to figure out some mathematical calculation that took the screen width and the total length of the error message and how much was off screen, etc., to come up with a good algorithm that worked for all combinations of message lengths. By lunchtime I had something workable, but it was the ugliest code imaginable.
We went to lunch and when I came back, I looked at the machine and the obvious solution came to me: the screen was just a 40-character wide window into the text and all I had to do was pan it over the length of the message. Like barely 3 lines of code to implement.
I try to remember that lesson whenever I find myself spending way too much time on something that sounds like it should be simple!
I'm curious, what was the approach you tried in the morning? Maybe it's a failure of my imagination but I can't think of anything other than the "window" strategy except scrolling word-by-word or something.
It was long enough ago (around 1997 IIRC) that I don't recall the details. I think most of the problem was that I kept running into fencepost errors and finding edge cases around a string being exactly the same size as the window. One of my more embarrassing programming escapades that no one would have ever known about if I wasn't dumb enough to mention it online...
The article was worth reading just for the above gem.