It’s all normal pre-work. A slow start, but I’ll be productive soon enough 1. The thing that concerns me a little bit is that I have less access to role models, inspriration, muses. So I figured I’d talk a little about where I’ve drawn from in the past. There are a bunch of sources:
- Books and discussions around them
- People online doing cool stuff
- Code reviews.
- Serendipitous cubical interactions.
- CADPax
It hasn’t happened as much in recent years, but the early times of my career felt like a Renaissance of Computer Science. The folks in my work environment were reading lots of books and implementing the ideas found therein. There must have been 15 or more participants in my local circles. Some of the books that come to mind.
- Code Complete
- Writing Solid code – written by Microsoft at a time when their products seemed so unstable.
- Design Patterns 2
- Modern C++ Design – quite a tough read, but worth it. It reminded me of some of my MIT math classes that were taught from a thin (1/4″ thick) book yet only covered a quarter of the material in it.
- Effective C++ – The author Scott Meyers visited Intel on at least two occasions. First to consult on some stuff the dept was working on and later to give a talk on Programmer’s Day. From a conversation with him on the second occasion, I was amused to learn that he’s never really been a developer.
In recent years, I’ve come to value the ideas I get from online personalities. This section warrants a digression to my childhood.
I’ve always been a curious person 3 but, as a kid, I lacked in world experience and hence had trouble filling my time. I can remember one summer, when I basically burned time by watching not so interesting television. Don’t ask my why I didn’t just spend more time reading or at the library. Had Youtube been available, things would have been much more interesting. I would have spent more time tinkering.
Jeri lElsworth is super awesome with a great story. She grew up largely in her dad’s auto service station. She made a living for a while building race cars and later doing circuits. I don’t believe she ever went to school for any of it. As a bonus, she’s from the sticks near Portland.
Dave Jones of EEVBlog and The Amp Hour podcast. I enjoy hearing his frank critiques of various electronic designs. Lots of great real world stuff.
As I’ve mentioned before I enjoy the ATP podcast. Although they talk about Apple stuff (which I am opposed to), they do it in a way that is interesting. It’s good to get a look into how knowledgeable people look at stuff.
Dangerous prototypes I appreciate how a tinkerer put up an open design of his Bus Pirate, was eventually approached by the Seeedstudio people which became popular and he made a career out of it.
Through links like these, one can get to a ton of others like them.
Code Review
Early in my career, some coworkers came across the only way I’ve seen to do effective code reviews. It goes like this:
- Print out the code in a line-numbered way such that everyone sees the same numbering
- Everyone takes an hour to read and markup their copy (we did it on paper, but I’ve found that Code Collaborator can be used for this 4
- You get together in a room and, round robin, everyone makes an observation.
- Discussion ensues.
- I don’t care if we find actual bugs. Sure, that’s a bonus, but we usually don’t find something earth-shattering. The code is usually specialized and only the author really understands it. The frequency of significant finds is not enough to keep everyone motivated.
- Personally, I find that coding standards are a waste of time. They always seem to devolve into arguments about where the curlies should go, how much spacing, camelcase,… I have only one universal rule:
- Be consistent to the rest of the file/function. Just because the placement of the curlies doesn’t make sense to you is not reason enough to be different from the rest of the code you’re modifying.
- Each reviewer makes comments based on their own experience and hangups. If it’s important enough for them to fixate on it, it must be worth noting and sharing.
- The real value comes from the discussion. It goes like this:
- A: on line 27, I don’t like leaving out the curlies on a single statement if.
- B: really? that adds clutter
- A: sure but what happens when you add a debug statement two years from how.
- B: add the curlies then.
- A: ok. but what if you first make this change, then this other change, then you delete this original line,… you have a bug.
- B: …. oh.
- After many discussions like this, the group will come to a consensus:
- Oh, that’s just something that Miles was bit by years ago, but we don’t agree it’s an issue.
- You really do want to do A, B, and C.
- Most important of all, in the end, the owner of the code is a well paid professional, who’s employed to use engineering judgement. The real value of these reviews is to educate each other and improve that collective judgement.
I’ve found that I don’t work so well in isolation. I need to talk to people. The people don’t need to be particularly knowledgeable on what I’m doing. I sometimes wonder whether a manikin would work as well. Just the process of explaining is enough to get my juices flowing. There are a couple ways in which the other side needs to be human.
When I worked in Israel supporting mask designers 5 to more effectively use the design tools. There were often times that I didn’t feel like working, so I walked around finding other people to corrupt. We’d shoot the breeze a bit, how are the kids?, going on a vacation?… Eventually, I’d ask them what they’re working on. What are you doing? How are you approaching it? Which commands are involved? Why don’t you do it this other way? Ah, I see why you can’t do it that way. Still why are you using this command. How about this other one? Response: well, that command has this side effect…. Me: I can fix that. We’d talk about what the thing should really do and I was motivated to work again.
Second story. My original manager, Avner, mostly left me alone. He sat in the cube next to mine but we often wouldn’t talk for days. Eventually, he’d come by “your cube has been quiet for a couple days. That usually means you’re cooking up something”. I’d explain what I was working on even though he likely didn’t understand most of it. What he did understand was how I talked about stuff when I wasn’t entirely convinced it was the correct approach. Maybe I just wanted to get it done, but he would zoom in on that. He sensed the chinks in the armor and didn’t let me get away with it. I’d try to explain why doing it the right way would be too hard but the process of explaining often showed me an easier way to do it right.
Of course there are also the people I can always go to for engaging discussion about whatever I’m trying to do.
CADPax
Years ago, in the golden age of programming in my department, someone noticed that all of us had our own little library of routines that made our programming lives easier. Code for spawning execution of several jobs, how to do common things in the tool we were working on, ways to make it easier to interact with TCL/SWIG. We got together to figure out a ways to reduce the duplication of effort. Releasing this stuff with the main tool didn’t really make sense. Each small library was too small to justify it’s own sub-tool. So we created an umbrella tool called CADPAx. (packages for the family of CAD tools we all worked on).
CADPax eventually became a pile of stuff I grew to depend on, but that wasn’t the main benefit of the library. Instead, it was the mindset it put me in. The mere act of considering the re-usability aspects of my work made my work better. Doing things cleanly often doesn’t require much more than thinking about it for an extra minute on a regular basis.
When done and managed well, the human work environment of a programmer can do a lot help hone the skill, maintain motivation, enable miracles to happen. Now that I’m not at Intel anymore, I need to find replacements for some of these.
- Please comment with any book titles I should checkout.
- I’m a good code reviewer (at least I think so), bug me if you’d like to do one.
- I have one or two prospects for collaborative projects. Let me know if you have an idea.
Role models and inspiration
Robie and I have agreed on a family schedule that gives me the equivalent of a couple solid days to do whatever I want… Garden, programming, lunch with friends. It’s mostly 4 hour chunks. ↩
I’ve had exactly two interviews in my career (in which I was the one interviewed). The second one was with Autodesk about eight years ago. Sadly one of the questions I did poorly on about a design pattern. I supposed that had the culture of discussing books continued around me I might have done better and gotten an offer. In retrospect, I’m glad I didn’t get the job. There’s no way the hiring manager and I would have gotten along. No real way to know ↩
my older sister likes to tell a story from when I was 5 or 6. I had watched my dad build a set of speakers. Soldering and all that. Some time later, I wanted to listen to the radio in my room, but the stereo was in the living room. In the closet’s junk pile, I found a length of antenna wire and one of my dad’s unused speaker drivers and wallah, the music was in my room ↩
you just have to ignore CC’s strong desire to do the standard thing of only reviewing diffs ↩
people who are employed to draw the polygons representing the wires and transistors that make up a semiconductor circuit. At car companies, they be called draftsmen/women. ↩