Learning To Program
From time-to-time, I’m asked, ”Greg, what’s a good way to learn how to become a programmer?” To this day, I have a hard time answering that question. I got into programming nearly 20 years ago simply because I was lazy. I was working in a machine shop using AutoCAD and quickly grew tired of dealing with the repetitive nature of some tasks. At the time, AutoCAD had two principal methods for extension - AutoLISP which was a specialized and ADS which was a C variant. Jarb, my colleague and first programming mentor, showed me the basics and I was off and running. It wasn’t long before I realized that I enjoyed programming much more than what I was being paid to do.
So when people ask me what the best way is to learn how to become a programmer is, I frequently respond with, ”Find a problem that nobody has solved yet and go solve it!” Quite often, this results in a slightly puzzled look and a mumbled statement about some book they bought that guaranteed they would learn XYZ.NET in 21 days. Depending on my mood, I’ll try to explain that a solid engineering principal (and one that applies to computer programming) is to only build something because it can’t be bought, but that usually ends the conversation.
The trouble is, people have a tendency to approach programming from a tool-centric point of view. They say things like, ”Greg, I want to learn C#! Where do I start?” or ”Greg, what’s the best way to learn PHP?” If I’m feeling impatient that day and they can’t tell me what problem they want to solve, I’ll probably just say something like, ”Sign up for a class at XYZ. That’ll get you going. Let me know if you get stuck.” and move on. If they do have a problem to solve, often I’ll simply say, ”Why not just download ABC software?” which makes me seem a little thick to some, but the smart ones usually read between the lines.
If you’re one of the people that’s asked me the question and you feel like I’ve blown you off then I will say that I’m sorry. Hell, I’ll even buy you a beer sometime. See, I have no interest in teaching you calculus. However, if you bring me an interesting problem that requires you learn calculus to solve then now we have something! If I need to help you learn calculus along the way then that’s great! If you ask, ”Greg, I want to learn geometry because I need to find the surface area of a cylinder” then you’ll pique my interest, but I’ll probably respond with “2 (pi r 2) + (2 pi r) * h” since the problem has already been solved.
If, on the other hand, you came to me and said, ”Greg, my grandfather really loves geometry. It’s a hobby of his. Unfortunately, his eyesight is failing and he can’t see the screen well enough to use the calculators that are currently available for Windows. I want to learn how to program so that I can write one for him.” well then my friend you will have my undivided attention! We’ll dig in to this problem and I’ll help every step of the way. Not because your goals are somehow noble, but because you’re approaching programming the same way I do… solve what hasn’t been solved and learn what you need to learn in order to solve it along the way.
Alas, there re still those that insist they want to learn how to program and yet have no real problem to solve. Well, in an effort to be a little more helpful, I’ll suggest that if you are a complete novice you might want to check out Small Basic from Microsoft’s DevLabs. Okay, so BASIC isn’t exactly sexy, but you have to start somewhere and Small Basic is designed as a learning tool. Download it, work through the exercises, and we’ll have some foundation to build upon. Good luck and let me know if you get stuck.
Posted on Nov 18 2008 in Programming | Comments (0) | PermalinkThey Call Me KD0FEP
It’s nice to finally get around to doing something you’ve meant to do for a long time. My own recent example is finally obtaining a amateur (HAM) radio ticket and my very own FCC-issued callsign… KD0FEP. Yep, that’s me. For the next 10 years (and longer as long as I renew), I am Kilo Delta Zero Foxtrot Echo Papa. Next, I’ll be upgrading my ticket to work HF and kindly asking the state of Minnesota to issue me a set of amateur radio plates.
CQ CQ CQ DE KD0FEP KD0FEP KD0FEP K
Posted on Sep 16 2008 in General | Comments (0) | PermalinkNotable Quote 4
”Our planet doesn’t seem to be the result of anything very special.”
Posted on Jul 06 2008 in | Comments (0) | PermalinkDesigning For Rewarding Behavior: Part Two
In the first installment of ”Designing For Rewarding Behavior”, I closed with the sentence ”Make it as easy as possible for people to do the right thing.” Another way of stating it is, ”Make the right thing the easiest thing.” The best user interface designers have known this for a very, very long time, but system designers and architects often miss the mark. Top-notch management in the manufacturing industry where cost of motion and safety are paramount leverage that concept to drive their employees to peak efficiency and satisfaction.
As you will recall, we were using time logging as an example. Like I said before, it is a thankless task that we put off until the last minute only to find ourselves scrambling to recall where we spent our time until we finally get frustrated and exclaim to ourselves, ”That is good enough!”, and grab our car keys. It is fairly easy to discern that there are really only three factors influencing our user’s rewarding mechanism. First, users have been told that it’s important to the company because that’s how we make money. That’s the reward of doing what’s best for the company we work for. Second, they’ve have been told, ”Do it or else!” and we know we’ll be in serious trouble with our boss if we don’t get it done. That’s the reward of keeping our job. Finally, we want to finish up and start our precious weekend.
Starting to see the picture? Timely and accurate timesheets are the desired behavior. However, keeping our job and starting our weekend generally carry roughly the same reward index and they both grossly outweigh doing the right thing for the company. This is the fundamental flaw we must correct if we want the desired behavior from the system. If we don’t change the indices then we’ll continue to see the same result which, first-hand experience tells us is timesheets that are usually submitted on time, but are rarely very accurate. Given the value the company places on timely and accurate timesheets, these aren’t acceptable results.
I suspect by now some of you are rolling your eyes and assuming that the rest of this post will be about how we all need to be better corporate citizens. How we really need to buckle down and make those timesheet as accurate as possible and never, ever late. Perhaps you’re thinking that I’m going to offer up some droll, overt reward program that bestows some horrible tchotchke upon those that get their timesheets in on-time every week for some period of time. You know, something right out of, ”8,000,000 Ways To Belittle Reward Your Servants” or some other horrible middle management book. No, the former only serves as fuel to feed the fire that burns in the cynical belly of the typical IT employee. The latter, while popular, would be enough to make Deming puke a rainbow of red and white beads.
Hardcore change agents appreciate the irony that determining how to make the right thing the easy thing is often the hardest thing for us when it comes to effecting truly effective change. The easy thing (which we already know isn’t the right thing because we’ve tried it and it’s not producing the desired behavior) would be to implement that asinine reward program or start walking up and down the halls yelling about how you’ll fire the next person that’s late submitting their timesheet. What I’m suggesting is the hardest thing, but if you’re in a position to influence such things then it’s probably what you’re getting paid to do. You have to step back, define the desired behavior (the “right thing"), look at the holistic system, and effect the changes necessary to make the right thing the easiest thing.
So what’s the tangible product? What’s the answer? Well, if it were that easy then we’d all be doing it. The simple truth is figuring that out is what makes it the hardest thing. In my ongoing, real-world case the first steps are complete; I know the desired behavior and I’ve identified the factors that I believe are influencing the user’s rewarding mechanism. The first and most obvious system change I can make is to introduce any form of user-visible reporting. The existing system is a black hole where timesheet data crosses the event horizon only to occasionally reappear as poorly constructed spreadsheet wielded by an angry manager wondering why a particular project is way over budget. By introducing concise dashboards that borrow heavily from Edward Tufte’s work, we can create the critical feedback loop that directly addresses a user’s typical ”Why bother? Nobody every looks at that stuff anyway.” argument and that’s a start.
The next steps will be to enter into a lightweight variation of the classic Six Sigma DMAIC. My intent is to deliver those humble little dashboard widgets, but this time a principal design goal will be to influence the user’s rewarding mechanism in a way that increases the “because it’s important to the company” index. That won’t be easy, but I believe it is possible and even if my design doesn’t fulfill this particular design goal I will still learn something and deliver a better product.
Posted on Jul 06 2008 in Programming | Comments (0) | PermalinkNotable Quote 3
”It is not necessary to change. Survival is not mandatory.”
Posted on Jul 06 2008 in | Comments (0) | Permalink