Category Archives: Software Development

Trying to Tell Stories

My instinct in writing is to just say what I believe to be a true or interesting in a direct way. Maybe give an argument or two why and call it day.

So, most of what I write is kind of like this: “Hey everybody, I think blah blah blah and one time I blah blah blah’ed and yada yada yada, it was great. You should blah blah blah too.”

And even as I’m doing this and re-reading my writing, I am thinking: “this is kind of boring”, but I didn’t know how to make it better. So I’ve plugged along because up to this point, I’ve decided that writing imperfectly is better than not writing.

But, today, (March 5th, the day I am writing this), is my first day as an independent software developer, writer, or whatever I end up doing. I don’t have the safety net of gainful employment to give my work meaning. It somehow has to come from me and my own projects.

And this blog is one of those projects, so it’s not enough to just write any more. Eventually, this blog has to be good, which I define as valuable to readers (as opposed to just valuable to me as a place to practice writing).

Over the years, I have seen/read/heard a lot of advice about writing, but one really stands out to me right now, and I am trying to really understand it.

It was a podcast episode of Scriptnotes (transcript), where Craig Mazin, the writer of the Chernobyl mini-series, explained what a story is. I recommend reading the whole thing, but the essential generator of story was an argument. This interests me because most of what I am writing is my side of an argument.

According to Mazin, to generate a story, you start with an argument with a true side and a false side. Then, you create a character that believes the false side and lives a stable, but imperfect life with this belief.

The story will make that stable life impossible and eventually change the character’s worldview such that they act in accordance with the true side of the argument. The details are fascinating, and I recommend you read the transcript (the back episodes are available on a paid subscription if you want to listen to it).

One way to sum it up is:

What is more interesting: “you know, if you lie to people, they might not believe you when you are telling the truth” or The Boy who Cried Wolf?

The first example is just advice (which is actually good advice, but it’s boring) and the second is a story. It has humor, it has twists, and it has an argument exemplified by a character living the opposite of the advice. It’s not exactly the same structure as Mazin’s, but it works.

Craig Mazin writes fiction, and a lot of what he’s describing is story invention. But, it applies to non-fiction as well (see his José Fernandez example). And, of course, if I think back to interesting non-fiction books I have read, they are full of stories.

But, I also know that long-winded stories (when you want actionable advice) are somewhat off-putting to me. I personally need to find the right balance.

In my own journey of “Stating advice directly, but in a somewhat boring way” to “Telling an interesting story that incidentally makes my argument”, I am really just getting started, but I will try to tell more stories of characters living the false and true sides of arguments I am making rather than just plain descriptions of the argument.

Accessibility First in Podcasts

I released a podcast a few days ago. I am doing this podcast partly to improve my writing and my ability to do Professional Performances, so it is scripted.

A side benefit is that it doesn’t take much to produce a transcript. In fact, I have a pretty good one before the podcast is even recorded.

Aside from accessibility, transcripts have many other benefits. SEO is a big one, but also, it makes it a lot easier for listeners to refer back to. And if they feel inclined to quote you on social media, it makes it a lot easier.

In any case, I’m glad that my process produces the accessible artifact first.

I Didn’t Have a Disk Drive

When I was 13, my mom got me an electric typewriter for Christmas. Luckily, it was broken, so we went back to Radio Shack to return it. When we got there, they were trying to move TRS-80 Color Computers for about $50 (the same price as the typewriter).

So my mom got me a 4k, chiclet keyboard version that hooked up to a TV. There was no storage included, but supposedly you could hook them up to ordinary tape recorders (I never figured this out).

The next Christmas, I got a Commodore 64, again with no disk drive. I finally got a disk drive for my birthday a few months later.

For a while, my home computer could literally do nothing except be programmed.

All of my personal programs lived on paper. I typed them in, played with them a bit, and then re-transcribed them back to paper. My most ambitious program in this time period was a very light Defender clone made from ASCII art.

It was like learning a musical instrument.

If I were learning piano, I would play songs over and over until I got them right. If I could compose music, I’d do it on paper and retranscribe often.

And doing this did at least accomplish the goal my mom had with her original gift. I learned how to type pretty fast.

Tech Career Tip: Drive Revenue, Not Cost

I have spent most of my career in software product development, meaning the code I wrote went into the products that made money for the company I worked for. I did a short stint writing internal software for the organization itself and the difference was very stark to me.

When you write software for your organization, it’s often to automate something and the driver is cost-reduction. The problem is that cost can only be reduced so much and eventually you are one of the biggest costs (in a budget owned by someone who likes to cut).

Revenue, on the other hand, can be very outsized compared to your cost. The budgets for product development are often expressed as a percent of revenue, so success increases budgets.

And, often, product development jobs offer some way to participate in that upside (options, RSUs, etc). Getting equity from an IT developer isn’t as easy.

It’s more complex than just “for-sale” or “internal”. When I was in FinTech, I wrote products, but my peers at banks, writing internal software, certainly drove revenue for their employers and were paid very well through generous bonus systems.

Pay is not the most important benefit. When you are critical to how a company makes money, you have bigger growth opportunities, more respect, and generally more clout. Product developers at software product companies have career prospects that lead all the way to CEO. That is not often the case for developers automating internal operations.

Make a Test Build of Your iOS App to use with Appium

I just published an article on App-o-Mat to show you how to create test builds from the command-line to use with Appium.

When you make GUI tests using XCUI directly in Xcode, it will automatically build the app for you when you run the test. Appium, however, is run completely outside of Xcode, so you must supply a build for it. The best way is to build from the command-line so that can control where the files end up.

This is the second in the series of how to write test scripts for iOS apps using Appium.

Excel as a Programming Language

Spreadsheets were a formative element of my introduction to programming. I learned them while learning programming and ideas from each influenced my understanding of the other. Generally, since I programmed a lot more, I tended to think in how a standard structural/imperative language would do things, and my spreadsheets started to have more and more complex macros.

Looking back though, what is interesting is that most spreadsheets are a pure functional system. I would say that Excel is the most deployed functionally programmed system. The biggest impediment of an Excel pro to learning conventional programming might be understanding the stateful, imperative, mutating model in the most common application programming languages and frameworks.

For example, if Excel were a programming language, you might say something like

A1 = 3.0
B1 = A1 * 2.0
A1 = 4.0
print(B1)

And you would naturally expect this to print 8.0.

The way to write it is more like this (in Swift)

var A1 = { 3.0 }
var B1 = { A1() * 2.0 }
A1 = { 4.0 }
print(B1())

This prints 8.0 as expected.

In other words, all cells are functions, not expressions or constants. Excel just simplifies your code by wrapping them for you.

Another way would be to use reactive programming, like Combine

let A1 = CurrentValueSubject<Double, Never>(3.0)
let B1 = A1.map { $0 * 2 }
A1.send(4.0)
B1.sink { print ($0) }

Simple, right? It is more in the spirit of what is happening in Excel and lets us use constants instead of variables.

It’s no wonder Excel is popular.

Excel is Programming

When I was in High School, I had a job in the accounting department of a non-profit. This was the mid-eighties, so a spreadsheet was a giant piece of green paper with cells drawn on them. The department had a mainframe and used computers to process invoices, but a lot of accounting work was still done on paper. I helped file that paper.

At some point, they got a couple of PCs and they installed Lotus 123 on them, but no one was really using them. They knew that I was into computers, and so they asked me to transcribe the paper spreadsheets to Lotus 123 as more of a data-entry clerk.

This work was a seed which grew and grew. At some point I discovered SUM and showed it to someone. I learned more about formulas and built spreadsheets that could auto calculate when the underlying numbers changed. You know, spreadsheet stuff.

By the time I left, my spreadsheets made extensive use of macros and more complex formulas.

In a very real sense, those spreadsheets were programs, and learning how to do that alongside with learning how to program made me better at both.

I think that a lot of people that are good at Excel could learn how to write conventional applications if they wanted to. Even if they aren’t currently writing macros, the main ideas of cells, formulas, range processing, grid-layout, and styling map pretty cleanly onto application software concepts.

Programming is Disambiguating

If you follow a programming tutorial, at the end you will have some working code. You will hopefully have some idea of how it works.

But, you haven’t learned how to make this code. Programming is different from woodworking or playing a guitar in this way, because they require training your hands. Watching and repeating what you see will work to help you learn and improve.

In programming, it’s good to type fast, but most of what is happening when you make new code is in your head, and tutorials don’t train that part.

This is why I think Programming Tutorials Should be Vaguer. Programming is taking a nebulous problem and breaking it down, understanding it, trying to find building blocks, and then building up something that solves the problem.

The final form is concrete, but it is made by going through multiple phases where you took unclear ideas and made them clearer.

We need tutorials that ask more questions and provide fewer answers.

Podcasts for Companion Learning

One of the advantages of podcasts is that they are audio-only, so you can listen to them while you do other things. I listen while doing chores, running, cooking, and driving. I mentioned in Soundtracks for Books that it’s hard to listen to something while you are doing effortful thinking.

But, just like a book soundtrack, you can pay attention to audio if the thing you are doing is really the same thing—something integrated with it.

I haven’t seen this much, but I think a big area for podcasts could be in guiding “learning by doing” tasks.

There are lots of video and text tutorials for learning programming. The issue is that you can be tempted to consume them without really doing the tasks yourself. And since you have to look at the book/video/blog etc, it’s hard to also be looking at your editor.

This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.

I’m not sure that a programming guide podcast is a good fit for very new learners, who still need a lot of help with the syntax. It would be better for learners who can write lines of code syntactically correct from a short-hand description.

Like I said in Vague Tutorials Would Help with Coding Interviews, I think getting good at taking spoken directions would help in coding interviews.