Want to hear about some of the dumbest technical mistakes I’ve ever made?
Way back in ancient days — in the last century and before Stack Overflow — the knowledge about how to get things done was a lot less concentrated and centralized online than it is today. Between that, and my own inexperience at the time, I sometimes got myself into trouble.
Here are a couple of examples of the silliest technical mistakes I’ve made.
Trying to Force my Linux Kernel to Talk Full-Duplex
When I first put together my home network, I used inexpensive commodity hardware. My local big-box computer retailer had Linksys brand ethernet cards, so that’s what I used. They worked pretty well and used the well-supported “Tulip” driver.
And, well… the card’s box said in big letters how its maximum possible speed was 200mbps in full-duplex mode. That sounded cool, and that was what I wanted! But no matter what I did, I couldn’t get it to work: the driver’s output said it was only running half-duplex mode. What the heck?!
So I did what any aspiring and ignorant young developer would do: I edited the tulip.c network driver source code and tried to hardcode the full_duplex flag to 1. It didn’t work.
Eventually, I did trip over the answer: I just didn’t have the hardware to do full-duplex communication: you need a network switch instead of a hub. I also doubt I’d have managed to make the right change to force the flag, but that doesn’t change the fundamental misunderstanding that, without the right hardware, it was never going to work.
Writing a Shell-script to Checkout a CVS Repo… Every Time
Another time I wanted to use the latest version of some software package. I don’t recall what it was specifically. It was probably something frivolous like an early version of a prettier window manager.
But regardless of what the package was, I wanted the latest. And that meant downloading the latest from source control, instead of an officially-released tarball. For most projects at the time, the source control tool was CVS (SVN had either not come out then or had been brand new. And Git was years off still.)
Therefore source control was new to me at the time. I was still doing manual source control ala `cp file1.cpp file2.cpp` for my own projects. And this whole CVS thing seemed like a pain (all those commands!). But I needed the latest! The project had listed the commands I needed on their website, and so I copied them… Then I pasted them into a shell script to checkout the repository.
I ended up automated deleting the old repo before recloning it: The script would do the full clone every time because I had no idea what all those other CVS subcommands were intended to accomplish. And on my 1990s-era-ISP, it took a long time to download!
Common Thread: Avoiding These Sorts of Mistakes
With my network driver updates, before investing in time-consuming technical work, I should’ve asked, “What kind of hardware goes in a home network?” and “Does anyone have two computers talking to each other that can demonstrate these promised speeds?” Those questions could have helped me identify the root cause faster.
For my misunderstanding about CVS, I feel that the sheer number of commands (checkout, update, commit, etc) should have been a clue: they’re there for a reason. Seeing the volume of complexity should’ve made it clear that CVS is trying to provide more functionality than I’m using.
The common thread with these examples isn’t just that what I did was silly. It’s that I had to do some fairly serious technical work to accomplish the wrong thing. This is what people mean when they talk about a level of skill that’s “just enough to be dangerous.” As we develop those skills, it becomes possible to go so far in the wrong direction that we can damage our projects.
What I try to do to prevent this is to check my understanding with questions like, “What are the servers/hardware/libraries involved?” and “What is this broadly supposed to accomplish?” I try to find working examples or descriptions of such in documentation — then you have something to compare.
Go ahead and experiment! It’s a great learning experience (at the very least!) to try ambitious automation or crazy shot-in-the-dark potential solutions. Just be mindful of how far you go down that path before you check that you’re solving the right problem or using the right tools.