I am going to attempt to put together a series of posts as kind of a Readers Digest version of what’s going on in software development today. A little story about what brought this on:
My buddy is looking for a job. He is a very sharp guy, extremely talented programmer. I’ve worked with him twice and would gladly do it again because he’s exactly what you want in a developer. He’s smart, talented at finding solutions to problems, tenacious, and motivated. He gets excited about code. To me, a guy like that is way more valuable than a coder who does it just because he can earn a paycheck. I want a guy that wants to code because he wants to code. Anyway, the problem is, my buddy is what I will call a “functional programmer” (not to be confused with functional programming). Really good at what he does, but isn’t up on all the “stuff” that a lot of us throw around all the time. You put a problem in front of his face and he solves it. He doesn’t necessarily know what a “design pattern” is, but you might look at his code and see an Observer. He doesn’t necessarily know how to explain abstraction or inheritance, but you see accessor and mutator functions in his objects because he intuitively puts things together that way. He might not understand “refactoring” but will look at some code mess and tweak it in similar ways that you might refactor it.
You get the idea. There’s a lot of these guys out there. I used to be one. I bet you did too. I would put this kind of programmer a step or two above Mort but maybe not necessarily Elvis (I don’t necessarily totally buy the distinctions between Mort, Elvis and Einstein, but they are useful tools, and another part of the lingua franca of software development today). My buddy for instance started as a VB guy, but picks up new languages well. He gets OO, he’s developed quite a taste for Perl, and recently has been picking up C# at a fast pace (which in light of the recent salary survey isn’t a bad thing). What’s missing is the exposure to the lingua franca of software development, and a few bits of information/experiences that move your development up another notch, or help you solve problems that much more efficiently.
I started doing macro development in VBA while I was working the help desk, and I had to learn all this stuff on my own. And to be honest, when I didn’t know some of this stuff by name, or couldn’t verbalize some of the concepts, I felt like less of a programmer…and that’s really not cool. It was only the last few years that I’ve really been up to speed on all the OOP and Design Patterns and other stuff we talk about all the time in the industry, and there’s more to learn and keep up with every day. A couple of years ago I couldn’t begin to pass an interview of the kind that I now give to prospective candidates, and I’m sure I couldn’t have passed an interview for many of you either. It’s hard enough to actually be a good programmer, it’s even tougher to try to go out and learn all this crap on your own, while you are trying to keep up with your daily job…so I want to help in my own little way. So this started as an email I was going to send to my buddy to help him out with some recent interview snafus he’s run into. People like to ask questions about OO and Patterns and other things of that nature and it helps to be armed with the answers. As an aside, I think that type of interviewing is kinda bullshit if that’s all you do, because you will miss out on some talented guys. You can teach the concepts and languages, you can’t teach natural problem solving ability. Yeah it’s important for a developer to talk the talk, but it’s more important that they can walk the walk. My buddy walks the walk for sure, and soon he’s gonna talk the talk. If you need a talented guy in NYC, hit me up and I’ll introduce you to him.
Anyway, about the series, it’s basics. Will be of no interest to a lot of you, though I would appreciate any feedback about where I can improve my explanations. I’m approaching this from a “in my experience” angle rather than a “some book says” angle. I don’t like the book angle. For me, this stuff is great, but if I can’t apply it to my daily job it’s useless. Also, it’s harder to learn in an academic sense, at least for me, than it is if you can put new concepts to work right away. And if this series helps you out at all, if you stumble across it googling for something in preparation for a job interview or just to improve your skills, glad to help.
Tags:
Software Writing OOP Architecture