As an architect for a team with a large number of people, I have a couple of problems: I often make decisions that turns out to be quite crappy. Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses: Most developers are pretty smart, especially when they’re trying to solve a specific problem.

What if you had to report daily your progress on the tasks you’re programming in your project. Wait, you say: “I already do that in my daily standup meetings”. But if your standup meeting is anything like most standup meetings out there, you’ve got a serious blind spot. What if I said that writing code doesn’t constitute progress. Code is effort, not value. In order to demonstrate value, you have to be able to show your progress to someone who doesn’t care about code.

Ctrl-1 is the magic “do what I think” button in Eclipse. Whenever I press it, Eclipse seems to come up with something that’s helpful in the current context. In this blog post, I illustrate 10 things that Eclipse hide under the ctrl-1 keypress. This is a follow up on my post on Eclipse stenography. I got some comments on my last post about Eclipse stenography about the animated gifs. I know this can be annoying, but I considered the alternative: To have you mouse-over or click a picture to animate it.

When working on replacement projects, I often find I need to make minor changes to an existing database that is still in use by one of several other applications. Initially, it may seem like situation will force you to conform to the current database schema. But there are other options, even though they may not be for those who are faint of heart. The general pattern when you want to evolve a database that is in use by legacy system, is to make sure that the legacy system sees the same data structure when it reads from or writes to the database.

Sometimes I’m asked to write or speak about something with very little preparation. In these situations, I need a tool that can help me: Organize my thoughts quickly Prioritize the wheat before the chaff Maintain a coherent train of thought I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each. Forcing myself to keep to a structure will make my thoughts flow more quickly.

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this. I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session.

According to Wikipedia, stenography or shorthand is “is an abbreviated symbolic writing method that increases speed or brevity of writing as compared to a normal method of writing a language”. Just as a stenographer learns to take down information really fast, a good programmer can learn to write code really fast by taking advantage of his or her tools. In this post I’ll show you my secret code stenography tricks.

Everyone has heard horror stories about pointy-haired-bosses counting lines of source code to track the progress of a project. We roll our eyes and laugh at their stupidity. But before you laugh too much, you might want to find out whether you’re really any better. Most of what software projects measure are not things we care about. Not things we really care about. Do you really care about the number of coding standard violations in your code?

How many steps do you need to perform to release a new version of your software? Do you even know? Releasing frequently requires the release process to be as streamlined as possible. A good way to get started is to write a step-by-step instruction that explicitly state everything that needs be performed for an installation or upgrade. Then get to work cleaning it up: Make sure you can build and package everything that’s needed for the installation with a single command Does the installation or upgrade require several files to be installed?

No computer system is an island. At least not these days. This creates a challenge when you want to change APIs: Do you want to upgrade all affected systems at once, or do you want to support multiple versions? Both approaches have downsides. Coordinating several upgrades increase the risk that one of the upgrades fail, in which case, you may want to roll everything back. In some situations, rollback may not even be possible.