Working Code

Latest Episodes:

045: Join Our Discord Oct 20, 2021

Show notes

This week's episode is all about the podcast's Discord server going public. We're now inviting all listeners to join us and participate in the community chat. Why would we want to do that, and what's in it for you? Answers to these questions and more now available as sound waves for your ear holes.

Join our Discord here: https://workingcode.dev/discord/

Follow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. Or, leave us a message at (512) 253-2633‬ (that's 512-253-CODE). New episodes drop weekly on Wednesday.

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

044: Facebook's No Good Very Bad Week Oct 13, 2021

Show notes

Between Frances Haugen's testimony, a meta outage of Facebook properties including Facebook.com, Instagram, and What's App, and a $7 billion drop in Mark Zuckerberg's personal wealth in a matter of hours, it's safe to say that Facebook has been having a terrible, horrible, no good, very bad time of it. There have even been rumors that Facebook's "work from home" policy is being rescinded; though, such claims have been denied by the company. Today, the crew talks about everything that's going on in the Facebook universe. And, Tim shares his own harrowing experience with Border Gateway Protocol (BGP) catastrophes and why Facebook's networking woes were a little too triggering for his own comfort.

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

043: Relay Race Programming Oct 06, 2021

Show notes

You might think that "programming" is a relatively straightforward concept: take abstract ideas and codify them into lines-of-code (LOC). But, within this broad abstraction, there are a multitude of implementation details. Some engineers love to hunker down and write code inside a metaphorical bubble; mob programmers love to dog-pile on the same machine, blitzing the problem until it's obliterated; and, pair programmers methodically alternate responsibilities between a "driver" and a "navigator" in cooperative pairing sessions.

On today's episode, Carol shares her team's approach to product development which sounds more like "Relay Race Programming." First, her team does some up-front design and planning in order to orient the work. Then, her team divvies up the tasks, processes the work in parallel, and keeps a constant line-of-communication open such that they can unblock each other as soon as issues arise. While this approach takes some getting used to, Carol believes that it has increased her productivity, decreased her Pull-Request review latency, and opened the door to many more mentorship opportunities.

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

042: Potluck #3 Sep 29, 2021

Show notes

This week on the podcast, the crew discusses various topics: "Strong opinions, loosely held" - is this a statement with noble intent? Or, does it encourage people to dismiss past evidence and the experiences that have shaped their current view of the world? When is it time to upgrade old technology choices? When the time it takes to upgrade is time not spent on building features, at what point is that cost justified for the business? GitHub Copilot helps you write code, but who gets credit for that? Is it even legal? Have engineers demonstrated enough responsibility in the past to merit an even more powerful copy-paste programming paradigm? And finally, why don't we see more employee-owned software companies? If engineers had more material skin in the game, wouldn't they be more motivated to ship product?

All that and more on this week's show!

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

041: The Third Age of JavaScript, with Shawn @Swyx Wang Sep 22, 2021

Show notes

Shawn Wang - known as "swyx" online - is a financial investor turned software engineer and journalist. With a passion for history and a knack for "trend spotting", Shawn uses a keen analytical sense, honed through years of financial due diligence, in order to organize the world of web development into a series of epochs, each with its own theme. He's recently codified these observations in a blog post titled, The Third Age of JavaScript. Today, we're thrilled to have Shawn as a guest on our podcast to discuss the past, present, and future state of JavaScript as well as the world of developer ergonomics and the magical possibilities of effortless platform management.

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

040: Automaticity Is a Weird Word Sep 15, 2021

Show notes

The other day, Ben was listening to an episode of the MongoDB podcast in which Mat Keep shared a story about the adding of atomic transactions into the MongoDB product. Mat said that the engineer who spearheaded the effort used to joke about the fact that his team was spending a huge amount of time working on a feature that 90% of developers would never need. For Ben - who leans heavily on transactions for referential integrity - this sounded like an crazy statement. But is it? Are database transactions overrated? Or, is it more so that the type of use-cases that work best in a document database are also the type of uses-cases that don't really need transactions?

On today's episode, the crew talks about how they use databases; the role of atomic transactions in the reduction of application complexity; and, whether or not they've ever felt "held back" by the limitations of a relational database management system. Full disclosure, all of the hosts have far more experience with traditional databases when compared to NoSQL databases.

NOTE: In the show, Ben mentioned that a document database like MongoDB can't enforce schemas like a relational database. And while this was true in earlier versions of the MongoDB product, it is no longer true. In recent updates, MongoDB has added schema validation and enforcement.

Notes & Links

MongoDB Podcast: Episode 67 - MongoDB Evolved with Mat Keep

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

039: Ben's Future at InVision Sep 08, 2021

Show notes

For last 8-years, Ben Nadel has poured his heart and soul into InVision, a product that drives design collaboration. During this period, his area of expertise has focused on the (now named) "legacy" platform - the ColdFusion and AngularJS monolith that has built the business into what it is today. Soon, however, the "legacy" platform will be wholly subsumed by the "modern" platform - a distributed, microservices architecture built on Go, Node.js, and React.

In today's episode, Ben opens up about the emotional struggle that he's facing as his role on the legacy platform comes to a end. He wonders what it's going to be like to start over; to go from a big fish in a CFML pond to a novice in a Go ocean; and, to find a way to not feel like a complete failure when his productivity drops significantly.

One of the scariest things for Ben is that he's not sure if he'll be able to trust his gut. While the fundamentals of programming will certainly transfer from the legacy platform over to the modern platform, it's hard to know if future "feelings" will be true indicators of potential problems. Or, if it's just a byproduct of his lack of familiarity with the new architecture and language constructs.

Only time will tell. And, until then, he intends to grind hard and deliver as much value as he possibly can on the legacy platform while he still has time and the skills necessary to get the job done.

ASIDE: While not mentioned by name in the show, Travis Heinström - the SVP of Engineering at InVision - is the person who wanted to make sure that Ben has all the room he needs to "feel his feelings" when the legacy platform is shut down. This is perhaps one of the most emotionally-intelligent things that Ben has ever heard a manager ask about.

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

038: Holding Developers Accountable Sep 01, 2021

Show notes

Recently on Facebook, Hal Helms —highly respected author, speaker, and computer programmer— shared some of his views on the use of "Sprints" to drive engineering work on a product team. In short, he despises the idea of asking engineers to commit to achieving a goal within an estimated time frame. He likens this to asking prisons to build their own gallows. Everyone is terrible at estimating everything. So when companies start to use each "estimate" as a "contract" with which to punish engineers for under-delivering after over-promising, all it does is set the entire team up for a toxic cycle of disappointment.

This is the full text of Hal's post:

"We have to be able to hold developers accountable."

A friend and I were discussing the idea of "sprints" — a system where developers commit to achieving certain results within a specified time frame — usually two weeks.

I hate and detest sprints. I despise asking developers to "commit" to achieving a goal within an estimated time frame. My friend disagrees. He's wrong.

The first flaw in this system is what Nobel Prize-winning psychologist Daniel Kahneman termed "The Estimation Fallacy". When people are asked how long a goal will take to achieve, they predictably and chronically underestimate the time. And this is true even when they have considerable experience in being wrong in their previous estimates.

A good estimate is one that's over half the time and under half the time. So, estimates are not really what developers are asked for. They're asked to commit to a date after which they can be held to blame if they have not achieved the goal. Every such "estimate" holds an implied threat. ' Asking developers to provide their own deadlines is a bit too much like asking prisoners to build their own gallows.

But let's say you have a taste for a bit of sadistic irony. It's still not a good idea — not if your goal is to actually increase the throughput of the system.

Developers are not, by lot, stupid. So while inexperienced developers may believe their own deadlines are realistic, those of us with more road behind us are not so quick to be led to slaughter.

If the boss demands a deadline that a more experienced developer thinks is probably five or six days, the deadline become two weeks — three if they can stretch it.

And when they actually complete the work ahead of time — well, would you be quick to voluntarily re-enter the arena only to place yourself at risk again any earlier than you have to?

It gets worse: you may know one part of the sprint goal while I know another, of which you're clueless. Can I help you? Sorry, I have my own deadline. How is this good for the developer, much less the organization?

And so I circle back to my conversation with my friend. "We have to be able to hold developers accountable." One needs to hold people accountable for things they don't want to do. Developers, on the other hand, like to develop. Most of the ones I know do it in their spare time as well as their work hours.

If I want you to do something you already want to do, what is the sense behind "holding you accountable"?

Eat this ice cream — and I'll need to see status reports of how much you've eaten, accompanied by proof that you're actually eating it (to make sure you don't just dispose of the ice cream).

I recently had a long discussion with a CEO who asked for what might be termed my "philosophy of management" when it comes to managing developers.

I told him it was really quite simple: give developers what they need and protect them from upper management.

CEOs don't produce software. CTOs don't. Product Managers don't. When upper management tries tricks like sprints to force their developers into deadlines — as if such a thing could be done by fiat — they effectively tell developers: we neither trust nor respect you.

I'm not sure what genius management consultant had the flash of insight that disempowering workers and placing obstacles in their way was a surefire way to get the most out of them.

Inspired by Hal's post, we wanted to talk about how we view—and experience—developer motivation; how we employ Sprints at our respective offices; and, what we think an organization should be doing to help drive a project to completion. There's the idealized approach that Hal puts forward:

Give developers what they need and protect them from upper management.

Amen! But, there's also the practicalities of running a business, building a road-map, organizing marketing campaigns, and keeping users interested and excited in your product. None of it is easy. But you can be sure that treating people with professional respect is certainly one of the necessary ingredients.

Notes & Links

Daniel Kahneman: The Planning Fallacy

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

037: Brian Klaas Talks Cloud Aug 25, 2021

Show notes

As we alluded to in Episode 20: Carol Needs a Consult, there are a lot of different products under the Amazon Web Services (AWS) umbrella. In fact, the number of products is somewhat mind-boggling. It can be overwhelming just figuring out where to start, let alone understanding which service is right for which job, how to configure that service, and how to get that service to integrate with all the other AWS services. Thankfully, we have Brian Klaas as a very special guest on today's episode.

Brian Klaas (@Brian_Klaas) is a Senior Technology Officer and instructor at the Johns Hopkins Bloomberg School of Public Health; he runs a team that builds a Learning Management System (LMS) running on a hybrid cloud; he's been using and extolling the value of Amazon Web Services since 2009; and, he's a well known and respected speaker and leader within the ColdFusion community. According to him, the overarching value that AWS provides is the outsourcing of "undifferentiated heavy lifting": AWS builds the infrastructure that you don't want to, allowing your team to focus on your own business-critical product-lines.

Notes & Links

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.

036: Blogs and Digital Gardens Aug 18, 2021

Show notes

Blogging is a win-win activity. Not only does the act of writing help burn knowledge into your long-term memory, it also acts as an easily searchable repository of your own thoughts. Furthermore, it helps other people solve similar problems when they stumble upon your blog in the future.

The value-add of blogging is obvious; the way start blogging is less clear. This week, Adam, Ben, and Tim talk to Carol about her desire to start blogging. The discussion touches on tooling, platforms, hosting, content, and strategy which Adam sums up nicely as: