Slashdot Mirror
Ask Slashdot: What Do You Wish You'd Known Starting Out As a Programmer?
snydeq writes: Most of us gave little thought to the "career" aspect of programming when starting out, but here we are, battle-hardened by hard-learned lessons, slouching our way through decades at the console, wishing perhaps that we had recognized the long road ahead when we started. What advice might we give to our younger self, or to younger selves coming to programming just now? Andrew C. Oliver offers several insights he gave little thought to when first coding: "Back then, I simply loved to code and could have cared less about my 'career' or about playing well with others. I could have saved myself a ton of trouble if I'd just followed a few simple practices." What are yours?
This Programmer Competency Matrix has been instrumental in helping me "know what I don't know".
Here's my advice, been programming for 15 years. Write comments, one per block of code that does a step, then fill in code. You will then have well commented code, and forced yourself to think through the solution before you begin coding. This saves tons of time by avoiding thought errors before you code. When hunting a bug, don't just look at what's not working. Instead look at what was most recently changed, even if it seems it couldn't possibly be related. The times I didn't do it this way have cost me many days hunting down a really tricky bug. Sometimes it really is unrelated to recent changes, but not often. If you are stuck, take a break and do something mindless, like get some water, go to bathroom etc. your subconscious keeps working without the interference of your conscious mind. Preplan your work a few days ahead if possible. You can avoid many roadblocks by thinking through things ahead of time. Persistence pays off. I've worked through many "seemingly impossible" tasks, only to find the solution after failing a few times first. Visualize what the users interaction will be before coding. I like to draw it on paper and pretend to use it. Putting yourself in your users shoes allows you to see what might be difficult to understand. I rarely keep my first design, but since it's just a drawing I'm not invested in it. If you lay it out in software, it's much more tempting to keep a poor design. Ask a colleague if you are stuck. Often, articulating the problem out loud is sufficient to solve it!
I'm going to answer this in a different way: what I knew when I started that I think most programmers, and most people, don't. That may sound arrogant, but I keep seeing it every day of my working life.
I wasn't a computer science major or anywhere close: I was a film major and English minor. It was the English that has helped me more than anything learn very quickly certain secrets to programming effectively. And yet it wasn't even the English classes themselves, because a lot of what is fashionable to teach in English is misleading or harmful.
What really happened was a certain approach to writing. It is taught clearly in just a few books, like The Elements of Style and On Writing Well. Reading these books literally changed my life. If I were to try to summarize it, it would be that the goal of writing is to reach the reader as plainly as possible, instead of writing in a flowery, fancy, or important-sounding way. To do that actually is the greatest amount of work. It actually is the opposite of everyone's inclination. Even for professional, longtime writers, it doesn't happen on the first draft or even the seventh draft. It involves adhering to certain non-glamorous principles like using as few words as possible and preferring the short word over the long one. It means putting yourself in the background. In short, in trying to be elegant.