This blog series is an extended version of a talk I gave at Serverless Days NYC 2022. The goal is to share ways that a "friend of mine" has failed at serverless to help level up the community. Just as the transportation industry shares accident report analysis with the whole industry to improve safety, we in the software community need to do the same. This is my attempt to do that.
I work on mac OSX and linux command line environments. My tool kit is shaped by the needs I have. There may be similar tools for powershell or other, I'm just not aware of them.
I work on Mac OSX and Linux command line environments. My tool kit is shaped by the needs I have. This is my tool box of tools that work with almost any command and help me go from just using the command line to being an expert. Wow, your friends and colleagues. These tools make every other command at the command line more powerful.
We all hit bugs that feel impossible to diagnose. The hardest ones to debug are intermittent or inconsistent. How do I fix what works sometimes? If a line of code always breaks then the fix is direct. The system is linear. The action leads to a failure.
How do I debug a bug that is intermittent? How do I debug something that works sometimes?
Here are some reminders to myself next time I encounter a baffling debugging session.
(photo credit Charles Cushing)
This article is intended for startup founders, particularly for those who are first timers. There is nothing extraordinary about my VC experiences. I have done the following: raised an angel round and two institutional rounds (and failed at two rounds?) at a company I co-founded in the GovTech/Community space (SeeClickFix). I have participated in pitches as CTO of a pre-PMF (product market fit) mortgage tech company (HeavyWater). I have raised a friends-and-family round at my current Cloud Infrastructure company (https://www.cyclic.sh)
I was 16 and about to head off as the youngest member of a month-long wilderness sailing trip. The night before my departure my dad came into my room to check on my packing and inspect my gear. He got serious and gave me the following advice for how to stay alive, keep safe and make the most of my time.
It has stuck with me. It is the best, most concise advice I know for how to build a startup, be a parent or venture into the unknown.
I have written previously about how we, as technical professionals, misuse the term debt and end up sounding like idiots in a business context. This is meant as a companion, to help better communicate, to our non-professional colleagues, what we mean when we say "technical debt".
As a repeat founder I get the question from entrepreneurs and others: "how do you get your first users?"
For me, this is actually the easiest stage. I think of acquiring and growing a group of users differently based on the scale of the existing user base. There is a great book that talks about going 0 to 1 (https://en.wikipedia.org/wiki/Zero\_to\_One). What I mean here is how to go from 0 users to 1 user.
I know how to write good code.
Usually it means spending more time now to make the code better for some future state of the world. This assumes that I know what the future will look like. In software we rarely know what the future holds.
(a short story inspired by true events)
TLDR: Mere mortals implement best practices for S3 read and write performance, create a million billion s3 objects with their high performance system, try to clean up the really really expensive mess and find themselves in a dimension as vast as space and as timeless as infinity.