Hi. Welcome to the first issue!

The journey to this first issue was quite an odd one. I have been on and off writing for a decade now. About 4-5 years ago, I watched Scott Hanselmann's talk on Scaling Yourself. My takeaway was that a blog and a newsletter were the best way to scale yourself. To publish ideas out there as your proxies to find other people to interact with, develop from and possibly make an impact. You wouldn't have to type the same message in your inbox every time a friend raises a similar topic. Instead of retyping the same same, you simply send a link to a post or thread.

Between the imposter syndrome and increasingly hostile internet, writing publicly sounded foolish but more appealing in its potential for growth. As such I decided to publish on April fools day! Just a reminder that I had to be willing to start from foolish humble beginnings while I build up to the right thing. Hope you enjoy this journey with me.

Lets begin

This first issue rotates around a theme which might seem obvious from the Newsletter title: To make humans the center of our software systems design.

1. Build Your Stripe Checkout Like A Lawyer, Not Just A Developer

I was working on a project where I had to design the Stripe checkout process and build it to make sure the business model doesn't break. Then it dawned on me that the biggest threat to business sustainability isn't technical issues — it's unpredictable human behaviour around money, and the systems built to police it. Read →

The People On The Other Side Of Your Upwork Proposal

Upwork is increasingly getting difficult — or so they say. I've had quite a number of people who created an account and abandoned it, and others curious to start but not sure it's worth it. The conversation kept repeating itself so I wrote this. Read →

My listen this week

Diana Montalion on Developer Voices makes the case that your software problems are rarely software problems. Conway's Law, systems leadership, why your developers need emotional connection with users. An hour fifty — go straight to the leverage points section if you're short on time. Watch →

Current reading

I am working through A Philosophy of Software Design by John Ousterhout. Stanford professor, creator of Tcl, and a pioneer on what makes software architecture actually good.

The argument that pulled me into his work: we should teach software design the same way we teach writing, through drafts, feedback and revision.

Ousterhout's method is to build the largest system you can in three weeks. Tear it apart in code review for 3 weeks. Build another one. Repeat. The skill you should develop through this process is problem decomposition - which is knowing how to break a complex thing into pieces that don't fight each other. 

Two talks worth watching before or alongside the book:

• First talk — Talks at Google — pre-AI, foundational.

• Second talk — The Pragmatic Engineer— post-AI, how his thinking has evolved.

Worth your time

Dana Ciocan on Hashnode — a senior engineer's honest account of stalling, growing, and finding her way through every career stage. No blueprint, just a real story. A good read if you've been taking your path too seriously. Read →

See you next time.