Tag Archives: coding

The Cobbler’s Kids are Shoeless

There’s a 16th-century proverb that goes something like, “The shoemaker’s children go barefoot.” Or unshod. Or something olde-timey like that. But however you phrase it, the sentiment certainly seems true today.

Last week, Apple announced that their developer site was hacked, and that potentially thousands of developers’ emails and other info may have been compromised. The hack (and the hacker) have since been called into question, and the real scope of the intrusion is unclear. But, to put it mildly, it ain’t good.

If Apple, with all of its resources and intricate technological knowledge, can’t keep it’s, ahem, stuff together with basic security, it seems like there’s not a great amount of hope for the rest of us. At least under the current security regime. Some of this is certainly due to neglect close to home — the shoemaker/cobbler proverb again — but much of it is based on how we handle security in general.

The username/password or email/password security approach just doesn’t work. It really doesn’t. Oh, sure, you might argue, it’s ubiquitous, so it must work fine. But there are SO many examples of breaches that something is amiss, and even where there aren’t breaches, it may just as likely be because nobody has really targeted that system yet.

So if not that, then what? Biometrics? RSA keys for everyone? Implanted chip under the skin? How apocalyptic sci-fi movie do we want to get?

Frankly, I don’t know. Each of those approaches has definite pros and cons, including a glimpse of dystopia. But I know this: what we have now is not working. And perhaps this is just another example of Apple leading the way.

Not that they were wanting to lead in this particular area… Apple, get your kids some shoes!

Where to Start?

I get asked every couple of months how to become a developer — someone excited about technology who wants to learn “how to code.” And I think that’s great. But they’re going about it all wrong.

There’s coding, and there’s programming, and there is a difference between them. One is a prerequisite to doing the other well.

If you are a coder, you can (probably with one or maybe two languages), attack problems and solve them. It may not always be elegant or efficient, but it works. You’re able to Get It Done.

But if you’re a good coder, you can (with whatever language is thrown at you, and probably choosing the one that is best suited to the task) attack problems and solve them as well. You can do it quickly, efficiently, and with as much simplicity as possible (without over-simplifying and missing the target). You can Get It Done Right.

So what’s the difference? The good coder is also a good programmer.

Learning how to program is mostly language-independent. It’s about how to think like the computer. How to spot common kinds of problems and solve them algorithmically. To use one of my favorite example, when to use a quick sort or a shell sort. What kinds of data structures work better in different cases. And so much more.

Almost none of that depends on a single language. In fact, learning those things in a language you think you’ll be using on “real” projects is probably a BAD idea. Which is why many universities use languages like Ada or Scheme. By doing that, you get (at least) two benefits: you can abstract the language away and focus on the underlying programming; and when it comes time to do “real” work, you’ll be learning a new language, which helps cement the programming concepts.

It’s no coincidence that many self-taught developers are coders — but not all. The key is to search through the midst…and find a programmer.

Know Thy Tools

A while ago, I was reading an issue of Dr. Dobb’s when I came across the assertion that programmers waste a significant proportion of time because they don’t know their tools well enough. And I think that’s probably right. But it doesn’t go far enough.

Earlier on the blog, there’s a post about the importance of having a broad and deep toolset. But both the Dr. Dobb’s comment and the earlier post focus on the development side of things. I think the assertion is just as true on the design side as well, although the perils may be a little different.

When developing, if you’re working in an IDE and you don’t know the intricacies of how it works, you’re definitely going to be working more slowly than you need be. When designing, if you’re working in a design tool and you don’t know the ins and outs, you’re restricting the scope of your creative output. That’s perhaps an even more catastrophic outcome!

Think about Photoshop, for instance. That tool is both broad and deep, and it gets moreso every cycle. Now that it will largely be available as a subscription only, the changes will just keep on comin’. But if you don’t know how the filters work, you may no longer have those design choices in your visual vocabulary to work with.

In contrast, if you don’t know how to do multi-file grep-based search and replace in BBEdit — something that is roughly comparable in terms of complexity and importance, I think — you have a bunch more work to do to get to the outcome, but you can still get there.

Regardless of the specific poor outcome, the lesson remains the same: know your tools. Whether you’re an information worker who lives in Word, Excel, and PowerPoint; a coder who lives in emacs, BBEdit, or Notepad++; or a designer who lives in the Adobe or Corel worlds, you’re probably missing out.

Besides, how can you complain about the limitations of your toolset if you don’t really know what they are? Think of the fun you’re denying yourself!

Making Comments Count

Earlier this week, Graham Lee wrote an opinion piece about what separates a good code comment from a bad one. It’s thoughtful and well-written, with plenty of examples and some excerpts from the relevant literature.

I must admit that my philosophy on code commenting has changed quite a bit over the years, as both I and my projects have gotten more sophisticated. (Well, the projects have gotten more sophisticated; I think I’ve just gotten older.)

When I was just starting out, commenting code seemed like a boring waste of time. Why on Earth would I spendwaste valuable time putting in comments when it was perfectly clear what the code was doing? Besides, I wrote the code, and I’d surely be the only one ever asked to maintain it, so there’s little point.

Of course, this was also a time in my career when coding projects numbered maybe into the hundreds of lines. So, arguably, there may have been some merit in the notion that comments wouldn’t have added a lot of value.

Then came the time when I needed to ACTUALLY go back and revise some code I had written years earlier. Yeesh. If there was ever a way to feel you had amnesia, this was it. I was looking at code I had written — I knew I had written it — but couldn’t recognize it for the life of me. I had gotten so much better in the language and the algorithmic design that I recognized the old code for what it was: a mess. And a virtually uncommented-one at that.

If losing a hard drive full of data is what makes most people fervent backer-uppers, getting baffled by my own historical code was what drove me to commenting. And in a multi-person team, it’s essential, since comments can also document required parameters and their meanings, and actions that need to be picked up by someone else. Heck, I even use comments to myself in the code to remind myself where I stopped work one day and where I need to pick up the next.

Beyond the act of commenting, though, there are some key differences between good ones and bad ones. But I’ll let Graham Lee pick up that ball. He’s done a good job of it in his article. Worth a read!