Author Archives: Lou Franco

July 2023 Blog Roundup

This month I kept up with my Podcast, mainly because I banked five episodes and then took a break

Based on my podcast, I wrote

I also used the Hacker News OPML file to add a bunch of blogs to my feed. This resulted in a bunch of posts

Write While True Episode 28: Complex Sentences

Podcast: Play in new window | Download

I like to sketch, mostly with pencil and charcoal on paper. One of the first things I needed to learn was how my drawing tools and the paper interacted. What kind of mark did each level of pencil hardness make, and how was that different from charcoal? What kind of paper worked best?

I did various exercises that helped me understand my own tools. 

I’ve been thinking a lot about this and trying to figure out what is the equivalent for this in writing. Here’s what I’ve come up with.

Transcript

Time Zones are the Hardest Problem in Remote Work

I was recently asked for advice on getting US Remote work from outside the US. There are several things you need to figure out, but while most can be worked on, time zone overlap is the hardest to overcome. Even inside the US, it’s an issue.

When I worked at Trello, we were about 70% remote, but almost all of us were in the US, Canada, or Latin America. We required that everyone work NY afternoon hours (12-5pm Eastern US). In the UK, that’s 5-10pm. Practically, this meant we didn’t have very many people in the UK and Western Europe, and I can’t think of anyone more East than that.

After we got acquired by Atlassian, we had some contractors in Ukraine who partially worked our hours. When Atlassian announced Team Anywhere, their remote policy, time zone overlap was a big part of the requirement for long-term remote teams. I personally had to interact with people in Sydney sometimes, and time zones made that painful.

This is just a single company, but time zone overlap was part of the secret sauce that made remote working better for us.

So, if you are outside the US time zones and are applying to remote jobs, I would think about how much time zone shifting you are willing to do. Perhaps you really like working extremely late (my father worked nights when I was young). If you think you’d like it, then I would say that directly in your cover letter. Also, I would concentrate on the part of the US that is easiest for you to overlap with.

I Will Give You Homework

It’s my goal to sponsor (not mentor) people that come to me for help. This means that instead of giving advice, I want to directly help by using my own social capital on their behalf. But, to do this, I have to have some basis for recommending or vouching for them.

I have two strategies for this—direct hiring and homework. If I have work they could do, I hire them to do it. Usually a small project. Their work on that will be the basis of my recommendation.

But, I don’t always have work that is easy to bring someone in on. In that case, after hearing where they are having trouble (usually in job seeking), I give them some tasks that I think would help, and ask them to get back in touch to let me know how it goes. If they do something (not necessarily what I asked, but anything that addresses the underlying reason I suggested it) and follow up, then I will feel a lot better about sponsoring them, usually by setting up informational interviews.

Third-party Dependencies are Inherently Technical Debt

I think of tech debt as just another kind of debt. You borrow by doing something that causes your code to have features now that it would normally not have for some time if you “did it right”. From then on, whenever you try to move this part of your code forward, you have to pay interest. If you remove the debt, you are paying off principal and future interest payments are lower. There are penalties if you pay off debt for no reason (increased QA and destabilization).

Given that definition, any third-party dependency is technical debt. Third-party? Here’s how I am defining it for the purposes of this article. You are the first party, the platform you are writing on (e.g. iOS, Android, React, NodeJS) is the second party. Everyone else is third party.

Here are some of the ways in which third-party dependencies have debt costs:

  1. You need to constantly update them. Even if you don’t want any of their new features, there might be security patches.
  2. They introduce breaking changes. Since you are constantly forced to update, you might also get breaking changes, which includes new bugs.
  3. They become unsupported. With enough time, this seems to happen to even the most popular projects.
  4. The second-party (your platform) adds their own incompatible implementation. Apple did this to me by introducing better support for HTTP (with many compelling features) which totally replaced AlamoFire.
  5. They don’t update on the same schedule as the second-party. This is not just the major releases, you also run into problems if they don’t keep up with the beta release schedule (you can’t move forward with your own adoption plans).

I have had all of these problems with dependencies I have taken on. Sometimes, it’s worth the trouble, but knowing all of the costs that might come has made me very skeptical of borderline dependencies.

Rewrite of Tech Debt Happens to You and Dependency Based Tech Debt based on Old, Flawed Work is the Jumping Off Point

Risks Could Have Mitigations That Also Have Risks

Most software development teams keep track of risks and mitigations throughout their project lifecycle. I think we often stop there and don’t really think about what it would mean to deploy the mitigation.

It would be frustrating for a project risk to manifest itself, but the mitigation is impossible to do because it needed prior planning or approval.

For example, let’s say you have a project with two broad phases. (1) a planning/architecture phase that would be done by a very small team (2) a long, mechanical phase that requires little coordination and is very parallelizable. An example of this might be converting a large front-end from Angular to React.

There is a risk that you underestimated how long it would take. Possible mitigations are:

  1. Add more engineers to the project (we are stipulating that that would help since coordination requirements are low).
  2. De-prioritize any other work your engineers might be assigned.
  3. Ask engineers to work longer hours and delay large blocks of time off.

These are if-then mitigations that you only do if a risk happens. If-then mitigations seem good, but the problem is that you are free to list them, and it seems that you have done something about the risk, but you really haven’t.

Let’s say we are in month 8 of 12 of the planned work, and you know you are going to slip to 16 months. If the work is important enough to care about that date and you want to deploy the mitigations, you must

  • Get budget approval
  • Find a source of engineers (contractors/internal)
  • Onboard the engineers to the project
  • Have management agree that other projects can be de-prioritized
  • Be prepared for engineers to leave the company

If-then mitigations have their own risks that must also be mitigated. For example:

  • Get budget pre-approval
  • Keep track of other projects engineers are on and keep in constant communication with their stakeholders.
  • Ask Engineers to plan for time off way in advance so that it can be accounted for in schedules.
  • Create project onboarding documents and plans.
  • Pre-identify engineers on other projects that would be moved to yours.
  • Pre-negotiate with an outsourcing company, and possibly include them in the project at the beginning of the parallelizable phase.

The benefit of these mitigations is that they can be deployed immediately, and so whatever risk they have should manifest early, thus ending the cycle of Risk->Mitigation->Risk.

Rewrite of Mitigating the Mitigations based on Old, Flawed Work is the Jumping Off Point

Having a Blog Makes Me Do Things

A couple of weeks ago I downloaded an OPML file of 1,000+ blogs to follow, which I only did because I thought I might get ideas of things to write about. I ended up writing about minimal blog feeds, how NetNewsWire handled the OPML file, raylib, linear algebra in game dev, and then I worked on a game in raylib (which I only did to write about).

A few years ago I started reading books about writing including Bird by Bird [amazon affiliate link] by Anne LaMott, On Writing [amazon affiliate link] by Stephen King, Art & Fear [amazon affiliate link] by Orland and Bayles, The Artist’s Way [amazon affiliate link] by Julia Cameron, and most recently, Writing Down the Bones [amazon affiliate link] by Natalie Goldberg. These books have been the backbone of my podcast about writing and have generated a lot of posts on this blog (Here’s a mashup of the ideas of Lamott and Cameron). If I didn’t blog, I would not have read them, which would have been a shame, because they are great and very applicable to writing code.

Obviously, not everything I do is just for this blog. Most of what I do is not. But, having this blog has made some use of the exhaust I spew by wanting to try things out. I used to stop myself by saying that I should focus on fewer things (which I did, and that was good), but now the thing I am focussed on is writing, and this blog is making it beneficial to do things that don’t seem to have much point.

Rewrite of Blogging follows doing based on Old, Flawed Work is the Jumping Off Point

Old, Flawed Work is the Jumping Off Point

In my podcast yesterday, I shared my final lesson-learned from Art & Fear [amazon affiliate link], which was that flaws are useful in making art. I always end the podcast with a writing tip, so you to look over your early work and find pieces where you didn’t live up to your intention.

This blog is nearly 20 years old, so I have a lot of old, flawed posts. For the rest of the week, I’m going to look for posts that had a good idea, but didn’t do a good job of expressing it.

Here is the process that I’m going to apply:

  1. Find a post that feels like it has no point, just a bunch of related ideas. (I have a lot of these)
  2. Figure out the single message or takeaway I wanted to convey.
  3. Remove everything that isn’t part of that message.
  4. Reorder the text to make it clear what the point of the post is as soon as possible.
  5. Title it to support that message.
  6. Add whatever else it might need to convey that single message.
  7. Make it more specific to my intended audience: software developers and managers.

It’s what I try to do now in new posts. I outlined this approach in Write While True Episode 5: Audience and Message.

Write While True Episode 27: Writing is Ordinary

Podcast: Play in new window | Download

This is the fourth and final episode in a series I’m doing about the book Art & Fear [amazon affiliate link] by David Bayles and Ted Orland.

In this, the final episode of the series, I’m going to tell you what they think you need to be in order to be an artist.

Transcript

Taking a Successful Break

I just finished a break where I traveled for four weeks to see family and friends in places I used to live (in NYC and New England). My intention was not to completely stop working, but that all of my projects would become much lower priority.

Here are some things that worked for me.

  • Banking content: I didn’t want to have to write every day and podcast every week, but I did want to keep the publishing schedule going. To do that, I pre-recorded five podcasts before I left and wrote many blog posts. I still wrote quite a bit during the break and did have to edit and post the podcasts, but it was much less work than normal.
  • Setting expectations: Before I left, I made a podcast about how I was taking a break and what my strategy was. I also set meeting expectations with my partners and clients.
  • Having a generation strategy: To make it a lot easier to make five podcasts in a couple of days, I did a four part series about lessons I learned from Art & Fear.
  • Lowering the bar: My goal in each podcast is to share something that is helping me in my writing with a clear takeaway. If I had that, I didn’t worry about the length.
  • Shutting off sometimes: Part of my trip was meant to be a real vacation, and during that time, I completely shut off.
  • Prioritizing relationships: I never turned down a chance to see my family or friends and made sure that my wife and I had plenty of time together as well. Everything else had to fit in between that.
  • Having fewer obligations: I do more projects alone or in partnerships that are trying to build modest businesses that can withstand me being away from it. My client work is more advisory and easy to schedule.

As I spoke about in my podcast, I did this exact same trip in 2021 and it completely derailed me. I did not set expectations correctly with a client and had to do a lot more work than I wanted to. I had to pare back everything to just work I was obligated to do and then kept that pattern for more than a year until I could get control again.

This time, using the strategies above, I was able to have the break I wanted and also keep projects going enough so that I could easily pick them back up when I returned.