Entry Level Programmers and Non-Breaking Spaces

Dana Ross
4 min readOct 17, 2015


“Dave, could I speak to you in my office?”

I froze. You know that little twinge you get in the base of your spine, right above where your coccyx meets its non-vestigial bretheren? I had that. Intellectually, I knew I hadn’t done anything wrong. My projects were ahead of schedule, my clients were happy, and I couldn’t think of a reason for any of my co-workers to be unhappy to be working with me. But I still had that twinge. It’s a remnant from my childhood, and life-long doubt that I must be guilty of something.

Now, I should point out, although it can probably be assumed from some of the context: the events I’m describing took place a decade and a half ago. I still lived with my parents, Bill Clinton was still president, and I don’t remember the exact words said to me or what defensive, borderline-sycophantic vomit came out of my mouth. It was a long time ago. Instead, you’re getting a reconstruction, a dramatic re-enactment if you will, in which I am brilliant, confident, and incredibly witty.

My manager had a printout on her desk. We used one of those wide-carriage dot matrix printers and regularly printed out code to show one another. It was in a soundproof box in our makeshift datacenter because it was LOUD. If you’ve ever been in a datacenter, with computer fans and air conditioning humming, you know how loud it can get without a high-speed dot matrix printer hammering out code onto ream upon ream of greenbar paper. Whoever bought that soundproof enclosure is my hero.

This particular page of fan-fold greenbar paper had six characters circled in red pen. “Dave…what is this?” I leaned over her desk and zeroed in on the suspect code: “ ”

“That’s the HTML entity for a non-breaking space,” I said confidently. And I probably did say it confidently because I knew HTML inside and out. It wasn’t that hard. There was a lot less to it back then.

“But why is it there?”

I skimmed the surrounding code. and quickly realized what code I was looking at. Since CSS 2.1, browsers have rendered empty table cells just like the rest of their brethren and you have to use a barely-known CSS2 declaration of “empty-cells: hide” to make the browser skip drawing them. But back in those days of Netscape 4 and IE 5, the default behavior was to “collapse” those cells automatically, hiding their borders and not rendering the background, leaving your table’s outer edge with gaps if that’s where the empty cells lied. There’s a reason so few know about the CSS2 implementation: it’s ridiculous and unsightly. But that was what we lived with in those days. The popular work-around was to fill those empty cells with a non-breaking space character. As long as there was something in the cell, the browser rendered the way you’d expect it to.

I explained about collapsing cells and how much better the output looked without gaps in the table border, and I saw the Director frown. Today we’d say she believes in good UX; back then we lauded her commitment to making things that were user-friendly.

“I see what you’re saying, but we have a problem. The entry-level programmers are coming back to us saying they don’t understand this code. They don’t know what that sequence of characters is and what it does. We want you to take it out.” It was my turn to frown, because I knew the client would come back with a bug report as soon as they saw the broken table.

But I did it, because there’s never enough money to train people right. And when you’re hiring warm bodies who don’t have a programming background aside from the two-week BASIC class you gave them, you can bet most of them will fall asleep when you start talking about character entities and cell collapsing. It’s easier to make one Sr. Programmer change their code.

Sometimes I see comments on Twitter or forums like Hacker News where someone sounds honestly confused. How could anyone managing developers or running a business whose principal product is software make a decision that’s bad for their customers’ user experience? Worse is when they try to explain to me all the ways the Director’s assumptions were wrong, like I was oblivious to how bad a decision this was.

There’s no lesson in this blog post, aside from a disappointed and resigned “it happens”. As developers, all we can do is learn from these experiences and get ourselves as far away from companies that work like this as we can. I’d like to believe we can change companies like this, but it’s pretty darn difficult.

By the way, I was prophetic: The client reported the terrible table display as a bug and I had to tell this whole story to my Project Manager, who told me to put the non-breaking spaces back in, make the client happy, and never tell anybody what I did.



Dana Ross

Building the web since 1996. Full-stack developer, but love front-end tech. I also socialize feral and abused cats.