It’s been a month now since I left Intel. Life is busy. There are lots of days when I go to the park with the kids not once, but twice. It’s gotten to the point that I’m on the lookout for more parks; can’t just go to the same place day in and day out. As I’ve kept mentioning, I still want to do technical work. I continue to chair the SystemRDL committee and that’s still engaging. Beyond that I have some other programming projects (I do like to write my for loops). I haven’t done much so far, I’m mostly setting up a work environment. Getting a linux box running in the basement, configuring a windowing environment like the one I used at work plus some additions I should have implemented years ago. I’ve installed the Android environment.
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.

Cool online folks
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.

It’s a fairly standard code review thing, but there are some things I find really important:

  • 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.

Cubical interactions
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.
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

  1. 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.

  2. 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

  3. 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

  4. you just have to ignore CC’s strong desire to do the standard thing of only reviewing diffs

  5. 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.

4 thoughts on “Role models and inspiration

  • June 4, 2015 at 7:07 am

    Code Complete and Writing Solid Code are two of my favorite all-time books. I remember browsing a local Ann Arbor bookstore over my lunch hour back in college, and being amazed at how well written they were. A few years back I bought the updated versions of each.
    A few others that were formative for me (and which I should really revisit, as it’s been many years since I last read them) were “The Pragmatic Programmer”, “Clean Code”, and Fowler’s “Refactoring”. I love reading a good programming book, but the advent of the web means that much learning comes from reading code snippets on stack overflow instead of deeper insights from coding experts. And perhaps it’s just that we’re all older, but it seems that few people really enjoy discussing a good programming book these days.
    I too am working on getting an Android development environment up and running; lots of ideas, so little time. Must make more time, or have fewer ideas….

    • June 4, 2015 at 3:56 pm

      Thanks for the recommendations.
      I agree that something is lost by depending only on short posts/snippets. In my internet based learning, I’ve found that the lessons out there to all cover the same specific points while lacking overall structure. There’s a lot of missing material between those points.
      There’s no such thing as too many ideas.

  • June 20, 2015 at 7:08 pm

    Effective Java is one of the best books I’ve read in recent years, really well presented ideas that don’t only apply to Java.
    Android development is really, really fun. I love that you can think of an application and release it directly to users, and Google has great analytics tools so you can see who’s using the application and how. It’s most pure fun I’ve had developing in a long time.

  • June 25, 2015 at 10:36 pm

    Miles certainly knows how difficult I am so this comment will come as no surprize! wink!
    This post seems pretty tech oriented and thus I suppose I should assume the context is so; but I cant . . even if I think and assume “tech” people read wider and deep than others.
    Here are my role models:
    Noam Chomsky
    Howard Zinn
    Bertrand Russell
    Karl Popper
    Murray Bookchin
    Books I would recommend and have even to people who have asked me during and from work are Peter Singer’s Practical Ethics and Nel Noddings The Maternal Factor. I absolutely recommend these authors and books over anything posted here.
    I have asked people: What was the last time you read a book? For the 10% (plainly an estimate as I dont have the data, so its anecdotal) that answer: Within the last month, I ask them to name it or what area it was in. 9% of those have read a fiction book (why? because we are nerds/geeks/etc so Game of Thrones) and 1% have a read a non-fiction, aka a biography. I cant understand this.
    What am I reading? Well, I could point you to my Goodreads bookshelves, but . . . just finished Understanding Social Networks: Theories, Concepts, and Findings by Charles Kadushin, currently reading Social Structures by John Levi Martin and Group Agency by Philip Pettit and Christian List; and for fun Betraying Spinoza by Rebecca Goldstein. Why? Reading and trying to understand someone’s complete ethical system that they worked their whole life on teaches me how to “think” at that scale (IMHO), the social network stuff informs my designs of the massively distributed software I write, and about “group minds” or “do corporations have minds” helps me but a team that can make coherent group decisions.
    Or Im just arrogant.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Miles's thoughts