J. Timothy King’s Blog

You Know You’re an Old Fogey Software Engineer When…

Today, I came to a realization. I’m now officially an Old Fogey Software Engineer. You know, like those narrow-minded, intolerant, old-time veterans of the field I used to look down on when I was but a young Whippersnapper. They were so limited in their view, only being able to do what they have always done, always disagreeing with me, always putting roadblocks in my way, always wiping out my carefully crafted abstractions in favor of in-line code, always throwing out my object-oriented design in favor of procedural, always turning my portable, reusable code into use-once code. I never stopped to think that their objections might have been born from decades of experience and life-long expertise.

Now that I’m officially on the other side of the fence, I’ve discovered a new rule: When your junior colleague thinks his fancy object-oriented code is simpler than your straightforward procedural code, you know it’s time to raise your rates. Because they’re not listening to you, so you know you can’t be charging them enough. (Read more…)

Does Bad Writing Reflect Poor Programming Skills?

Writing is a communication skill. And they say that communication skills and the other soft skills are what programmers need today. Effective developers don’t work alone. They work with others in a team. And a team member needs to communicate with the other team members to be effective.

It’s like playing football. No one person can win the game on his own. Each player does his part to determine whether the team moves forward. The center snaps the ball to the quarterback, who hands it off to the half-back, who runs through a hole the offensive line has created in the the other team’s defenses. Or maybe the quarterback passes the ball to a receiver. Occasionally, the receiver is on a different page than the quarterback, and when the ball is thrown, there’s no one there to catch it. The play falls apart. Players either work together, or they lose the game. In football speak, this is called “not executing well.”

(Read more…)

Seven Truths of Good Code

What is “good” code? Some define it as “beautiful.” Some equate it with experience. Some with cleverness. Some can’t tell you what it is. Others know it when they see it. For me, “good” means maintainable.

Good code, yes, has grace and beauty. But what makes it worthwhile is that it’s easy to work with. It’s easy to add to good code. It’s easy to take away. It’s easy to make changes. It’s easy to fix bugs. And bugs are rare. Good code does what you want it to, usually the first time. Good code is a joy, not a burden.

This should be the normal state of software. How many developers live in the opposite state? They think that adding a feature always takes a long time and many lines of code. They think that getting cozy with your debugger is part of the process. They think that long hours sitting in front of the computer screen means you’re doing your job. It doesn’t. Long hours means you’re doing your job poorly.

Consider these truths of quality code. The best developers know them without thinking. To them, good code is second-nature. They’ve internalized these truths. They’ve reached nirvana. They are one with the code.

(Read more…)

Ten Favorite Books

These are not necessarily my all-time favorites in all categories. I don’t even know whether I could narrow the list down that far. But these are ten really good books from my library, all of which I heartily recommend.

In fact, I continue to be amazed at how many people have not read even the most significant of these books. How many businessmen have never read Peter Drucker. Every executive, every manager, every entrepreneur must read Peter Drucker. Or how many software engineers have never read Frederick Brooks or Demarco and Lister. Or how many software managers don’t even know who Brooks or Demarco or Lister is.

(Read more…)

Quick and Dirty May Be Dirty, But Is It Quick?

I’ve been meaning for some time to write about how slow “quick and dirty” is, how misnamed the term is, how misguided are the hoards of managers (many of them former and current software developers) who embrace “quick and dirty” as a fast solution to pressing problems, as though it could ever deliver an actual solution.

I’ve been meaning for some time to write this. It took Lidor Wyssocky’s latest blog post to push me into it. And just in case someone out there couldn’t tell you were joking… (You were joking, right?) The sad truth is that “quick and dirty” may be dirty, but it’s never quick, at least not if you actually want to deliver a usable product.

(Read more…)

Fix for w3mir With Latest URI.pm

What brought this all on was that one of my computers died. So I updated software on another computer, and discovered I needed a fix. It’s a fix for a recent improvement in a Perl library, URI::file::Base, that coupled with behavior in URI::file::Unix happens to invoke different behavior in URI::URL, which… Basically, w3mir no longer works.

(Read more…)

Dead Fish and Other Things People Wear

Lidor Wyssocky at The Mindset writes about “The Emperor’s New Clothes Syndrome.” This reminded me of a talk Tim Lister gave earlier this year at the Boston SPIN. “The problem is that although we know exactly what doesn’t work right and how it should be fixed, most of us will never say anything,” Lidor writes.

(Read more…)

Please Don’t Share Your Bodily Fluids With the Rest of the System

Have you ever been here? Refactoring old code, seeing new code that partially de-factors it, and taking out my frustrations in code comments.

The old comment for a struct declaration:

// This structure will be generated
// and stay with each connection

The new comment:

(Read more…)

Top Eight Reasons to Abandon SourceSafe

How many of us work in Microsoft shops? I’m ashamed to admit that I do. When I took the job, I thought the benefits of working in a new domain with new technologies would outweigh the fact that I had to use Microsoft tools and program for Windows. Well, the benefits are real. The costs are also real. And one of these costs is SourceSafe.

The worst part about it is that there’s no particularly good reason why we have to use SourceSafe. (Read more…)

When the Best Tool Isn’t, and Why a Growing Team Doesn’t Care

Kathy Sierra excellent post on When the “best tool for the job”… isn’t misses an important point. It’s not that she missed the point so much as she just didn’t go into it. But I think it deserves going into.

Many software developers become very attached to their favorite programming languages, methodologies, practices, and so forth. Checking the link-backs for my post “Twelve Benefits of Writing Unit Tests First” demonstrates this. One commenter on another blog even said he saw no value in reading the whole post, since it was specious and had no redeeming value. I took great joy in that comment, because it means I must be doing something right to push someone’s righteous buttons so accurately. Regardless, would test-first be the right tool for that programmer?

(Read more…)