Author Archives: Lou Franco

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.

Sponsor, Don’t Mentor

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.

Twitter Can be an Empathy Machine

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.

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.

Kite: First Impressions

I wrote in Robotic Pair Programmers:

If search engines ever get eclipsed, I think it will be by something in the environment that just brings things to your attention when you need them. I want this most when I code, like a pair programmer that just tells me stuff I need to know at exactly the right time.

Kite, a code editing plugin, seems to be trying to go down this route. They have “AI powered code completions” for 16 languages in 16 code editors. Unfortunately, they don’t support Swift in Xcode yet. But, they do support Python, HTML, CSS, TypeScript, and JavaScript in VSCode, Sublime, and all of the JetBrains editors, so I could use it to work on App-o-Mat, which is a Django-based site.

In addition to code-completion, Kite also offers Copilot, which is a documentation pane that is synced to your cursor. Xcode already does this—the issue is that a lot of Apple’s documentation isn’t very complete. Kite only supports this for Python right now, but one addition to the standard docs is they link out to open-source projects that use the type or method you are editing.

Unfortunately, Kite doesn’t work on Apple Silicon, yet. It uses TensorFlow, which uses a particular instruction set that isn’t supported by Rosetta. Apple seems to be working on getting TensorFlow ported to M1.

So, I’ll have to wait to try it out. Very promising though.