Sick of the lack of posts? Bored with some of the most “recent” ones? Yeah, me too. I’ve had a lot of people (okay, a few friends) ask me why I haven’t been updating lately. I’ve got an answer for that. If you thought some of the posts I made were rather boring, I might have an response for that, too.

A Problem of Motivation

Believe it or not, lack of material hasn’t been a problem. Lack of material I care about has been a problem. I’ve got twenty-some-odd drafts in various states of completion, and dozens more topic ideas written in a notebook. But I just don’t care enough about most of the topics to finish them, so I haven’t, and I won’t.

When I first started this site, I thought I would enjoy writing about personal development and especially personal finance. It turns out that I don’t. There are some personal development and finance topics that I have enjoyed (and will enjoy) writing about, but for the most part, I don’t have the dedication and desire to write about this stuff regularly. And that comes through in the writing. My posts about goals and finance and such haven’t been nearly as well received as my more off-the-cuff posts about programming, or resume tips, or even the secret. The truth is that posts that I wrote to be interesting were just boring. The posts I wrote because I was interested were fun.

Lack of Time

I frankly haven’t had a lot of time to dedicate to this site. Each post I put up takes three hours, minimum, and many of them take considerably longer. Maybe that means I’m a slow writer. Either way, it’s just too much time to put into posts I don’t care about.

I’m working a full-time job, and I’ve been enrolled in graduate classes constantly since I started this site. Those take priority over this site, and always will.

My girlfriend (now fiancée) has been living about seven hours away for the past year, which means I spend quite a few of my weekends traveling to see her. Other weekends are spent when she comes to see me. I also spend a decent bit of time on the phone through the week. This is not the primary reason I stopped posting, but it has contributed. My fiancée takes priority above this site. Way, way above this site.

I’m not looking to excuse the fact that I haven’t been posting. I’m just saying this is how it is.

What the Future Holds

So, we’ve established that I have neither the motivation nor the time to post here frequently. What does that mean for the future of this site? For starters, I’m only writing about things I’m interested in from now on. No more posts that I write just because I think others might be interested. I write for me. If others like it, great. If not, great.

When will I write? Who knows. Maybe once every week or two. Maybe never. I’m not going to make any promises about posting. Every time I see someone do that, they make themselves into liars by disappearing again. I’m not doing that. Without promising anything, I will say that my plan is to post occasionally, a couple of times per month, at most. So if you check in once in a while, you might might find some new posts. If we’re both lucky, they might even be interesting.

September 20th, 2007

What do you really want to accomplish in the next month, the next year, the next decade? Is your career on track? Are your relationships developing correctly? Do you really even know?

The Yardstick

We cannot measure our success without knowing what success will look like. Our goals should be the yardsticks for our lives. If we are meeting our goals, then we are successful. If we are not, then we need to adjust either our goals or our efforts. Do you know what your goals are?

You might want a million dollars, but that’s not good enough. That’s not a goal. It’s a dream. You can’t act on a dream. Do you want to save a million dollars for retirement? If so, then maybe your goal should be to “invest $250 in a mutual fund every month for the next 40 years.” That’s a goal you can act on. You are much more likely to invest $250 than you are to just “save a million dollars.”

Let’s look at another common example. If you want to get in shape, then “eating better” and “going to the gym regularly” should not be your goals. Even “lose ten pounds” shouldn’t be your goal. Those are all just too intangible to reliably act upon. Your goals should be to “eat no more than 1500 calories per day,” and to “go the gym from 6:00 to 7:00 on Tuesdays, Thursdays, and Saturdays.” Anything less than that isn’t a real goal. It’s just a dream.

Toward a Goal

Once you’ve made your goals into something tangible, something measurable, you can monitor your progress. Did you save $250 last month? If not, you need to adjust your budget and compensate. Did you go to the gym last Tuesday? No? Then you need to make the time.

By setting a measurable goal, you can constantly evaluate whether you’re going to reach that goal. If your dream is to spend more time with your kids, you can’t really track that. How much is enough more? If you want to spend 2 hours every weeknight helping your children with their homework and then going for a walk as a family, that’s something you can track. You can try to track your success in your head, or you can actually keep a personal log. Either way, the first step is to make the goal measurable.

I want to finish all of my degree, except for my dissertation, by the end of next spring. That’s not very tangible, though. So instead, my goals are to take my comprehensive exams and finish 12 hours of class this fall, and to take 6 hours of class and propose my dissertation in the spring. These are by no means easy goals (I have a full-time, off-campus job), but they are measurable goals. I know exactly what I need to do, and I know exactly when I need to do it. I can and do track how my school goals are progressing.

Once your goals are measurable, you can make progress. Until then, you’re just frustrating yourself with dreams that won’t come true.

Big Goals

Sometimes a goal might just be too big to really be tangible. If that’s the case, you need to break it into smaller goals. For example, starting your own company is a huge goal. It’s definitely possible, because others have done it. But “start a company” just doesn’t seam tangible, or very measurable, for that matter. You’ve got to somehow break it up into achievable pieces.

If you want to start a software company, you should probably have a goal of spending several hours a day putting together a prototype product. After that, maybe you need to find a partner or an investor. So you should have a goal of spending some amount of time finding a partner. Or a goal of hitting up everyone you know with more than $5 for investment money. At every step of the way, there should be tangible goals. Even if they aren’t all obvious from the beginning, you should be nailing them down as you go along.

Meeting goals can be hard. It can be very hard work. But the first step is to really know what the goals are. Setting goals is not an extremely difficult thing to do. It takes some time, a little personal honesty, and probably a pen and paper. Whatever time and effort you put into setting your goals will pay itself back many times over, when you actually meet your goals. Once you’ve actually set real goals, you’ll know what you want, you’ll know what you need to do to get it, and you’ll know how to track your progress.

People waste their entire lives dreaming and never doing. All the hoping in the world won’t turn a single dream into reality. But hard work can turn goals into reality. Don’t sell yourself short.

How rapidly does programming knowledge really become out-of-date? Do things change so frequently that it has become unreasonable to expect programmers to keep up with the pace of technology? I’m not so sure the pace is really that fast.

A few days ago, Half Sigma posted an article claiming that a career in programming sucks. I responded that no, it doesn’t. In turn, I got quite a few comments supporting Sigma. Several of them were centered around Sigma’s first argument, that programming knowledge becomes obsolete too quickly.

Rapid Obsoletion of Programming Knowledge

In an attempt to prove that programming knowledge has a very short expiration date, it’s easy — and common — to drag out an expired technology (Punchcards, Z80, Turbo Pascal, etc.) and then point at it and say, “Look! Look! How does any of that still apply?”

Quite frankly, if you have to drag out punch cards to make your point, you don’t have one. Punch cards died 30 years ago. If that’s the best you can do, the computer science field must not be moving very quickly at all. The Z80 died in the mid-1980s. Even Turbo Pascal was gone before Windows 95 hit the streets. Each of those technologies had more than a 10-year lifespan before it became obsolete. Is it so unreasonable to tell programmers that they need to learn a new technology at least once every ten years?

Hey, remember when plumbers used to use lead-based solder? Plumbing knowledge is obsoleted so fast!

Just like the basics of soldering are partially independent of any specific solder compound, so are the basics of computer science separate from any specific technology. Punch cards are just a storage medium, like hard disks, so much of the knowledge gained during the punch card era is still relevant. Similarly, a programmer who has good knowledge of the Z80 should be able to map much of his knowledge to modern processors. And a skilled programmer who used Turbo Pascal should still be a skilled programmer in a new language, given a brief acclimation period.

If tomorrow morning we all switch to PowerPC computers, programmed in Python, using some funky crystal matrix for storage, my knowledge will not all be obsolete. Certainly, my knowledge of the more quirky aspects of C++ won’t be useful anymore, but the basics won’t have changed. It’s still a Von Neumann machine. Algorithms are still important. Software design practices are still relevant.

Nothing fundamental really changes very quickly. The superficial stuff evolves rapidly, but if your knowledge is only superficial, that’s a different problem altogether.

The Example Game, from the Other Side

If we want to play the “look at this example” game, I’ll just trot out C and the x86 architecture. Both of those have been around for more than 30 years, and they’re both still going strong. They’ve been around since before I was born, and I still use both every day at work. Likewise, C++ and IPv4 have both been around for more than 20 years, and show no sign of dying soon. Even Java and PostgreSQL have been around for 10 years now.

There are many examples of technologies that have been around for more than a decade. In fact, I challenge anyone to demonstrate a dead technology that was once popular and considered important, which didn’t last for at least ten years. I doubt there are very many examples. I think there’s a minimum lifespan before anything can really even be considered important, if for no other reason than it takes a while before a given technology becomes well-developed enough to be utilized by business.

Knowledge Carry-Over

Even when particular technologies die, they still influence future technologies, and so the knowledge base doesn’t disappear or become useless.

Pick any current technology, and you can trace its roots back toward previous technologies. C# was influenced by Java. Python was influenced by Lisp. Ruby was influenced by Python, Smalltalk, and Perl.

Knowledge of any predecessor technology will spill over to the newer technology. Certainly, not everything remains relevant, but there’s definitely some knowledge carry-over. If you’re skilled with Java, C# is not a huge leap. Things are different, but not completely alien. If you’re comfortable with functional and object-oriented programming, you can pick up Ruby.

What Do Employers Want?

Some commenters argued that employers will only hire programmers who are already skilled in the latest technologies. I agree that’s true for some employers. However, I’d argue that it’s not true for most, shouldn’t be true for any, and won’t be true for the employers good programmers should want to work for.

Would I hire an experienced Clipper/dBASE programmer for work on an Oracle project? Yes. Would I hire a good C++ programmer to work on a C# project? Yes.

Good people are far more valuable than specific knowledge. Any decent programmer can learn the syntax and APIs. If you have demonstrated a strong knowledge of database programming, why wouldn’t your knowledge carry over to Oracle? If you are a good C++ programmer, why wouldn’t you be a good C# programmer? If you cannot move from one language to another, then your knowledge is purely superficial, and you are not a good programmer.

If a potential employer cannot recognize that a good programmer is much more valuable than a mediocre programmer “skilled” in the latest buzzwords, then you don’t want to work there. You will almost certainly not be treated well, because the employer clearly doesn’t understand the value of a good programmer.

If your boss doesn’t want you to learn new technologies, then you’ve got a bad boss. Your boss should want, and expect, you to be constantly learning. What kind of idiot thinks that he’s hiring programmers with all the knowledge they’ll ever need?

Technology Changes

You people complaining about the obsoletion of knowledge sound like luddites. It frankly sounds like you’re afraid of progress, and unwilling to learn new technologies. You picked a fast-moving field. Accept that some of your specific knowledge will be subject to attrition. Knowing, for example, a particular object-oriented language’s syntax is transient knowledge. Understanding how to program using good object-oriented methodologies is not transient.

Expect to learn new technologies. It’s part of the field. Learn them at work, or learn them on your own time. But don’t complain to me that your knowledge of Clipper isn’t useful anymore because the world now uses Oracle. If you didn’t learn anything useful while you were using Clipper that would be applicable to Oracle, then you probably didn’t do anything useful while working with Clipper.

Now, I’m not going to pretend that the computer science field doesn’t have any problems. Certainly it has problems. Life has problems. That’s just the way things are. But pretending that the problems are insurmountable doesn’t help anything. Pretending that technology evolves so fast that no one could possibly keep up long term is just a way of hiding the fact that you aren’t interested in keeping up.

If you want to switch fields because you can’t or won’t keep up with the pace of technology, please do so. If you find something you love, then that’s far better than doing something you don’t care about. And if you find a field where you knowledge base never needs to evolve, let me know. I’ll be sure to pass the news on to others who don’t want to program anymore. I have to say though, I can’t think of a faster way to obsolete all your knowledge than by switching to a different field.

This is a response to the author of Half Sigma, who wrote a post about why a career in computer programming sucks. This topic could be considered slightly off-topic for this blog, but I’m a programmer, so I feel it’s career-related enough that it falls slightly into the realm of this blog. Besides, I want to respond.

Sigma (as I’ll refer to you throughout this post), you are way off. I’m afraid that your arguments are weak and poorly formed. You’ve made erroneous and biased assertions and based your arguments on those false premises. You clearly don’t like being a programmer, but your personal dislike for the job (or the field) doesn’t make it bad. It just makes it a bad fit for you.

I’m going to address your arguments point-by-point, so readers can more easily refer back to your post for context.

  • Temporary nature of knowledge capital

    You argued that because so much of the everyday knowledge in programming is transitory, there’s basically no benefit to hiring an experienced programmer over an unexperienced one (or a programmer with relatively little experience). It’s true that Cobol is effectively dead, and “Significant Cobol Experience” isn’t exactly the best way to headline a resume these days. It’s not true, however, that experience is worthless. The transient parts of programming change: the languages, the tools. But much of programming does not change. Good software engineering practices and concerns have not changed: Encapsulation, clarity, patterns, security, stability. These are all as important today as when they were first conceived.

    The fundamentals do not change. A linked list is still a linked list. Binary searches and hash maps are still faster than linear searches on large data sets. If an experienced programmer can write the code for a linked list, or understand when a linear search is bad (or — gasp — when it’s good), then he’s definitely got something to offer beyond the average recent graduate (who sadly, doesn’t understand pointers or Big-O notation).

    There’s even a great deal of technology retention from the “transient” aspects of programming. I still use Make at work, and it’s been around in various forms since 1977. Some of the languages haven’t changed, either. C is still C. I’ve got the K&R book, and it’s still a good reference. Even newfangled languages like C# inherited a great deal from C. Certainly, there have been massive changes, but variables still have to be declared, and a for loop still looks like a for loop.

    New languages and tools don’t have to leave experienced programmers behind. When Canola oil became popular, all the experienced chefs weren’t suddenly replaced by recent culinary school graduates. Scrambling an egg is about more than just what fat is used. Likewise, CAD didn’t put all the draftsmen and architects out of work. And Java hasn’t put all the C programmers out of work, either. There’s fundamental knowledge in any field that isn’t tied to a particular technology, and experience builds on this fundamental knowledge. If all your knowledge is all tied to a particular programming language, or a particular API, that’s a huge problem, but not because Q# is newer than Y++.

  • Low prestige

    Sigma, I don’t know if you expected prestige when you signed up for your computer science degree, but if you did, it’s your fault. Engineering and science disciplines simply do not have the prestige that law and medicine do. This isn’t a problem with computer science any more than it’s a problem with physics. It’s just a fact. If prestige is what you’re after, the sciences are not for you.

    You claim that Ivy League students aren’t majoring in programming. Well, I disagree. You say that what MIT teaches isn’t really programming. Well, I don’t know anyone but you who thinks MIT isn’t churning out real programmers. Yes, MIT is actually teaching the fundamentals of computer science, but I’m unclear how that’s a problem. Even “low-level” work in ASP.NET is benefited by a proper education. If someone can’t understand recursion, then quite frankly, I don’t want them building my e-commerce site, because they’re unlikely to be able to understand basic security, either. (I’m not sure exactly when ASP.NET became considered “low-level”, either.)

    The fact that schools like Devry and the University of Phoenix churn out “programming” degrees doesn’t indicate that programming is low prestige. All it indicates is that programmers are in demand, and the regulations are lax. If Devry could churn out MDs, you better believe that they would.

    Programmers aren’t lacking in prestige. They get the same prestige that anyone else in the sciences does. Civil engineers aren’t treated like lawyers. They get the same basic respect that programmers get. If you don’t think you’re respected at work, then leave. If you think you should be treated better, then find a better job. If you are worth more, then someone will give you more.

  • The foreignization of computer programming

    Quite frankly, your blurb about foreignization says more about your own prejudices and fears than it does about any real problem with the industry.

    First off, outsourcing is not a real problem. People have been saying that outsourcing would put everyone out of work since I started college. It still hasn’t happened. Yes, some companies have outsourced IT workers. Those workers found new jobs. (And many of those jobs came back, too.) There are still more jobs to fill than there are programmers to fill them. This is especially the case with good programmers. Bad programmers might get their jobs outsourced and be in trouble. Good programmers can always get other jobs. The really good programmers never even work places that would be dumb enough to outsource the programming jobs.

    As far as bringing in good foreign talent, I’m not sure why that’s a bad thing. You’re being a complete alarmist by claiming that foreign IT workers are taking all the jobs from Americans, and that the domestic market has been nearly abandoned to foreigners. Only someone who’s not good at their job should have to worry about losing it to someone who is good. Bill Gates stated recently that the government issues 65000 H1-B visas each year. Meanwhile, the number of computer science jobs is growing at a rate of 100000 per year. He’s pushing for looser regulations on H1-B visas because there’s still a shortage of good programmers.

    You say that foreignization causes a vicious cycle of low pay when combined with low prestige. This only makes sense if programmers have low prestige, which is not the case. Additionally, Microsoft and other companies pay the same wages to H1-B workers as citizen workers, according to Gates. No one’s bringing in genius programmers and paying them minimum wage.

    I don’t know why you care so much about how “America” views our “industry full of brown people”, either. It may be that the average person thinks less of the profession because many programmers are foreigners. But how is that even relevant? Random Joe on the street doesn’t cut my paycheck, so it doesn’t matter if he thinks less of programmers.

    You also say that Americans have more rights to the money created here than foreigners do. Well, many of the people who’ve helped drive America to be a superpower were, and are, foreign-born. If I hire a programmer, he is helping to create wealth for America. It doesn’t matter if he’s foreign or not.

  • Project management sucks too

    Not everyone wants to move into management. It’s also possible to be a highly-paid programmer without moving into management, so your initial premises are invalid.

    Older programmers don’t have to move into management to avoid ending up “underemployed fifty-year-olds, only suitable for lower paying IT jobs like ‘QA’ because they no longer know how to use the latest and supposedly greatest programming tools”. I don’t know why you think experience is worthless, but I really don’t understand why you think it’s impossible for anyone older than 25 to continue to learn. There’s no magical switch that flips when a programmer leaves college that stops him from learning new things. If a programmer is 50 and hasn’t learned anything since he was 25, he probably deserves to be unemployed. He’s clearly not the best asset. If a 50 year old civil engineer had been unwilling to learn anything after college, he wouldn’t be able to use CAD, and he wouldn’t know the latest building codes, and he deservedly would be unemployed.

    You also don’t seem to understand what “management” is if you think it shouldn’t involve planning and status reporting. That’s exactly what management is. The people who hold the purse aren’t managers, they are Directors and Executives. Directors tell managers what to do, and managers manage the day-to-day details. Management isn’t generally glamorous. It’s not a situation unique to programming.

    You also state that we need stronger industry bodies from the computer science profession. On this, I completely agree. The low quality of the average computer science graduate is enough to demonstrate that there are problems within the industry. We need industry bodies to set minimum competency requirements. The barrier to entry should be high, not to rule out foreigners, but to weed out incompetence. I think this needs to grow from the programmers themselves (much as lawyers run the Bar and doctors head medical boards). And I do agree that programmers should not be managed by non-programmers.

  • The working conditions suck

    Sadly, there is truth to this. Some places do not appreciate their employees, and therefore do not treat them well. This is not, however, a problem exclusive to programming.

    This is an area where an industry body would help. I think if we had an board which weeded out all the incompetent programmers, there would be less of a problem with poor tools. I think many companies simply cannot tell a good programmer from a bad one. And so they have a mix (mostly bad, a few good). A bad programmer isn’t going to be more productive with two monitors, and I think companies recognize this, and assume they are better off not giving dual monitors to anyone, rather than trying to give them selectively, or wasting the money giving them to everyone.

    Of course, there are many places that do appreciate their programmers, and do whatever is necessary to keep them happy. These are the places that programmers want to work, and these are likewise the places that you will find most of the good programmers employed.

Sigma, for the most part, your arguments don’t reveal any deep problems with the programming profession. They reveal instead serious issues that you seem to have with your choice to be a programmer. Your aversion to learning new technology seems to be a major problem. You chose one of the fastest-evolving fields in modern times, so this is unlikely to change. Programmers need to be lifelong learners. I’m not sure what else to tell you. Lots of people change their professions. It’s not too late for you. Alternatively, you could find a job using a stable technology that you enjoy. Maybe you should find somewhere that will let you use C or C++, both of which are unlikely to disappear anytime soon.

To the readers, pick a field that’s compatible with your own nature. You’ll be much happier. If you find that you’ve chosen the wrong field, change it. It’s just a job. Find something you actually enjoy, even if it means a massive career change. It’s better to be poorly-paid and happy than highly-paid and miserable.

March 7th, 2007

The one thing that unites all human beings, regardless of age, gender, religion, economic status or ethnic background, is that, deep down inside, we ALL believe that we are above-average drivers.

– Dave Barry

Let’s face it, we hate everyone else on the road. We’re all absolutely fed up with the terrible drivers. Unfortunately, the bad drivers show no signs of disappearing. If anything, the number of bad drivers seem to actually be increasing. Maybe that’s because we are the very same drivers we hate. Here’s my thoughts on what it takes (and what it means) to be a good driver.

A Brief Detour

Remember how yesterday the guy driving that green SUV nearly hit you when he merged into your lane without signaling? The asshole! What kind of idiot is he?

Well, you did the same thing to me last week. And I did it to someone else the week before that. Everyone makes mistakes while driving. Yes, yourself included. That doesn’t necessarily mean that everyone is a bad driver. It means everyone is human. Keep that in mind next time you see another driver do something really stupid. We all make mistakes, so take a deep breath and just let it go. Fuming in your car isn’t helping you or anyone else.

Have a Driving Goal

The most important thing you need in order to be a good driver is a goal. You should have a clear goal whenever you pull onto the road. I’m not talking about just getting from point A to point B. I’m talking about an overall guiding principle to guide your driving, a driving philosophy, if you will.

Your goal might be, e.g., to maximize safety, certainly a good goal to have. My goal is to promote overall traffic flow. I feel that every driver has a responsibility to other drivers. It’s not just you on the road. It’s a shared resource, and it’s only responsible to try to maximize the utility of that resource. It also turns out that the goal of promoting traffic flow is complementary to promoting safety.

Once you’ve got a goal, you can refer to it to fine-tune your driving. Having a goal won’t put an end to all your mistakes, but you might be surprised how a goal can redefine your behavior in certain driving situations. It’s simple to weigh two options and decide which one will help your goal the most. Constantly evaluating your driving against a strong reference can certainly help you to become a better driver.

An Example: When to Slow Down for a Turn

Lots of drivers slow down before they really need to. They slow down for turns, exits, etc. Some drivers begin slowing down as much as a mile early for highway exits. Let’s weigh this kind of behavior against a reasonable driving goal, and see how it holds up.

  • Safety. By slowing down early, you are no longer following the flow of traffic. You are therefore at a higher risk of being hit by someone behind you who’s not paying attention. If you’re like most of the “early slowers,” you’re also not even braking, you’re just pressing the accelerator more gently, slowing without brake lights, further increasing the chances of an accident. Now, you can say it’s the other driver’s fault if they rear-end you, and that’s fine, but that’s got nothing to do with safety. Increasing safety means you want to minimize accidents, not just minimize the accidents in which a judge will find you at fault.
  • Traffic Flow. By slowing down early, you’re forcing those behind you to slow down unnecessarily. You’re also encouraging them to swerve around you, potentially slowing other lanes down as well (and increasing the chances of an accident, see above). Slowing down early hurts traffic flow unnecessarily.
  • Fuel Efficiency. An interesting argument for the “early slowdown” is fuel efficiency concern. However, in many cases, you aren’t maximizing fuel efficiency by slowing down early. If you slow down too early for some highway exits (e.g., those in which the exit ramp climbs toward an overpass), you’ll have to accelerate again later to reach the end of the exit ramp. You’d likely be better off holding a steady speed and using the exit ramp’s climb to slow you.

As an aside, I also have serious doubts about the efficiency of slowing down while still applying some gas. It seems that for maximum efficiency, you shouldn’t slow down for a turn, exit, or red light until your foot is completely off the accelerator. The wind and the natural resistance of the car’s moving parts will bring your speed down fairly quickly, without braking, if you completely remove your foot from the accelerator. And I can guarantee that your car is burning less fuel when your foot is completely off the accelerator than when you’re lightly pressing the accelerator.

It seems best to slow down only when necessary. If your foot is still on the accelerator, you shouldn’t be slowing down. If your foot is still on the accelerator, then you do not need to slow down yet, and there’s no logical reason to so so.

One More Example: Merging at low speed.

We’ve all seen people merge with highway traffic going 25mph, or try to. It can be infuriating. Rather than just be angry and dismissive, though, it’s again useful to think about why it’s so infuriating.

  • Safety. Merging at low speed is unsafe for two main reasons. First, if you merge moving slower than traffic, someone in that traffic is much more likely to hit you. You’re also more likely to be hit by others behind you who are merging, and who are giving more attention to the traffic they’re merging with than they are giving to you.
  • Traffic Flow. If you merge at low speed, others who are merging behind you are forced to slow down, as are those in the traffic you’re merging with. You’re forcing numerous people to slow down when you merge at low speed. This kind of poor merging can be a major cause of traffic problems on busy highways.
  • Fuel Efficiency. This one’s barely even relevant here. You’re (presumably) going to get up to highway speed eventually. It makes sense to do that before merging. In many (or most) cases, the on-ramp will be sloped downward, which is the perfect place to build speed with low fuel expenditure.

Merge at speed. You should be moving at the same speed as the traffic you want to merge with. Going slower makes it harder, not easier. To be as safe and efficient as possible, always merge at the speed of traffic (but keep an eye out for the guy in front of you trying to merge at 25mph).

Put Your Goal Into Practice

I’m sure you can come up with plenty of other examples of driving problems, so I won’t bore you with any more. The point isn’t just to pick out examples of bad driving, but instead to decide why they are examples of bad driving. When you see someone do something stupid while driving, ask why it’s stupid. Determine why they shouldn’t have done that, so that you can truly know why you shouldn’t do it either.

But don’t stop there. Once you’ve picked your driving goal, use it to evaluate your own driving habits as well. Part of being good at anything is working to improve. If you want to be a good driver, think about how you drive. Ask yourself how you could improve. Find the parts of your driving that don’t fit well with your goal, and fix them.

Being a good driver means asking yourself where you can improve. Having a goal can help you answer that question.

(Update: I’ve changed the title to hopefully better match the tone of the post. The title was written before the actual post, and seemed out of place.)