Liss is More
By Casey Liss
True Development is Boring

Your favorite snowman and mine, Dr. Drang, has responded to Brent Simmons’ observation that software engineers don’t really have a code of ethics. Certainly not like traditional professional engineers from old and boring tangible disciplines like civil engineering.

In his post, Dr. Drang makes an observation:

Not that long ago, Daniel [Jalkut] couldn’t be a licensed engineer, because there was no licensure procedure for software engineers, but that changed a couple of years ago. Now there’s a licensing exam for software engineering, although I don’t know how many states currently accept it.

…which he follows with a question:

(I am, by the way, curious what programmers think of the topics covered by the exam.)

I’m a programmer software engineer, and I’m happy to weigh in. But first, a diversion.

When I landed my first job out of college, I was writing software that ran bingo games that masqueraded as slot machines. When I arrived, I immediately realized that despite graduating from a top-10 public undergraduate engineering school, that I had no clue how to write software. We were using crazy things like “source control” and “issue tracking software” that I had never heard of before.

I had to learn quickly. I had to take all the theory that I learned in school and turn it into practical knowledge.

Fast forward a couple years and I’m working for a defense contractor. The firm was, at the time, CMMI Level 3. That means, in short, that we were pretty good at writing software reliably. Our estimates were nearly always on the mark, and our releases were nearly always bug-free.

Here again, I had to learn quickly. I had to learn how to be a good participant in code reviews — both as a presenter and as a contributor. I had to learn what a quality assurance department was, and how they are friends, not foes. I had to learn that, in that environment, waterfall is your friend.

With this knowledge in mind, that brings me back around to Dr. Drang’s question: what do software engineers think of the topics covered by the exam?

I think they make perfect sense, and I like them.

The topics were clearly written from the perspective of someone who takes software engineering seriously. Not the fire-from-the-hip startup world, where failure is an option. Instead, this was clearly written to encourage real, true, software engineering. Development that is predictable and reliable. This is abundantly obvious in the first 10 lines of the topics list:

I. B. Requirements elicitation
I. C. Requirements specification
I. D. Requirements analysis
I. E. Requirements verification
I. F. Requirements management

Perhaps I’m allowing my perspective to be skewed by a career mostly in consulting, but these topics being part of a software engineering exam makes me smile.

The catch about software engineering — about development in general — is that to be a great developer is to be great at the un-sexy stuff. To be a great software engineer is to be great at the entire process of writing software. It begins with defining the problem, and flows all the way through ensuring changes to a deployed system do not break the system:

VI. C. Configuration status accounting
VI. D. Release management and delivery

In this environment where the new and exciting are fetishized so heavily, the reality is that writing code that’s “boring” is actually a good indicator that you’ve done your job well. Having a sign like this, while funny, means we’re probably not doing our jobs right.

Speak Beautiful

Dove ran an ad before the Oscars that I was glad I happened to catch:

The cynical man in me says I shouldn’t be celebrating a commercial. Really, though, I’m just happy to see the message get out.

You are beautiful.

Gold Ain't Cheap

Matthew Panzarino of TechCrunch retweeted a couple interesting tweets about the Apple Watch last night:

This corroborates the rumblings I’ve heard about cost.

Not long ago, I remember just having an iPhone could be construed as a status symbol. The Apple Watch will be taking it to a whole new level.

Behind the App 
  ⚓

One of the disadvantages of having such smart friends is never knowing when they do great work.

When John writes an amazing OS X review, is it really amazing? Or am I just biased because John is my friend?

Is Overcast actually good? Or do I just really like Marco? Or maybe I just really like orange?

Are the retrospectives Stephen, Federico, and Myke did, for the iPhone and iPad, truly impressive and deserving of our praise? Or do I just find their unique accents so adorable?

I hope and suspect the answer to all of the above questions is “yes”.

When Myke sent me a pre-release version of the new Inquisitive, I was immediately floored. Myke has brought a level of research, discipline, storytelling, and polish to tech podcasting that I haven’t heard before.

Myke is a dear friend. We share a podcast together. I’m predisposed to like everything he touches.

Despite all that, I’m completely confident when I say Inquisitive: Behind the App is good. Really good.

Eschewing his previous interview/profile format, Myke has started Inquisitive anew, taking it in a very different direction. The first series is about making apps in today’s app-obsessed world. There are plenty of interviews in the episode, and perfectly tell the story that Myke is setting up.

It’s a neat and welcome change for me to hear all these voices in one show. As an exclusive listener of one-to-three-host podcasts, Inquisitive sounds so delightfully different to me. As an occasional listener to This American Life, I was very much reminded of that format and editing style. Given This American Life is one of the most popular podcasts on the planet, that’s quite a compliment.

I’m really impressed with the new Inquisitive. Not just because Myke is a friend, but because it’s damned good programming. If you’re a fan of ATP, you should really like it. If you’re not a podcast listener, Inquisitive is a wonderful way to dip your toe in the water. You won’t regret it.

Scenery

Yesterday The New Yorker released a phenomenal profile of Jony Ive written by Ian Parker. Well worth the very long read, I could quote so many portions of the piece.

These quotes related to cars deeply appealed to my inner gearhead:

[Ive] and Newson are car guys, and they feel disappointed with most modern cars; each summer, they attend the Goodwood Festival of Speed, where vintage sports cars are exhibited and raced in the South of England. “There are some shocking cars on the road,” Ive said. “One person’s car is another person’s scenery.” To his right was a silver sedan with a jutting lower lip. Ive said, quietly, “For example.” As the disgraced car fell behind, I asked Ive to critique its design: “It is baffling, isn’t it? It’s just nothing, isn’t it? It’s just insipid.” He declined to name the model, muttering, “I don’t know, I don’t want to offend.” (Toyota Echo.)

Later:

Jeff Williams, Apple’s senior vice-president of operations, drives an old Toyota Camry. Ive’s verdict, according to Williams, is “Oh, God.”

Apple Building Their Own Car?

The Wall Street Journal is reporting that Apple is working on their own electric car:

Apple has several hundred employees working secretly toward creating an Apple-branded electric vehicle, according to people familiar with the matter. They said the project, code-named “Titan,” has an initial design of a vehicle that resembles a minivan, one of these people said.

I’m pretty skeptical. If this does happen, I know who is having the last laugh.

Perspective 
  ⚓

When I first started doing ATP, I wasn’t really prepared for the amount of feedback I’d get. Some of it was funny — who the hell is Casey, anyway? Some of it, though, was really harsh. Some days it feels like everything I say is critiqued or criticized somehow.

It can hurt after a while.

What I have to deal with, though, is not even in the same universe as the hatred that some people face. These people, almost universally women, are ridiculed, ostricised, and even threatened, simply because they are women with opinions.

What Brianna Wu (among many others) has gone through is not only stupefying, but also terrifying. I don’t know how she has the will, the tenacity, and the stamina to continue to fight every day. To continue to fight for something that should already be a given. To continue to fight for her right to be a woman with an opinion.

Take a few minutes out of your day and read her piece at Bustle. It’s well worth your time.

Small Hurdles

Last night I added native post-to-Twitter support to Camel. In and of itself, this is not particularly remarkable. However, the path to get there is an interesting example of how developers work, and how one small change can create some significant ripples.

Genesis

Everything started with me deciding to add the ability to make link posts to Camel. That went smoothly and, at first glance, didn’t create any further problems. Until:

I needed to do something to fix this.

Diversion #1: RSS Modifications

Thus, I did what was recommended, and I had seen a zillion times before. I modified the RSS generator to set the URL of the post not as my own site, but instead the target of the link post. All seemed well.

Then I made a second link post and realized something else was amiss.

A New Problem

At the time, I was using IFTTT to automatically tweet when I make new posts to this site. That was working perfectly, until I made that change to how the RSS worked. Notice the difference between this tweet, which was before the change:

As compared to this tweet, after the change:

You’ll notice in the latter tweet, the link is to the external URL, not to this site. This is a change from how it was before I adjusted the RSS feed. Unfortunately, I preferred it the old way.

I was now at an impasse — I could either have RSS work the way I want or Twitter work the way I want. At a glance, there was no way to tell IFTTT to use a different URL for what it posts to Twitter.

Diversion #2: Creating a Twitter App

Most of the motivation for using IFTTT was to avoid having to write my own Twitter client into Camel. I didn’t want to do that specifically because I wasn’t sure how the OAuth flow would work. The idea was for Camel to autonomously post to Twitter; I had no intention of building a login flow just for that.

As it turns out, I had made a poor assumption.

When creating a Twitter application (which is to say, asking Twitter for the ability to access its data programmatically), you can actually get the requisite OAuth tokens by hand for the account that created the application. So, I created an application off of the @caseyliss Twitter account, and was able to mock something up using the twitter package for Node.

However, since I created the app off of my Twitter account, it could only post to my account. Now that I had things working, I need to create a Twitter application off of the @caseylisscom account, so tweets would be posted from there. That should have been easy, until I ran into this:

Twitter Error

At a glance, this is no big deal. Until I remembered that my phone number is associated with my @caseyliss account. Unsurprisingly, Twitter only allows a phone number to be used for one account.

Diversion #3: Getting a Burner Number

Most people need a “burner” phone number to do nefarious things. Perhaps they’re trafficking illegal items. Perhaps they’re running around on their spouse.

Me? I’m trying to get my blog to post to Twitter.

I wasn’t sure how to go about getting a burner number that can receive text messages. I asked on Twitter, and got a few responses. Most immediately jumped to Google Voice, but others pointed out that Google Voice can’t receive messages from short codes. So, that was a non-starter.

By the magic of Twitter, though, I did get the winning suggestion:

I quickly checked out Burner, and it looked promising. I downloaded it, set up a number for free[1], and plugged that into Twitter. It sent me a confirmation code, which Burner received no problem, and I was up and running.

A New New Problem: Determining When to Tweet

The next obstacle was determining the right time to tweet. Camel doesn’t have any sort of database, and Heroku has an ephemeral filesystem, which means I can’t just save a record of the last post that has been tweeted. Thus, the only reliable way to figure out what has been tweeted is to look at the tweets of the account itself. In my case, that meant inspecting @caseylisscom’s tweets.

Though I very rarely write tweets by hand from @caseylisscom, I do on a rare occasion. Thus, it wouldn’t be as simple as just grabbing the most recent tweet, or even the most recent tweet that had a URL associated with it. I needed a reliable way to determine when Camel itself had tweeted last.

The easiest answer? Look for tweets posted by the just-created Twitter app that Camel uses.

The general idea is, Camel looks at the most recent tweet posted using “Camel Spitter” (the aforementioned app) has made. Once it finds the most recent auto-tweet, Camel looks at the URL on that post, and sees if it matches the URL of the most recent post within Camel. If not, Camel will fire off a new tweet for that post.

Diversion #4: Deployment Issues

At this point, I had:

  • A RSS feed that points to the external link when the post is a link post
  • A Twitter app unique to my website
  • Code to automatically tweet when a new post is posted

I had everything I needed, so I went ahead and deployed the changes to Heroku. Which didn’t work:

module.js:340
throw err;
      ^
Error: Cannot find module 'Twitter'
	at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/app/camel.js:21:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)

Uhhhhhh… what?

After doing a bit of trial-and-error, I realized that my Mac’s file system (🔔) is not case-sensitive, but the one Heroku uses is. Thus, this line:

var twitter = require('Twitter');

Just needed to be changed to:

var twitter = require('twitter');

And everything was right as rain.

Turns Out

None of the actions above are particularly remarkable, but what made it interesting to me is that a seemingly innocuous change — adding the ability to create link posts to Camel — caused quite the avalanche of random changes and issues.

Despite all the pain, Camel is now considerably more robust than it was just a week ago. I’m extremely happy with where it’s ended up. The challenges were, well, challenging, but that’s exactly what makes software development so much fun.

When the dust settled, after all that work, I got this:

…and I couldn’t be happier.

  1. Burner gives you 60 free text messages & 20 free minutes when you install; it’s an in-app purchase to get more. ↩

Top Gear Aftermath 
  ⚓

I’ve long wondered what happens to the cars that the hosts of Top Gear drive once they’re done with them — particularly so for cars they drive on foreign soil. In the past, I’ve noticed some of them end up in the studio, but not always. What happens to the others?

Someone has posted pictures of Richard Hammond’s Bentley once he was done using it in the recent episode in Australia. From the link:

By the end of this episode the cars still worked perfectly, although they suffered minor cosmetic damages.

After looking at these pictures, it’s clear that not everyone has the same definition of “minor damages”.

Link via Top Gear Box

Camel Gets Link Posts 
  ⚓

A couple of important changes to Camel, for those that are using it, or are considering doing so:

  • Support for link posts such as this one.
    • Click the hand to follow the link
    • Click the anchor to get a permanent link to this page.
  • Significant cleanup of the post rendering logic, so it’s not… well… insane.

I was pretty embarrassed about how rough the post rendering logic was. It was a mess of seemingly-redundant functions with hard-to-differentiate names. Now, the process is much simpler and thus much easier to follow, extend, or debug.

When I originally wrote Camel, I had really thought about supporting link posts, but I wanted to force myself to have something to say. I didn’t want this to just be a dumping ground for links I find — that’s what Twitter is for. Now that I feel like I’ve established a voice for myself and this website, I went ahead and added support for link posts.

Naturally, all of these changes are on Github, save for the settings to use emoji as the link/anchor indicators. I’m not even sure I’ll stick with those, but I wanted to try something other than ∞ and →.

« Newer 
» Older
Copyright © 2014-2025 Limitliss LLC