One thing that I like about podcasts is that you can do them while you are doing other things. But, I think there’s an opportunity for a podcast to augment the other thing you are doing.
Write While True is a podcast is for programmers that want to write more. Listen to it and get ready to start writing when it’s done. Each episode is short and will describe a writing exercise you can do when it’s over.
The first episode is an exercise that will help you get unblocked.
Podcast: Play in new window | Download
I started my blog 17 years ago, but wrote about 9 posts a year. Then, I started doing something that helped me write something I could publish every day.
Links:
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.
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.
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.
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.
Since I mostly use Twitter to listen to young, underrepresented programmers, I get to hear about things I normally would not. One recurring theme is the role of mentors, and at some point I saw people talking about how they needed sponsors instead. Here’s an example from Nancy Wang in Forbes:
Part of a solution could be via mentorships and sponsors. The difference is critical: mentors can help make introductions and give valuable advice, and sponsors often go one step (or many steps) further, leveraging their own reputation and personal capital to advocate for your success.
I am trying to apply this when people ask for advice. It’s hard.
It’s easy to just say a bunch of stuff. Talk about yourself, tell a story, recommend a book, etc. If you are successful, it’s easy to think it’s because of the things you did and if someone else did them, they would also be successful. But it’s not that simple, because mixed in with our efforts were luck and helping hands. A lot of what we think is good advice doesn’t apply at the very start, where we need someone to just take a chance on us.
When I look back for sponsors in my own life, I remember that my aunt got me a job filing paper invoices in her office and that’s where I learned Lotus 123 and did my first professional programming in high school. At 13 my mom got me a computer at Radio Shack when we went there to return a defective electric typewriter (they were the same price). A few months before that, my wood shop teacher transferred me to computer “shop”. They didn’t give advice—they used their “personal capital” to put me in a position to grow.
Moms, aunts, and teachers will probably always help out a teenager. They are part of our lives, know us well, and probably feel a vested interest in our success. But, as aspiring sponsors, we can do that too. Our goal should be to get to know the people we are trying to help. To become invested in their success.
So, now when someone approaches me for help, my default is to think about how I can get into a position to sponsor them. To do that, I need to know them and what they can do. For programming students, I hire them to help me with my personal projects and consulting. I always pay for this work.
It’s not a lot, but my goal is to get to know them well enough to recommend them without reservation.
Update July 2023: This post was written in 2021. Since then, I have changed my views on Twitter and deleted all of the data in my account. I haven’t edited this post, but I would see it as more of a way to use Mastodon or other social media, not Twitter specifically.
I don’t tweet much, so my Twitter experience is highly dependent on how I manage who I follow, block, and mute. I realized a few years ago that by tightly controlling this, I could make Twitter into any experience I wanted.
I decided that the best way to use it for me was to give me access to voices I wouldn’t normally hear from. So (aside from people I know in real life), I almost exclusively follow programmers from groups that are underrepresented in tech.
In my feed, since they are way overrepresented, I am constantly exposed to the world as they experience it, and it helps me develop empathy. I can feel my attitudes and default reaction changing in ways it never would have if I only interacted with people I know.
Another important part of how I use it is that I mostly listen. If the topic is tech and I can answer a question or add value, I do. But I don’t chime in on topics where I should be learning, and where my instincts are probably not great.
I can also add value by amplifying their great work. Again, by making my default overwhelmingly underrepresented programmers, it’s just more likely I will be exposed to their work instead of it getting buried in my feed.
I am starting a new series of articles about Appium on my iOS content site, App-o-Mat.
In the first one, I cover the first step of getting the most out of GUI Testing: setting accessibility identifiers.
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.