In programming, a little guidance goes a long way

How many times must we reinvent the wheel

When I started out programming, everything was unknown to me. Getting the computer to do anything was exciting. My breadth of knowledge was narrow and the depth was shallow. This meant that each new problem, no matter how trivial, was a monumental undertaking to solve. Building on that issue was the fact that I’d succumbed to a common pitfall of rookie developers, I built everything from scratch using only what I knew.

Fresh out of college I had done little (ok zero) real world programming aside from a summer internship with a bank where I worked some magic with PDFs and JavaScript. I was hungry though, and willing to take on any task. I landed a job heading up IT for an office of around 35 people with a manufacturing plant attached containing another 90 people or so. It was a big deal but I was confident that not only could I run the day to day systems, I could also improve efficiency through software. The problem was, I was on my own without anybody to guide / mentor me.

Novice coders see every problem through a tunnel. You have what you know and you shoehorn those skills into every solution. It’s helpful in your skill development to bang away at a problem using only your wits and whatever help docs you can find but you’ll definitely be spending a lot of time on each problem. Conversely, a good mentor will let you struggle for a while on your own but offer up other avenues you haven’t considered. That type of wider vision is only gained through experience, despite what my younger self adamantly believed. I recall writing these gigantic low level programs to accomplish common tasks like user authentication or email transmission only to later find the same functionality could be accomplished in two or three lines if I just knew which library to use or where to look. I ended up creating some interesting software that improved processes at that company, but thinking back on how I accomplished it makes me cringe.

The urge to roll your own solution is strong in newer developers. They've got great ideas about how to tackle problems. Unfortunately the majority of those ideas end at a brick wall or a flaky system. With the rise of GitHub, it has become easier than ever to research a good solution to your problem before you charge ahead with your first solution. You can see how active the development is on a library, check the star count, and view the code before you commit to it as a starting point. If the problem you’re solving is common, it’s almost a guarantee that it’s already been solved, usually better than you would have done. But it’s still good for new developers to try. You’ll learn a lot about how something works rather than learn how to integrate someone else's code. And every once in a while you’ll get surprised by a new technique that nobody ever thought of before.

After over 10 years of software development including starting several technology related companies, I have a much wider vision. It’s not a matter of knowing more (though you will), it’s a matter of knowing the available approaches and recognizing the wrong ones. Gaining the skill to eliminate the bad paths early on is invaluable. It’s something you’ll never be 100% at but will improve on consistently. It’s what helps you steer teams of young and talented developers whose only shortfall is that they haven’t suffered enough yet to see the landmines coming.

While there is no substitute for trying, failing, and trying again, a friendly guide can help expedite the process. Explaining why a tactic is wrong and the problems it can lead to will give a better understanding. They can also recognize a useful learning experience vs. a futile waste of time and save you there. That person isn't always your boss and they don’t always have more experience than you, sometimes they just have different experience and you can assist each other.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies