Balance, free resources, lock-in, and whitepapers - 123dev #9
Posted on September 14, 2021 • 3 minutes • 489 words
Comments
Balance
Learning how to ride a bike requires you to balance in new ways. Riding a bike on a tight rope requires similar balance, and I can only image the perceived risks of failure makes it exponentially harder to focus.
Trying anything new will require some sort of balance. Physical, mental, time management, relationships all create a balance in our lives that can easily topple due to unexpected illnesses, changes in priority, or adding new plates to juggle. Balance is only achievable when we understand how we fall and reacting to the signals that indicate we are falling.
The people and systems who do this the best are the ones that can measure and react — and even predict — to falling. Don’t be afraid to ask for help.
Learning from mistakes
I did something without thinking too much about who it could harm. I never thought about how something could escalate or who it would discourage from participating. I could have deflected blame or defended my actions, but I took a moment to stop and think about someone else’s perspective.
Not learning from your past is a guaranteed way to grow in one skill. Defending my actions is not a skill I want to perfect.
Links
A huge list of resources that have something to offer developers. I look through this on occasion to see if there’s something I can use.
This is a fairly old post but I like Joe’s perspective on different types of lock-in. He talks about operations and developer lock-in in this post but also points out data in the footnotes. It comes down to lock-in is anything that will cost money — or time — to change and companies usually optimize for the cheapest lock-in possible.
Operations Lock-in vs. Development Lock-in · 80% I’m not a large enterprise developer. My experiences are at the unique environments of Google and Microsoft1. Over my career I’ve helped build platforms and I’ve learned that to build a great developer platform (or any good product at all) requires you to talk to many customers and put yourself in their mindset. This extends from the day to day usability of the product to the decision of a customer to bet a part of his/her business and career on the product in the first place.
I’ve learned a lot from reading whitepapers. My favorite way to read them is by printing them out and going outside with a pen. I take my time and mark up the pages with notes and underlying key things I learn.
This is a fantastic collection of whitepapers if you’re interested in distributed systems. Feel free to reply to this email and let me know your favorite whitepapers! I’d love to read more.
Foundational distributed systems papers I talked about the importance of reading foundational papers last week. To followup, here is my compilation of foundational papers in the d…