June 29, 2007

That's not how it's done

Growing up as an aspiring guitarist I used to take my acoustic to school and play on the lawn during lunches. It was fun. I always enjoyed playing. Trying to tackle new riffs or old ones, it kept me busy. Sometimes the funnest thing to do was take a song I'd been hearing a lot of and make my guitar play the same notes. Of course there were always tabs which were a very easy way to learn any song. But sometimes it was more interesting to work it out just by ear.

One song I learned by ear was a popular one from the Goo Goo Dolls. When I was playing it at school one day a friend stopped me mid-intro and said.... "That's not how it's done." I stared for a second and asked what he meant. He informed me that he had the sheet music from that album and the way I was playing wasn't the way that was written in the book. I asked the rest of the group what song I had just been playing and they all agreed it was the song in question that was coming from my guitar, but my friend wasn't interested in what it "sounded like", he was learning to play based on the exact way the artists themselves played. Forget music theory or the fact that there are multiple variations of the same notes/chords across the fretboard of a guitar (same as any other instrument). He wasn't really interested in understanding music or the instrument, he was only interested in understanding the way the artist played it.

Exit the world of rock guitars and enter the world I'm currently in: software programming.

Many coders don't have a grasp on what it is that a programmer does. The funny thing about that is that in many businesses the 2 types are paid pretty much the same compensation. For the coder it's only relevant to know that a piece of code is written in comparison to any other code they can find to copy from. Their only true requirement is that it meets user requirements. A programmer is more of an engineer. It's not good enough to just borrow code that meets requirements. The programmer has to know more. Why does the code do what it does? How does it work? Can it be made better?

Oh yes, the coder will take pride in the claim that they know the business requirements but they can't explain why they can't deliver successful products in a timely manner with quality rock solid code. By knowing the business requirements the coder can easily find other code that meets those requirements and voila they've written a program by use of a few right clicks of their mouse.

What does it take to separate yourself from these copy/pasters? For one, have a growing knowledge of your tools. By tools I mean the platform you're developing for, the language you're using (including libraries and the way the language works with the machine), and even the IDE you'll be using (i.e. Eclipse). If you're going to work in this industry you have to be a nerd and that's not as bad as it seemed when you were in high school. Now that we're in the real world a really good nerd can bring home a way better bottom line than the most popular jock in your high school (who's most likely working in a local factory pulling in just over min. wage or working at his uncle's auto dealership). So don't worry, be a little nerdy. Spend some time reading technical books and articles that help you immerse yourself in your craft (although don't forget to take the time to do other things you enjoy, like spending time with family and friends, because nerds do have friends here in the real world).

end of rant
Until next time
Les

3 comments:

Erik said...

I think it's more fundamental than knowing your tools and understanding how your platform and OS work together. The main thing that separates real programmers from people who can program is programming deliberately instead of programming by coincidence (thank you pragmatic programmer). When you truly understand what your code does and what the code you're calling does and you can say with certainty what your program will do before you hit the big green button then you are a real programmer. I know we all have moments where it's alter a tiny bit of code, save, run, rinse, repeat, but the awesome programmers don't need an IDE or even a compiler. They could write their program on paper and have a monkey type it, compile it, and run it and it would perform exactly as they knew it would.

I hope I'm that good some day.

Les said...

Ah yes, the IDE debacle. My main reason for mentioning it was that so many people in our industry use a robust IDE and think they know what they are doing and think they know what their IDE is doing for them. This is a problem in so many areas. It's like learning to play a song before you actually learn what it is behind the song. Sure you can learn/memorize what strings to hold and what chords to strum, but you don't know what the music is doing and so can't replicate it on your own.

Every Eclipse using Java programmer should be required to write and execute a Java program in a text editor and on the command prompt.

thanks for the input Erik, and yes, we all want to be that good someday...

:-)

Jason said...

Good stuff Les. I agree with all of your points, but I'm starting to think at the core of a good programmer is a fundamental way they think. It's not only mastering language, IDEs, OS's, tools, etc. I would take a rookie "programmer" type over a 25 year seasoned "coder" any day, ANY DAY! Because like you said the programmer wants to understand, not just copy/paste or follow instructions taped on their cube wall. So a programmer that doesn't know anything about a given library won't throw up hands and say "I don't know library" they will say "I'm confident in my ability to dig and understand". Basically I'm saying noone is going to fully MASTER all of the tools, libraries, etc. that we see in our profession everyday, so what the programmer gives you is the ability to have different things thrown at them and have the ability to process and solve. I think it's often overlooked... so much emphasis in interviews is "explain keyword final" "what does private mean" "can you invoke a private method using reflection" BLAH, who cares. Can I give you a stack trace and you go figure it out? That's the secret sauce of a true programmer.