Monthly Archives: October 2007

Trump Tower

My business took me to Trump Tower, under construction.

It’s going to be really, really big. I don’t think they’re even half way up yet.

Heavy construction is underway on the upper floors. Infrastructure work on the lower.

This picture doesn’t do it justice.
Trump Tower

Here’s the view from the skip — the construction elevator on the outside of the building.
Trump Tower
Trump Tower

There were always two trucks delivering cement, with another standing by.
Trump Tower dump trucks

It’s amazing the amount of work that goes into a building, particularly one this big.

Consultant’s Swiss-Army Knife (Part 1)

As a consultant, I’m always looking for the perfect Swiss Army knife-type tools related to what I do. Pulling the right adapter or gizmo out of your bag can save the day, avoid embarrassment (yours or your client’s), or make you come off looking like the hero.

But you can’t carry a stack of steamer trunks: small and lightweight are crucial.

Here are a few things I’ve found helpful related to the software I write:

  • Of course the USB flash drive (aka flash disk, thumb drive, or USB key) is crucial. They’re getting higher capacity and cheaper by the month.
  • This Ethernet cross-over adapter lets me carry just one CAT-6 cable instead of two. It’s very small.
  • Trendnet’s USB modem is nearly as small as a thumb drive.
  • This Cables-to-Go USB Serial Port has proven itself valuable. The Belkin version is even a little nicer, with 3 LEDs: TX, RX, USB.
  • This Eforcity USB Sound Card Adapter gives you another sound card for $5, and is as small as a thumb drive. It’s amazing. (It was a bit confusing when I was looking at these, but it’s the same as this and this.)
  • National-tech seems to have lots of little adapters, though I haven’t bought from them.
  • If you need USB cables, this kit has them all. Other similar kits are here, here, and here.
  • An ordinary chair can be a life-saver (or back/neck-saver) when you’re working in an unfriendly environment. Target sells a camping chair for under $6 that packs into a bag. Well worth the money if you need it. (Sorry, I couldn’t find it online.)

I’ll put more up as I go.

Getting your mind around it

Paul Graham gives an excellent inside look at programming. He calls it “Holding a Program in One’s Head”:

A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he’s working on. Mathematicians don’t answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.

I call this getting your mind around it. I don’t try to hold the whole program in my head, but rather its key objects: how they should interact; which features matter; which objects handle which requirements[1].

That’s particularly valuable at the start of a project, because initially the most important thing is to be able to change what you’re doing. Not just to solve the problem in a different way, but to change the problem you’re solving.

Your code is your understanding of the problem you’re exploring. So it’s only when you have your code in your head that you really understand the problem.

You labor to intimately understand the entire problem, even though it’s impossible. So (as he says) you must mentally explore various directions.

It’s not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you’re actively working on a program it can take half an hour to load into your head when you start work each day. And that’s in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they’re solving.

Distractions can be deadly, though I wouldn’t put it this dramatically. Programmers working in “typical office conditions” do need to get creative to carve out the mental resources they need.

Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard.


Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you.


Harness the power.

The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.

Today’s C++ compiler is an incredibly powerful tool. Use it. Exploit it. Harness its power. Its goal is to help you solve the problem, managing details and catching many kinds of mistakes along the way. Let it.[2]

Your code’s values. (Clarity, clarity, clarity.)

You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.

“Programming languages” sounds a bit cryptic to my ears. I prefer building blocks. The lower layers should be good building blocks for the higher ones.

Your code should be “values-oriented:”

  • Your first responsibility: make your caller’s code clear.
  • Your second responsibility: be as clear as possible yourself.

Trading a lower layer’s clarity for a higher layer’s is almost always the right thing to do. Your caller’s code should read like pseudo-code, marching as clearly through its sequence as possible. Same’s true for you.

How would you do it differently? (Make it so!)

Paul writes:

Keep rewriting your program. Rewriting a program often yields a cleaner design. But it would have advantages even if it didn’t: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.

It almost sounds like he’s endorsing rewriting just to warm up your fingers, but that’s not his point.

A delicate issue requiring sober judgment. There’s an obvious cost to rewriting code (your time). But there’s a cost to living with a piece of code, too (and it’s open-ended and perhaps very painful). As you learn better what it needs to do, you may need to radically change it. My bias, like Paul’s, is to make those radical changes. (And don’t blame yourself for lacking omniscience.) Yes, your boss may have a heart attack, but it could save him from one too.

I’ve rambled enough. Give Paul’s piece a read.

Via Bruce


[1] — He agrees, saying later, “If you [build your code] right, you only have to keep the topmost layer in your head.”

[2] — I don’t mean to slight your favorite language.