Dive Deep – Page 6 – Making Of Things

Writing On A Saturday?

By Jud | May 6, 2017 | 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!

The Fire In Which We Burn

By Jud | May 3, 2017 | 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).

Toaster Apps

By Jud | May 1, 2017 | 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

By Jud | April 29, 2017 | 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.

The Other Full Stack

By Jud | April 25, 2017 | Comments 0 Comment

Typically when a software person says he is “full stack developer” what is meant is “I can do UI, business logic, and databases.” All well and good, those kind of folks are important to have around.

But there’s another dimension to development that I consider even more useful. Let’s call it the “life-cycle stack”:

“I can write requirements, design, implement, test, deploy, and maintain.”

An engineer who can do everything across that spectrum is tremendously valuable.