It’s Not the Ratio, It’s the Delta

I sometimes see a misconception regarding living in a high-cost vs. low-cost of living (HCOL v. LCOL) area. It goes something like this: “I make 2x more, but my expenses are 2x more, so it’s a wash.”

This is not true. If you make 50k and spend 30k, you save 20k. If you make 100k and spend 60k, you save 40k. Since increasing savings is the easiest way to change your future net worth, this is big deal. I started my career in NYC, so I know what this did to my savings account in my 20’s.

Just because you live in an HCOL area, doesn’t mean you have to have a high cost of living. I paired my NYC salary with a low rent (the 2023 equivalent of $900-$1,400) and no car, which are the easiest ways to save money in an HCOL.

Not all expenses are higher in an HCOL—mostly it’s housing and dining. Commuting (for me) was a lot cheaper. Other expenses, like travel, clothes, and “stuff” are pretty much the same where ever you live, so living in an HCOL means that you have more money to spend on those things. HCOL areas themselves are usually desirable travel destinations, and you can do that for free.

So, when planning where you live, if you are deciding between HCOL and LCOL, use the delta, not the ratio. Of course, if you can, working remotely and pairing an LCOL home with an HCOL job can give you the best delta.

30 Plants for Dinner

I saw this post about eating more plants from Mike Crittenden today. One suggestion is trying to hit 30 plants per week. As a vegan, I can get near 30 plants per day, but tonight I made a 3 course dinner for my wife and a neighbor.

  1. Vietnamese style raw spring rolls in rice paper with 2 dipping sauces (peanut and sweet & sour)
  2. Sesame Tofu and Brocolli over cold sesame noodles
  3. Mango Pudding with Coconut Cream Panna Cotta Style

Here is the list of plants we ate:

  1. Mint
  2. Cilantro
  3. Basil
  4. Spinach
  5. Soybeans (Tempeh and Tofu)
  6. Carrot
  7. Rice (in the rice paper and noodles)
  8. Peanut
  9. Garlic
  10. Ginger
  11. Wheat (flour)
  12. Shallot
  13. Black Pepper
  14. Sesame Seed
  15. Scallion
  16. Celery
  17. Lime
  18. Maple Syrup
  19. Serrano Pepper
  20. Brocolli
  21. Sugar
  22. Mango
  23. Coconut
  24. Vanilla

There was also vinegar, soy sauce, hoisin sauce, and sriracha used in the dips and glazes. I use very little oil (tofu was made in an air fryer), but there was a little bit of olive and grapeseed oil. I’m sure I got to 30 plants.

If I was going for 30 plant ingredients, I’d have just added some blueberries and allspice to the dessert, dredged the tofu in corn starch, and added a few more plants/spices to the main dish (peas, turmeric, cayenne pepper, grape tomatoes).

If you’re looking for plant variety, look for vegan recipes, but even if you eat meat, I agree with Mike that you should add more plants and varieties of plants, which is easy to do if you are going for it.

Be Happy When It’s Hard. Be Worried When It’s Easy.

When I was running product development for Atalasoft, I used to love it when a developer was having a hard time with a project. We sold image codecs, and our main competitor was open-source. Our secret sauce was that we could do things they wouldn’t. It was supposed to be hard.

If it were easy, everyone would do it, and it would be free. We wouldn’t have a business.

I think about this a lot when I see what people are doing with Large Language Models. Making an LLM isn’t easy, but Google thinks there’s no moat here for anyone. Still, it’s hard enough because it costs a lot of money, even if you know exactly how to do it.

The part that’s more concerning is what people who use LLM’s are saying. Everyone is so surprised how well it does with basically no work or skill on the part of the user. That’s fine, but then anyone could do it, and the thing they are doing with LLMs isn’t going to accrue value to them.

I think every knowledge worker should be using LLMs in some way, if only to learn about it. It offers enough benefits right now that it can’t be ignored. But, the easier it seems to be that you are getting good results, the more I would be concerned that you won’t be necessary to get those results in the future.

What Hardware Inspires Programming Language Design?

In early computing history, the government, academia, and industry collaborated to create languages for mainframes. The enduring ones were COBOL and Fortran.

You’d think that the PC era, when computing was delivering doublings in power every couple of years that it would also have been a time of programming language innovation. Aside from Microsoft, in the 70’s-2000’s, most of the PC companies didn’t do much here. IBM, Intel, AMD, Apple, Dell, HP, Sony, and Compaq made all the hardware, but contributed nothing to programming languages. Sun is the only hardware company that bucked this trend.

The photocopier, with Smalltalk, did more than the PC to drive programming language design than the PC. Fifty years of OO dominance followed.

But, for driving programming language development, nothing beats phones.

Telephone profits powered Bell Labs, which invented a lot of important tech, but some of the most enduring are the programming languages they developed. To limit it to just the ones I have used professionally, there are C, C++, Awk, KSH and the document processing languages troff, pic, and eqn. I’m probably leaving out about a dozen more.

AT&T was the most prolific converter of phone calls to programming languages, but Ericsson created Erlang, and Apple’s iPhone profits drove them to create Swift. You can give most of the credit for Kotlin to Android.

In the end, it’s probably money that does most of the work, and the real driver seems to be when it coalesces to a single winner.

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