Missing The Mark

Missing The Mark

By | | Comments 0 Comment

Yesterday I made a broad claim about the applicability of various subjects to the task of software development. Today I want to give a specific example from the realm of theology.

The notion of sin is foundational to a number of world religions. Without belaboring the details or arguing the validity of any one definition, what cannot be disputed is that humans have been wrestling for a long time with their own limitations. Why is it that none of us are able to live up to our own ideals, let alone the ideals of a faith tradition? Why must it be that “nobody’s perfect”? To quote Saint Paul,

I do not understand my own actions. For I do not do what I want, but I do the very thing I hate . . . I have the desire to do what is right, but not the ability to carry it out.

Great stories confront us with the fickle imperfections of human nature as well. Is not human frailty and the conflict that arises from it the very foundation of an epic tale? Nothing proves this truth quite like “fiction”.

What does this have to do with software? Let me repeat myself: software is made by humans, and the results are subject to their constraints. That means you can expect both errors of omission and commission, and both unintentional mistakes (e.g. a developer fails to adequately review code) and deliberate laziness, cheating, pride, etc. One certainly hopes for few instances of the latter, but they do happen. It’s not just time you have to plan for.

A process must be designed to recover from its own imperfect implementation, else it is doomed to fail.

Like Eating Your Vegetables, But Better

Like Eating Your Vegetables, But Better

By | | Comments 1 comment

Good software engineers read. And not just technical blogs or books on coding, but on all manner of subjects. Politics, mathematics, philosophy, science, history, and theology have much to contribute to the work of professional software development. But even more important to cultivating a healthy creative mind is the reading of fiction.

Maybe it’s just me, but I feel that a rich diet of fiction has fallen out of favor in our culture, especially in contrast to the consumption of technical information. That’s unfortunate, for stories have a unique power to shape the mind. For me, classic science fiction in particular has inspired me to consider how technology can be of benefit to humanity, and warned me of ways it might be a danger. No O’Reilly book is going to tell you that.

While I’m on the topic, can I say how much it bothers me that we categorize books as “fiction” and “non-fiction”? Those are horrible labels. Novels and other stories can communicate truth in a myriad of ways, and it’s quite possible for non-fiction to be either mistaken or outright false. If you tell me “I only want to read things that are real, not fake” I will absolutely make fun of you. Consider yourself warned.

Writing On A Saturday?

Writing On A Saturday?

By | | Comments 2 comments

Show yourself grace, but get back on the horse as soon as possible, right? Fortunately I happen to have some free time this morning. Did the breakfast dishes while listening to some Pink Floyd, which took me right back to high school when I was an obsessive fan (circa “The Division Bell”). It got me reminiscing as well about the various kinds of software development I’ve done over the years. Here’s some significant milestones:

  • Age 4: Dad buys our family its first computer, a TI-99/4A
  • Age 5: Someone gives me a green paperback with a bunch of Basic programs; I spend hours typing them into the computer and figuring out how to print the American flag in ASCII characters, among other things
  • Age 7: I’m a regular at the local library’s “programming” section, and start writing simple games (still on the TI computer, and still all in Basic)
Early code sample
Based on where I found this at my parents’ house, I’m guessing age 8
  • Age 9: My first upgrade: a Tandy 1000 TL/2 from Radio Shack; within a few days of having it at home I inadvertently format the boot disk, bricking the machine
  • Age 10: Now having the ability to save programs to floppy disk, I get pretty into QuickBASIC, especially fiddling with the game Gorillas
  • Age 11: We upgrade again, to a Tandy 386, with an internal hard drive and VGA graphics; somehow my parents think it’s a good idea to put the computer in my bedroom
  • Age 12: I teach myself C, and begin memorizing powers of 2 (up to 65,536) and digits of Pi (3.14159265)
  • Age 14: I take a correspondence course in Pascal, where I learn legitimate structured programming; lacking email or the Internet, I printed out code and mailed it to my teacher
  • Age 16: Wanting to keep a secret journal, I write an encryption algorithm (a substitution cipher that would have worked reasonably well had I not used Pascal’s built-in pseudo-random number generator); but it was enough to keep my sister out
  • Age 17: The Internet happens; “hijinks” ensue of which I will speak no more
  • Age 18: Now running a Pentium 2, my dad comes home from work to find I’d completely disassembled the machine; he was not pleased, but I put it right back together again without issue
  • Age 19: I take my first college course (C programming); it was interminably boring
  • Age 20: VisualBasic comes so quickly to me that I finish the entirety of the class’s projects in a couple of weeks; I was so brazen I told the professor I had no intention of coming to class the rest of the semester except to take exams (still got an A)
  • Age 21: Compilers, number theory, combinatorics, and linear algebra give me all kinds of new programming ideas; I spend gobs of my free time optimizing an algorithm to compute the largest possible determinant of an nxn binary matrix
  • Age 22: I write a Monte Carlo Simulation to determine if there’s an advantage to having the first turn in Monopoly (spoiler alert: there is); I also get hired by TRW
  • Age 23: My boss hands me a book on Ada and tells me I have 2 weeks to learn it; I do so by porting a bunch of my college work, in particular a Number Jumbler solver
  • Age 24: During my time at graduate school I make side money doing LaTeX typesetting
  • Age 27: Now back at Northrop Grumman, I build an algorithms doing terrain analysis and flight path optimization (still in Ada)
  • Age 28: Ada goes the way of the dodo, and I’m porting stuff to C; I’m also starting to get into mapping software and learn the “right” way to compute distances on the Earth’s surface
  • Age 29: I write my favorite single piece of code ever (ask if you’re curious)
  • Age 30: My first visit to San Diego, where I give a presentation on my flight path algorithm
  • Age 31: I spend way too much time working on a huge proposal that we end up not submitting
  • Age 32: We move to San Diego and I get my first taste of technical leadership; I also start learning the basics of HTTP API design
  • Age 33: Thinking of making a job change, I go to my first interview since college; it does not go well, and I decide to take a couple classes on web development at SDSU to beef up my resume
  • Age 34: I convince my management to buy an 84″ touchscreen for our mapping application; we make the interns assemble the stand
  • Age 35: After nearly 13 years, I take my second job at Everyone Counts who I somehow tricked into believing I knew Java (which I’d learned in college but hadn’t seriously used since)
  • Age 36: I mistakenly reveal I took a class in Perl at SDSU, which I eventually use to become the technical lead for the company’s voting application
  • Age 37: It’s a year of learning, as I get a Code School account and get smart(ish) on Angular, Node.js, and Docker, among other things
  • Age 38: I revive this blog and decide to write a bulleted list of my history of software development

Well, that was fun (for me, at least); I probably could have doubled the length, but I’ve already spent too much time on it. If you’ve read this far, I thank you!

Babies With Great Personality

Babies With Great Personality

By | | Comments 0 Comment

Yesterday I was speaking with a fellow engineer about the state of our new user interface implementation. We’d crossed a major functionality threshold, but there were still several obvious bugs. I argued that the significance of the functions that were working merited deploying to our integration server for others to see, but he resisted saying that he’d rather wait until a couple of the blatant problems were ironed out.

The above is a common conundrum for developers. Put your work out there for others to see too soon, and they’ll be quick to point out all the flaws. Wait too long, and managers start breathing down your neck because they’re not seeing tangible results.

Personally, I think the wise manager understands the idea of a work in progress, and should appreciate seeing said progress without getting overly critical of early blemishes. It’s a bit like posting photos of a newborn baby. Obviously everyone loves their little nugget, but reality is most newborns aren’t super cute in their first couple of days. But would anyone ever dare point that out to proud parents? Let’s surely hope not! The birth of a child is a momentous event to be celebrated; there’s plenty of time later for the kid to grow into his adorableness.

Likewise a software application. Publish early, and let that baby grow!

The Fire In Which We Burn

The Fire In Which We Burn

By | | Comments 7 comments

Everything takes time.

  • Reading and responding to emails takes time
  • Checking Slack takes time
  • Updating JIRA takes time
  • Peer reviewing code takes time
  • Writing documentation takes time
  • Managing versions and branches takes time
  • Meetings and discussions take time
  • Keeping a workspace organized takes time
  • Updating a computer takes time
  • Addressing HR concerns takes time
  • Performance evaluations take time
  • Eating lunch takes time
  • Going to the bathroom takes time
  • Mental breaks take time
  • Thinking takes time

Plan accordingly (which also takes time).

Day Off

Day Off

By | | Comments 0 Comment

I’m taking a day off from writing today. See you tomorrow!

(Yes, I understand the irony of this post)

Toaster Apps

Toaster Apps

By | | Comments 2 comments

Developers may like to write software, but that doesn’t mean we want to fix your computer (or even know how to fix it, for that matter). Nevertheless, we’re often asked, and sometimes try. A former co-worker of mine used to complain about his neighbor’s constant IT requests. “Toaster Lady” he called her, because she’d say “I want my computer to ‘just work’. Like a toaster.”

There’s a lot for those of us in the software industry to unpack in a statement like that. In particular, I was reminded this weekend that getting software applications to the point where they “just work” can be incredibly difficult.

Part of this relates to the phenomenon of simplicity that I’ve written about before. It takes effort to design interfaces that are both simple and functional for a broad range of users. And there’s a temptation to put aesthetics before all else. Resist it (and read Don Norman’s seminal work on the subject).

Implementation of a simple design is not simple. In fact, it’s often tougher to build code that does simple things well, because nothing is simple with computers. Beneath the Google search box lies an unimaginable stack of data, algorithms, networks, and hardware, all of which works together in concert to find that perfect cat video. It takes an army of people to keep it all running (because everything is always breaking all the time). Not to mention the even larger army of people who designed the individual elements, who could only do so because of the work of even more people whose research and ingenuity gave rise to computing machines in the first place. Simple search? Ha, there’s no such thing.

And the work required continues to grow exponentially into testing. All possible permutations of use cases must be tested to flush out potential problems. Have two buttons? Well, that’s four tests. Add a third, now you’re up to eight tests. Oh, and even that isn’t covering that one weird case where if you press the same button fifty times in a row and then hit button three the software crashes. Now expand that to a box with arbitrary text input? The possibilities are staggering (but not endless; there’s a big gulf between large and infinite, but that’s a post for another day).

Consider all of this next time your technology fails you, and be thankful that it ever works at all.

Lesson Learned

Lesson Learned

By | | Comments 0 Comment

When you’re cross-posting your writing to five different social media channels, it behooves you to proofread, especially that first sentence.

Thinking In Future Tense

Thinking In Future Tense

By | | Comments 0 Comment

Last night I was reading an article on characteristics of a good startup, and this nugget jumped out at me (it was originally said by Marc Benioff):

People overestimate what you can do in a year and they underestimate what you can do in a decade.

Software folks tend to be impatient for success, perhaps fueled by seeing the lucky few like Mark Zuckerberg who achieve near-instant greatness. The temptation of moving around to chase pay increases is also ever-present. And it’s really easy to get tired of a particular project at about the 80% complete mark and leave it unfinished (that’s worth a post all its own).

However, great products and great companies almost always take time to develop. And deep satisfaction awaits the person who, through years of toils, takes an idea to completion or builds a fantastic engineering culture. When I was (finally) looking for a change after 12 years at one place, why did I turn down offers from the typical dream companies? Because they’re essentially solved problems, and the chance to make a long-term transformation is minimal.

My current workplace is far from perfect. Without a doubt it’s been more challenging than I expected since I started 3 years ago. But I’m learning to be patient. There’s no guarantee of success, but if it comes, I know it’ll be more satisfying than if it had come quickly.

It reminds me of a story I heard from Andrew Peterson of the designers of Central Park. Told briefly, the folks who planted those first trees knew they would never even see the fruits of their labor, since a generation had to pass before their landscapes could mature. But what a result it was! That kind of patience inspired a great song and it inspires me as well.

Sidenote: the title of this post comes from a book I snatched from the free table outside the library at Judson Baptist Church in Nashville. I highly recommended it (the book, not the church).