Podcasts Programming What I’m Up To

I’m on episode 123 of “The 6 Figure Developer” — “iOS Apprentice & Accordions w/ Joey deVilla”!

Last month, the folks at The 6 Figure Developer podcast interviewed me, and that interview was published this morning! It’s titled iOS Apprentice & Accordions w/ Joey deVilla, and you can find it right on the 6 Figure Developer site, or through your favorite way to find podcasts.

You can also use the player below:

The topics covered in the interview:

  • How I got started in the industry and where I am now. I started as a developer, then a developer evangelist, then marketing, then product owner, and now I’m a developer again!
  • My new job at Lilypad, which I like to describe as “a CRM for the alcohol industry”, and how much fun I’m having being a developer again.
  • My tech strategy: “Always bet on the toy.” The technology that people dismiss as a toy today often becomes tomorrow’s indispensable tool.
  • Working on the 8th edition of iOS Apprentice for It was an adventure, what with having to cover the new SwiftUI framework in a beginner-friendly way. I also talk about being honored to work on this edition of the book, as I learned iOS programming from an earlier edition written by the original author, Matthijs Hollemans.
  • Cross-platform vs. native mobile development and the challenges with each approach. When do you use each approach?
  • The people whose primary way of getting online is their mobile device. I talk about a key demographic — about 8% — whose smartphone is pretty much their only gateway into the online world.
  • Taking an active role in the Tampa Bay tech scene. I explain that it’s a habit I picked up from the Toronto tech scene in the early 2000s, during the era of DemoCamp Toronto. This work helped turn Toronto into one of the top 5 tech powerhouses in North America, and I think Tampa Bay can borrow a few of those tricks.
  • Don’t forget that two Tampa Bay authors have iOS books! It’s not just me, but Craig Clayton as well.
  • Recommended meetups and resources for Tampa Bay mobile developers. There’s Tampa iOS Meetup, the Suncoast Google Developers Group, and of course, the Coders, Creatives, and Craft Beer meetup.
  • My one piece of career advice: It’s actually Eleanor Roosevelt’s advice — “Do the thing you think you cannot do.”

Who interviewed me?

The hosts of The 6 Figure Developer who interviewed me are:

John Callaway: An International Speaker, Author, and Microsoft MVP, John has been a professional developer since 1999. He has focused primarily on web technologies and currently focuses on C# and .NET Core in Azure. Clean code and professionalism are particularly important to him, as well as mentoring and teaching others what he has learned along the way.

Clayton Hunt: Clayton has been programming professionally since 2005 doing mostly web development with an emphasis on JavaScript and C#. He has a focus Software Craftsmanship and is a signatory of both the Agile Manifesto and the Software Craftsmanship manifesto. He believes that through short iterations and the careful gathering of requirements that we can deliver the highest quality and the most value in the shortest time. He enjoys learning and encouraging other to continuously improve themselves.

Jon Ash: Jon has been a web developer since 2011 and a professional consultant since 2006. Coming from the aerospace industry he brings a passion for professionalism and excellence. He has a broad experience in current web technologies, with a strong foundation in C# and JavaScript. Though working knowledge of technologies are important, he takes pride in practicing and promoting clean code, adherence to the SOLID principles, and disciplines such as Test Driven Development.


Table-driven programming and the weather forecasting stone

Creative Commons photo by Tim Rogers. Click to see the source.

Whenever a picturesque small town located by a body of water gets popular with tourists, someone eventually sets up a “weather forecasting stone” like the one pictured above. It’s not all that different from a lot of what a lot of programs do: For a given input, provide corresponding output.

Prior to becoming a senior developer at Lilypad/Fintech, I took a consulting gig where my mission was to bring an application to a more workable condition. During that time. I saw a lot of “weather forecasting stone” code, and in this article, I’ll show you what I did with it.

The most common approach: if / else if

Most of the “weather forecasting stone” code took the form of good ol’ if / else if. Here’s the JavaScript implementation:

let forecast;
if (stoneCondition == 'wet') {
  forecast = 'Rain';
} else if (stoneCondition == 'dry') {
  forecast = 'Not raining';
} else if (stoneCondition == 'shadow') {
  forecast = 'Sunny';
} else if (stoneCondition == 'white') {
  forecast = 'Snowing';
} else if (stoneCondition == 'unseen') {
  forecast = 'Foggy';
} else if (stoneCondition == 'swinging') {
  forecast = 'Windy';
} else if (stoneCondition == 'jumping') {
  forecast = 'Earthquake';
} else if (stoneCondition == 'gone') {
  forecast = 'Tornado';

Aside from not handling the case where stoneCondition doesn’t match any of the expected values, this code works just fine. It’s reasonably readable, but it doesn’t have the conciseness of the the sign in the photo. It reads more like this:

  • Is the stone wet?
    • The forecast is “Rain”.
  • Otherwise, is the stone dry?
    • The forecast is “Not raining”.
  • Otherwise, is the stone casting a shadow?
    • The forecast is “Sunny”.
  • Otherwise, is the stone casting a shadow?
    • The forecast is “Sunny”.
  • Otherwise, is the stone white on top?
    • The forecast is “Snowing”.
  • Otherwise, is the stone unseen?
    • The forecast is “Foggy”.
  • Otherwise, is the stone swinging?
    • The forecast is “Windy”.
  • Otherwise, is the stone jumping?
    • The forecast is “Earthquake”.
  • Otherwise, is the stone gone?
    • The forecast is “Tornado”.

Another approach: switch

In the same application, I saw more “weather forecasting stone” code, and from all appearances, it appeared that it was written by another programmer. This one preferred to keep variable names as short as possible, often condensing them to remove as many vowels as possible. They also were deeply in love with the switch statement. Their code, as implemented in JavaScript, looked like this:

let frcst;
switch (stnCndtn) {
  case 'wet':
    frcst = 'Rain';
  case 'dry':
    frcst = 'Not raining';
  case 'shadow':
    frcst = 'Sunny';
  case 'white':
    frcst = 'Snowing';
  case 'unseen':
    frcst = 'Foggy';
  case 'swinging':
    frcst = 'Windy';
  case 'jumping':
    frcst = 'Earthquake';
  case 'gone':
    frcst = 'Tornado';
    frcst = 'Unknown';

The switch statement in JavaScript is modeled after the one in C. This means that a break statement has to be added to the end of each case to prevent fall-through. You should think of it as more of a goto statement in disguise rather than a structured branching statement.

Note that switch requires a default clause to handle the case when none of the other cases apply. In the code above, I’ve set it so that any case we haven’t accounted for causes the forecast to be “Unknown”. In the circumstance where the code should never have to deal with an unexpected case, I’d have the default throw an exception or similar red flag that we should catch during development.

It works, but it’s even wordier than the if / else if example, thanks to the required break statement on every clause except the default one. Once again, it’s not as concise as the sign, because it reads like this:

  • Is the stone wet?
    • The forecast is “Rain”.
    • Stop here.
  • Is the stone dry?
    • The forecast is “Not raining”.
    • Stop here.
  • Is the stone casting a shadow?
    • The forecast is “Sunny”.
    • Stop here.
  • Is the stone casting a shadow?
    • The forecast is “Sunny”.
    • Stop here.
  • Is the stone white on top?
    • The forecast is “Snowing”.
    • Stop here.
  • Is the stone unseen?
    • The forecast is “Foggy”.
    • Stop here.
  • Is the stone swinging?
    • The forecast is “Windy”.
    • Stop here.
  • Is the stone jumping?
    • The forecast is “Earthquake”.
    • Stop here.
  • Is the stone gone?
    • The forecast is “Tornado”.
    • Stop here.
  • And if you’ve made it this far:
    • The forecast is “Unknown”.

My preferred approach: Lookup tables

While both approaches work, I was still looking to make the code as simple to read as the sign (and in the process, also make it simple to maintain and modify). I wanted code that looked like this table:

If the stone’s condition is… …then the forecast is:
Wet Rain
Dry Not raining
Casting a shadow Sunny
White on top Snowing
Unseen Foggy
Swinging Windy
Jumping Earthquake
Gone Tornado
None of the above Unknown

Here’s my lookup-table based implementation of the “weather forecasting stone” sign, in JavaScript

  'wet'      : 'Rain',
  'dry'      : 'Not raining',
  'shadow'   : 'Sunny',
  'white'    : 'Snowing',
  'unseen'   : 'Foggy',
  'swinging' : 'Windy',
  'jumping'  : 'Earthquake',
  'gone'     : 'Tornado',
  'default'  : 'Unknown'
const forecastLookup = (stoneCondition) =>

This code gives you a couple of things:

  1. FORECAST_LOOKUP_TABLE, an object that acts as a lookup table. Its property keys are the set of strings for all the possible stone conditions, and its values are the forecasts that correspond to each condition.
  2. forecastLookup, a function that makes it easier to use the lookup table.

With this code, you can get the forecast using the lookup table…

let forecast = FORECAST_LOOKUP_TABLE['wet'];

…or to handle unexpected stone conditions, get it using the forecastLookup() function:

let forecast1 = forecastLookup('wet'); // results in "Rain"
let forecast2 = forecastLookup('covered in gravy'); // results in "Unknown"

The table-based solution is easier to read and maintain than the if / else and switch methods. It also requires fewer lines, which is important if you follow Corbató’s Law:

Simply put, what Corbató is saying is that every day, you only have so many lines of code in you on any given day. The corollary to Corbató’s Law is that for maximum productivity, you should code in such a way that uses as few lines as possible while maintaining readability and maintainability. I think my solution does just that!

Humor Programming

I had the same reaction

As its own creator says: “In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.”

Thanks to Jennifer Newsome for the find!

Programming Video

Worth watching: Videos on programming paradigms and object-oriented vs. functional programming

Watching programmers debate can sometimes be like watching a monkey knife fight.

Even in this day and age, when programming languages freely mix object-oriented and functional features, there are still arguments over which approach is “better”, or at least which one should be used in a given situation. Here are some videos that cover these paradigms; they might event give you some insight on how you can use them in your day-to-day coding.

4 Programming Paradigms In 40 Minutes – Aja Hammerly

Here’s a nice overview of four programming paradigms: object-oriented, functional, procedural, and logical, including the strengths of each. Start with this one.

Why Isn’t Functional Programming the Norm? – Richard Feldman

Functional programming is actually the earliest programming paradigm, but it’s not the primary paradigm of any of the top ten programming languages that programmers are using in 2019.

Object-Oriented Programming is Embarrassing: 4 Short Examples — Brian Will

In this video, Brian Will — an OO skeptic — takes four examples of “proper” object-oriented code and rewrites them using a procedural approach, resulting in what he considers to be “better” code. He’s not a big fan of the philosophy where data and code grouped together — he says “Let data just be data; let actions just be actions.” I leave it to the viewer to make their own call as to whether he’s right or wrong. (Hey, I figured I should throw in at least one curmudgeon into the list!)

FP vs. OO: Choose Two — Brian Goetz

When it comes to FP vs. OO, I’m of the “Why not both?” school of thought, and so in Brian Goetz.

Humor Programming

The five phases of software development

It wasn’t the answer the professor was looking for, but I’d have given it at least 6 out of the 10 points the question was worth.

If you search for “5 phases of software development”, you’ll find that there isn’t a complete consensus on what those phases are, or even if it’s just five.

Programming Video What I’m Up To

Now that I’m getting paid to be a developer again…

…it’s time to revive this video that New Relic put out way back in 2011 to promote their application monitoring service.

Titled We Love Developers, it features some of the brightest lights in the industry:

  • Matz: Yukihiro Matsumoto, creator of the Ruby programming language
  • Guido van Rossum: Creator of the Python programming language
  • Linus Torvalds: Creator of the Linux operating system and the Git version control system
  • DHH: David Heinemeier Hansson, creator of the Ruby on Rails framework
  • Bill Joy: Co-founder of Sun Microsystems and creator of the vi text editor
  • James Gosling: Lead designer of the Java programming language
  • Sir Tim: Tim Berners-Lee, creator of the World Wide Web
  • Marc Andreesen: Co-creator of Mosaic, the first widely-used web browser, co-founder of Netscape, co-founder of Andreesen Horowitz
  • Woz: Steve Wozniak, creator of Apple
  • Rasmus Lerdorf: Creator of the PHP programming language
  • The Gu: Scott Guthrie, creator of ASP.NET, Executive VP of Microsoft’s Cloud and AI group
  • Sergey Brin: Co-founder of Google
  • Dries Buytaert: Creator of Drupal

At the end of the video, they wanted to use the image of a more “everyman” developer to represent you, their customer. Guessed who they picked:

My photographer friend Adam P. W. Smith (my old business partner; together, we were datapanik software systems and we worked on some pretty interesting projects back in the late ‘90s) took the picture back in August when I was visiting him in Vancouver. I’d arrived a day early for the HackVAN hackathon and was sitting in his kitchen getting some work done when he decided to get a couple of shots. He poured me a glass of scotch, set it on my accordion, which I’d set down on the chair beside me, and staring taking pictures.

In case you were wondering, you can find out more about my new gig in the article titled — appropriately enough — The new gig.

Humor Programming The Street Finds Its Own Uses For Things

ArnoldC: A programming language based on Arnold Schwarzenegger’s movie one-liners

Do you like programming? Do you like Arnold Schwarzenegger movies? If so, ArnoldC is the programming language for you!

ArnoldC will never make the TIOBE list, but then again, no other programming language is based on Arnold Schwarzenegger’s movie one-liners! Better still, there’s an ArnoldC syntax highlighting package for Sublime.

Here’s “Hello, World!” in ArnoldC:

TALK TO THE HAND "hello world"

It compiles down to Java bytecode. Running the program above is as simple as saving it as hello.arnoldc and entering the following on the command line:

java -jar ArnoldC.jar hello.arnoldc
java hello

Find out more about ArnoldC on its GitHub page, and once you’ve been impressed, download it, start coding, and GET TO DA CHOPPA!

Since we’re on the topic of Arnie, enjoy this video: