Monthly Archives: November 2017

One of my favorites: Python Weekly

Here's one of my favorite email lists I'm a part of: Python Weekly.

I recommend it to you, even if you're not a big Python person. What I like about it is just seeing the range of problems that can be solved. Honestly, I don't even understand most of the Python stuff that it links to. And I don't feel the need to understand most of it because I don't rely so heavily on 3rd party libraries (for good or ill). I read through the links and absorb ideas that I can steal.

Do it up.


I checked into the Venture Cafe tonight at the Danforth Plant Science Center to hear some people pitch projects that they were working on. The one that stood out to me was this app: TableTalk.

The basic idea seemed to be this: make it easy to set up a table anywhere (via API connections to Yelp, Eventbrite, Meetup) and meet with people. Even if they're people you don't know, you could organize around an idea or topic.

I have a Meetup account, but I never use it. I'm a member ("member") of a number of local groups, and I get the weekly updates, but I never use it. The regular schedule of the meetups make them seem like pseudo-organizations, and I'm not interested in that. And the feeling I get from the meeting announcements is that they're aiming for big crowds, but there only seem to be a few people actually signed up. It all seems a little off for me, so I never use it.

TableTalk sounded nice to me because it seems to be aimed at a smaller audience per meeting—the size of a table, obviously. And it feels like a one-time thing for each event without any unnecessary obligation, even if you do repeat the events. The demo app worked quickly as well.

It's planned for launch in a few weeks. I hope it goes well. I think it could go far.

On leaving well enough alone

This is a followup of sorts to this one: "My Recurring Nightmare" (15 Oct 2016).

On Friday, for our project 2 team in CS411: Database Systems, I needed to demonstrate the software we're developing to the professor via Skype. The project is to develop a program that can perform SQL queries on CSV files. On Thursday night, I had a version of the code that only had simple capabilities (a single WHERE statement on a single table), but it worked.

And what follows is where we get the saying: leave well enough alone.

Since I ended up taking a sick day from work on Friday, I spend some of the time trying to develop more capabilities in the code. Mainly, just trying to get the thing to accept multiple WHERE statements. Naturally, I broke something. And that something that I broke, well, it broke everything. At least before it gave some correct outputs for simple inputs. But after the "improvement": blank answers for everything.

And that's what I got to present to the professor. Laugh or cry—what difference does it make?

At least I got to walk him through the code and explain how it was working the evening before. And it didn't turn out too bad because the other project teams were also having problems, so another intermediate demo was scheduled. And I was able to get in there and, first, fix the thing I broke, and second, add the extra capability I was trying to get in there in the first place. So all's well that ends well.

That moment of terror an hour before presentation time, though, was the stuff of occasionally recurring nightmares about college. I was tempted to say I learned my lesson about fussing with things that are good enough, but I've lived in this head long enough to know that I'll do it again, and at the first available opportunity.

On GitHub, if you can work Python and would like to give it a try: SQL CSV ASAP.

Back to Los Angeles, December 2017

The version of me that spent three-ish years in the LA area may as well have been a different person. That's one of the refrains I use on myself to avoid thinking too hard about whether I'd prefer to be there now or not.

I used to believe in no regrets, but after some years I've settled more on not only regrets. It doesn't have the same ring to it, and it's not going to make the cut for a motivational poster, but after a few decades I can't image it's not OK to look in the rearview mirror sometimes and think, "Oof, maybe I should have turned there." The key is not to dwell on it. If you've figured that one out, tell me how.

Where were we...

Coming up in December: four days in the LA area. My wife and I are going to check in on the things we miss. Porto's Bakery in Burbank. Sushi Komasa in Little Tokyo. 金海餐厅 in Monterey Park. Pick up a Green Tea Mille Crêpes cake at Lady M. Dumplings at Din Tai Fung in Glendale. Oysters from the Pacific Fish Center at the Redondo Pier.

And others. If we can fit it in—fit in in the schedule, fit it in our stomach.

There are people there that I miss as well. Of course, there's never enough time for that. But we'll try.

There are other things in my memory from that time as well, but I don't know how to classify them. I only lived there in Burbank—lived as in having my own address— for about 15 months. But I was there for 42 months, though the first 24 were only half-time because I was traveling two weeks on/two weeks off for work. So my memory from the time is a mess of running trails and diners and bars and roads and bookstores. As snapshots, when they come uninvited to mind, the memories are so crisp and tangible, but as they pass they leave eddies in their wake, fouling the memory image so you wonder if the substance of the memory was ever there at all. It doesn't hurt. It's more of a curiosity. Like seeing a face you think you recognize, only to realize that it's a mirror.

Networking as a game

I used to be better at networking in college. Don't know why. I suspect mostly it was that I didn't have any agenda and it was fun to meet people—no pressure, no fear of failure, only action. And when you run an organization as a student, you can email anyone and ask them to come and make a presentation. If someone says no or the price is too high, you can ask someone else. I got Elon Musk to come to UI back in 2005. I didn't even watch his presentation. I sent in the other students helping run the conference and covered the registration table while they watched. The payoff was in the doing, not the receiving. It was fun to set it up and let it run.

So much for all that. Networking doesn't feel easy or fun now, perhaps because now I want the payoff. I feel like I need the payoff. That extra do-or-die pressure stifles the drive to even start networking and meeting people, never mind the execution.

I was considering that today and I thought: why not make it a game?

Indeed. Why not? Get past the stuckness and worrying by aiming at something else that accomplishes that same goal. It wouldn't really be a game, like a fun thing to play, but just a scorecard—do this, get some points; receive that, get some points; aim for a goal or high score every week. Get back to focusing on action instead of payoff.

What would the scoring parameters look like? What would the actions be? For a first cut, using easy to enumerate parameters, maybe...

  1. LinkedIn profile visits
  2. LinkedIn connection count
  3. LinkedIn post interactions
  4. Internal network connection count
  5. Internal network post interactions
  6. Outgoing professional contacts
  7. In person meetings
    1. What actions would get you there?

      1. LinkedIn profile visits --> Visit LinkedIn profiles (reciprocal visits); Post interactions (like, comment); Post in groups
      2. LinkedIn connection count --> Add more meaningful contacts (reciprocal adds)
      3. LinkedIn post interactions --> More meaningful posts
      4. Internal network connection count --> Add contacts (reciprocal adds); Post interactions (like, comment); Post in groups
      5. Internal network post interactions --> More meaningful posts
      6. Outgoing professional contacts --> Collect potential connections; Send emails
      7. In person meetings --> Send requests; Go to events

      Part of it is a game where you get points for an accomplishment, and part of it is an experiment: make a hypothesis about what you think will increase the score, design and perform a test, see how it affects the score. Observe the results, and roll it again.

      It feels a little pathetic to approach it like this, but what the hell? If it works, it works. I'll work on a version in my favorite prototyping tool, Excel (don't judge).

The erosion of definition

At work we're preparing for an upcoming customer review of our project. It ought to be a fairly standard thing, but after a program reorganization this year and last year, we lost a solid century of systems engineering experience to attrition and were organized under managers with a solid zero seconds of systems engineering experience. So: not ideal, but not impossible. There is opportunity in change.

Anyway, suffice it to say that it didn't work out like that. Selah.

One thing that came up in a dry run for the review presentation is that some of the values we were using to explain our status on the project (basically just what percentage of our work was completed) no longer made much sense. Over the course of the summer, they started to drift a little—which is understandable if your leaders don't know what the systems engineering status numbers mean. And that's just in the general sense—every program's definition of what done means is insane in its own way. With experience you learn to just deal with that, and try to stay on the top side of your board as the waves hit.

As the review approached, panic set in and the definition of done for required task statuses started to drift week to week, day to day, faster than the team's ability to digest the changes. The culmination was a series of review slides with new terms,
numbers that didn't add up. General confusion. Human sacrifice. Dogs and cats living together. Mass hysteria. I still don't understand how we're going to straighten it out.

Back up a step. Last year I started working on a side project to help the main project. I knew, from experience, that as the final review approached, there wouldn't be time to constantly calculate status, never mind do the harder, more abstract work of deciding what status means. That has to be worked out before you start the calculation. So I ended up writing a few thousand lines of code that could query our databases and tell us where we were, from the top level of doneness to the doneness of each individual thing we needed to do. It was the first real software project I had executed in my life—maybe my second or third favorite professional accomplishment.

First was arguing with teammates about definitions of done. And I mean arguing in a positive way—presenting my case about how things should be defined, and being right about some things and wrong about others, each convincing the other until a steady state was reached. I don't like to be told I'm wrong—hate it—but it's a satisfying feeling to relax and open up to the possibility and then believe it when it's true. And with code to lock in the definitions, the definition can be enforced. I can't believe that's not obvious. But some people prefer to run the calculation by hand ("by hand", well, by Excel, but not necessarily the same way every time).

But the downside of working in a stodgy industry is that code is magic at best, totally made up at worst. The new regime hated the idea of code. There was a separate division that handled tools. We can't waste our time with that. Real quote: I thought your code was just making up numbers.

It's all a little bit of drama, but the point is this: you should lay out definitions in an algorithmic form and get the team to buy off on them. If the customer doesn't buy off on them and want their own definitions—that's fine, it's just an interface to your own definitions. And, for the love of whatever you find holy, automate the things that don't need an interpersonal relationship. Make your own tools to do it, because you learn the nuances of the problem by making tools—definitions that appeared simple on the face can be recognized as their complicated selves when you have to work through all of the conditions. Besides, it's more fun to create than to consume.

Now reading: The Paris Review Interviews, Volume 1

It's not the first time I've checked out this volume of The Paris Review Interviews. I doubt it will be the last. I think I'll buy my own copy so I don't wear out the library's.

The interviews are fine literature on their own. They're mixed and edited and laid back down in an interview Q&A format to create a good story. It's how I imagine that I'd like to do interviews—although I don't know if that feeling came before or after being exposed to these. I think Cal Fussman does a fine thing with interviews in Esquire also: "What I've Learned". I suspect the average person would want to have an interview to be more like a transcript—sometimes I also want that, when I want the information as it was stated, like traceable bits of data for reference—but there are other truths in the material that can be only be found through refinement, like metal from an ore.

Anyway, I suspect I'll be posting some lines from the interviews here as I encounter them. They're too good to keep to myself.

From end of the introduction by Philip Gourevitch:

There is hardly a more enjoyable way to spend one's time, when not writing, than in the company of so much sheer intelligence demanding the best of itself.


From "Dorothy Parker, The Art of Fiction No. 13" (Summer 1956):

As for me, I'd like to have money. And I'd like to be a good writer. These two can come together, and I hope they will, but if that's too adorable, I'd rather have money. I hate almost all rich people, but I think I'd be darling at it.

There's a hell of a distance between wisecracking and wit. Wit has truth in it; wisecracking is simply calisthenics with words.

Database is not understanding, but a view of understanding

Following up on Human is not database, database is not human...

Regarding the horrible non-intersection of databases and people at work, there are two main examples that I see every day: (1) requirements database; (2) status data.

As a systems engineer, I manage our "what is this machine supposed to do anyway" specifications in a requirements database. Back in the day, this would have strictly been a document, with topics organized by numbered headers (referred to as paragraph numbers). Over time these paragraphs were atomized into sentences and pushed into a database, each sentence getting a requirementID number. You can roughly guess someone's age at work based on how much they insist on referring to paragraph numbers.
There's a part of me that used to think of this an anachronism—get with the program, old guys—because I was brought up in the industry strictly using the requirements database.

I don't think like that anymore. Something was lost in the conversion—not necessarily information about the system itself (we can build the same thing in either format), but an understanding of how the various parts cohered into a whole. Systems engineers get caught up in requirementIDs and verificationIDs and it doesn't mean much to the people who do the work. The design engineers humor us because they have to—it's the systems engineering accounting of doneness that the customer uses to determine whether the design is done. (For good or ill.) But ask the systems engineer what the requirements mean, or how they interact, or any of the technical details how how to prove that the design does what the requirements want, and too often you receive a stare that looks like one of those deep sea fish roused from its habitat by nosy human in a submarine.

Anyway: there is a better way to bridge that gap, to transform the light-reading descriptive information to the technical model information to the design status information. There are different views of the same data, if you want there to be. To do so requires more interpersonal work than technical work, really. But it's so much easier to disregard the people and give them simply what your database architecture was designed to hold. That's wrongheaded and I'm going to fix it.

Regarding status data... put briefly, there has to be a better, more humane way to communicate to management about the status of [insert here] that is neither too rigid for the status giver (no more forms, no more spreadsheets, no more databases, PLEASE), nor too loose for the status maintainer (the poor person who has to design the system for keeping the information) nor too incomprehensible for the status user (who will torment us all with eroding definitions of what they want when they don't understand what they've got). It all gets held in a database (an Excel spreadsheet mostly), but never gets translated well from that format. It feels—and is— rigid. Yet the definitions and implementations are sloppy, which is ironic, something rigid should be easy to define because by definition it's not very malleable.

Human is not database, database is not human

Seth Godin published an article recently that touched on something I've been thinking. And it gave me a phrase to steal to describe it. Machine Unreadable.

Databases are useful. I use them every day. I'm taking a class to learn how to use them well, to do more sophisticated things with them. But they're not for all things.

At work, an important point that is often forgotten is that people are involved in the work. Information gets jammed into a database whether it belongs there or not, and that information, even though it might be complete and correct, can become incomprehensible—incomprehensible to a reader, to a user, to a maintainer.

How often at work do we load up a spreadsheet with a database output, fuss with the colors and borders a bit, and then send it off to an unwitting person to fill the rest in? Too often. And the table doesn't mean anything to the person that receives it. It barely means anything to us who own the data. But the Word of the Database is Law, especially to the managers who summarize it for the Holy Powerpoint. It is spoken of authoritatively in hushed tones. It is mysterious and awesome. It is bogus.

I wish we spent more time thinking about what the data means—especially to the people we share it with. I think it's a mark of distinction when a person asks, "Why are we doing this?" when we send data in an esoteric format that is destined to be ignored or misunderstood. (Which one is worse?) If we want to solve problems, we—the data and database owners—ought to feel more responsible for being understood. At the very least, it's the humane thing to do.

I could riff on this for a while. It's something that gives me fits at work. The idea, if not the implementation, seems so simple and obvious: translation. If not everyone can or wants to use the central information in the same format then it's silly to do that. Like language translation, some might be formulaic, some might be art. Whatever the case, spare a thought for the humans involved.

Follow up: Database is not understanding, but a view of understanding...

Resurrecting another alumni club

Last year it was the St. Louis Illini Club, the local University of Illinois alumni group. (More action on the Facebook page, actually. Nevermind that UI is the alma mater of Andreesen, Levchin, Ozzie, the university decided on some garbage software for the alumni clubs.) A group of about eight of us took a moribund club and flipped it.

This year, it's the International Space University USA alumni club. After a few years of disrepair, it's time to put that one back together as well. I ran it with some friends back in 2009-2010, but it has since drifted into inactivity. No one was running it, so... why not me?


Why #1: Why do these things fall apart?

Why #2: Why do I like putting them back together again?

The second one is easier. It's fun. It's fun to organize people. It's fun to connect people. It's fun to fix things up. There's some utility—get to meet people, create opportunity—but I'm not even that interested in using the opportunity for myself. That's all. And for me it fills in something I don't get at work—getting to lead and organize and strategize and execute. Without it, I'd go crazy.

The first one is easy and hard to understand. Easy: people get busy. Kids, work, etc. It happens. Hard to understand: responsibility is responsibility. If you stand up for something, you should finish the deal. I'm 100% on that either. But the point stands: when you're being counted on, you must close.

There's one more reason I like putting together organizations even more than creating a new one. It's the... archaeological element to it. Find an organization that is interesting, functionally dead but some of the physical (or digital) ruins are still there. Dig through the pieces, try to understand what the people who came before you were thinking, what they were feeling, what they were hoping to accomplish when the invested their time and energy in the organization. Find and save the traditions. Create new ones. Draw a line from where they were to where you are and on into the future. Creating and recreating.

But again, mostly, it's just fun to do the work.