Author: ryanh878

Ongoing New Quotes / Articles

I have an old page: legendary quotes.

As I gather new ones, I will add new ideas here and prune them over time:

“Just recently I came to a realization, people and organisations exist in a competency / incompetency matrix.

The competent orgs with incompetent people are your blue chips and “traditional” companies. They ship stuff, have customers, grow along with the overall market and economy and are able to survive most non-existential threats and down-turns and even existential ones from time to time. All, or most, the competency is institutional, recorded in implicit knowledge held by people and various tools and processes. Unless those companies loose that knowledge for some reason, things are good.” – hef19898 – On HN

“When making life decisions, going in the direction of more money can be wise. However, we must keep in mind that when we choose money, we don’t choose much. We just decide to decide later.”

“Upper limit of complexity is infinity? An engineer can hold a whole complicated system in his head and work on it. When he leaves and needs to pass it on, he won’t be able to communicate it all. Complexity we can sustain over time is less than today.” https://www.youtube.com/watch?time_continue=2841&v=pW-SOdj4Kkk

Norris Numbers – average amount of code an untrained programmer can write before he or she hits a wall. Clift estimates this as 1,500 lines. Beyond that the code becomes so tangled that the author cannot debug or modify it without herculean effort.

… the very language that one could use to make a comparison is taken away, and the possibility of benchmarking on a different infrastructure is an endeavor akin to rewriting everything from scratch.
https://cerebralab.com/Is_a_billion-dollar_worth_of_server_lying_on_the_ground

““The choice isn’t between automation and non-automation,” said Erik Brynjolfsson, the director of M.I.T.’s Initiative on the Digital Economy. “It’s between whether you use the technology in a way that creates shared prosperity, or more concentration of wealth.””

Articles:

The most plausible explanation I’ve seen for people moving off programming onto different jobs:
https://whoisnnamdi.com/never-enough-developers/

A case where tight feedback loops don’t help.
https://brianlui.dog/2020/05/10/beware-of-tight-feedback-loops/

What Color is Your Function?

THE TYRANNY of STRUCTURELESSNESS
https://www.jofreeman.com/joreen/tyranny.htm

psychohistory is real:
https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0237458&type=printable

Crafting Interpreters – Nystrom

I have read this book, went through the exercises and went back to reference this book a number of times.
It’s 10/10 excellent
but I confess I almost forgot to write a review as I mostly read it online and only bought the (heavy book. See pic) to make sure the author got paid for his brilliant work.

Summary: “A comprehensive introduction to writing an interpreter for a dynamically typed, object-oriented toy programming language (Lox). Throughout the book the author develops two complete interpreters for the language from start to finish, including all the front-end and backend parts. The first is a simple AST walking interpreter implemented in Java, and the second is a moderately optimized VM written in C, including a garbage collector.” (src)

Crafting Interpreters Book

Batteries Included = Comes together with all possible parts required for full usability

Every developer should:

  1. Implement a programming language at least once.
  2. Use this book as a guide.

I confess I didn’t arrive at this book naively. I have previously taken 1 university course on compilers and implemented parts of a language naively, i.e. just having a go without any advance thought. If possible I would recommend “having a go” first as it will truly make you appreciate how great this book is.

Robert Nystrom gently leads you down the garden path of creating an interpreter in java and then in C. Even with no C/java experience I think most people could follow along. In fact a major positive of the book is that all code is covered in the book. In theory and mostly in practice I did this. I implemented the language as I followed the book. I wasn’t making his lox language but every step he showed was applicable and useful.

Since I’ve been writing a language on/off for a few years and recently stumbled upon the book. I’ve been particularly interested to read the parts of the book I’ve already implemented to see how someone else approached or thinks about the problem. It has been highly amusing, Robert has some keen insights and his diagrams are brilliant!

If you are a programmer buy this book and more importantly follow it to implement a language that interests you.
The insight it will give you long term is invaluable.

Link to referenced summary: https://eli.thegreenplace.net/2022/book-review-crafting-interpreters-by-robert-nystrom/

Bonus Points: +1 for the author as I emailed them in 2020 when I read the book and they gave a detailed reply to a particularly niche query. Thanks Bob.

Traction – Weinberg and Mares – Book

Traction – How any startup can achieve explosive customer growth

Overall: 9/10

I orginally purchased this book in July 2016 and I’ve returned to it throughout the year to re-read sections and twice to re-read it fully. Contains a simple approach that forces developers like me that typically prefer development to sales to
a) Realise the importance of distribution
b) Apply an engineering approach to achieve that.

Book Notes:

Traction = Quantitive evidence of customer demand.

Channels:

  1. Targeting Blogs
  2. Publicity
  3. Unconventional PR
  4. Search Engine Marketing
  5. Social and Display Ads
  6. Offline Ads
  7. Search Engine Optimiziation
  8. Content Marketing
  9. Email Marketing
  10. Engineering as Marketing
  11. Viral Marketing
  12. Business Development – Partnerships
  13. Sales
  14. Affiliaite Programs
  15. Existing Platforms – Facebook, app marketplaces
  16. Trade Shows
  17. Offline Events
  18. Speaking Engagements
  19. Community Building
  • Chapter 2 – Distribution
    • “Almost every failed startup has a product,
      What failed startups don’t have enough of is customers”
    • Traction and Product are equally important, spend 50% on each
    • 1st set a traction goal
      • Make something people want
      • Market it
      • Scale
    • Intially you are NOT trying to capture all the water
      You only need to send enough through to find if it works or where the leaks are.
    • Find bright spots within customer base
  • Chapter 3 BullsEye
    • “It is very likely that one traction channel is optimal”
    • Bullseye – Force to consider all options (find underexploited), then focus on one.
  • How much will it cost to acquire a customer
  • How many customers available through this channel
  • Are they the customers we want now?

Middle Ring – For each construct a cheap test.

“When testing, you are NOT trying to get a lof of customers. You are simply trying to determine if it’s a channel that could move the needle for your startup.”

Chapter 4 – Traction Testing

  • Middle Ring – Goal is to find promising channel
  • Inner Ring
    • Optimization
    • Uncovering strategies within the channel
  • “Over time all marketing strategies result in shitty click through rates” – Andrew Chen

Chapter 5 – Critical Path

  • Traction trumps everything – Define your critical path
  • This may involve stepping stone goals – to develop product or form partnership.
  • This should also dicate product, Do we need SSL/security/SSO for current customers?
  • Lay out your milestones
  • Stay on the critical path.

See also: https://chrisgimmer.com/marketing-flywheel/

Company Contractor Cash Flow Diagram

code:

digraph G {

subgraph cluster_0 {
label = “Me”;
node [style=filled];
pension salary dividend mbalance ISA stocks expenses;
color=blue
}

subgraph cluster_1 {
node [style=filled];
NIC VAT CapitalGains IncomeTax Corporation;
label = “Gov”;
color=red
}

subgraph cluster_2 {
node [style=filled];
profits revenue cbalance employee;
label = “Company”;
}

mbalance -> pension;
IncomeTax -> pension [label=”tax relief”];
mbalance -> stocks;
stocks -> mbalance;
stocks -> CapitalGains [label=”10% tax”];
ISA -> mbalance;
mbalance -> costs;
revenue -> pension [label=”40K limit”];
revenue -> VAT [label=”14.5% VAT on revenue”];
cbalance -> dividend [label=”pay shareholders”];
“UK customer” -> revenue [label=”pays for services\n+20% VAT”];
customer -> revenue;
revenue -> profits;
profits -> cbalance;
revenue -> costs;
cbalance -> employee;
profits -> Corporation [label=”19% of profits”];
employee -> NIC;
employee -> salary;
salary -> IncomeTax [label=”20-45% tax”];
costs -> expenses [label=””];
pension -> mbalance;
dividend -> mbalance [label=”2K allowance”];
dividend -> IncomeTax;
salary -> mbalance;
mbalance -> ISA [label=”20K annually”];
}

The Continuing Transformation of the Tech Industry

Assumed Axioms:

  1. Technology has impacted the world in 3 waves (List of companies by founding year)
    1. Hardware – Building the infrastructure
    2. Software – Easily scalable businesses e.g. social media
    3. Hybrid – Combining real-life and assuming always available internet.
  2. Software is eating the world (source) – “More and more major businesses and industries are being run on software and delivered as online services”
  3. Startups and tech in general can be thought as an expanding fractal, reaching all areas of our lives (fractal idea).
  4. The rise of open source can be explained as eating it’s way up the stack as each layer becomes commoditized.

The Past: 1980-1995 – The Transformation of the computer Industry

source: Andrew S Grove – Only the Paranoid Survive

The industry:

  • Had been vertially aligned. i.e. A handful of suppliers, delivered the full end to end package to allow using the hardware and software.
  • A significant change was the standardization of the IBM PC
  • This and other changes allowed shifting to a horizontal marketplace, allowing companies to specialize within each layer and to save costs and earn more profits.
    Microsoft/Intel probably being the biggest winners.

The Present

Any company essentially bundles a bunch of processes/people that allows solving problems within one encapsulated entity, I’ve blogged before about banks as a stack:

The Future

  1. What are the stacks of services that currently deliver value end to end?
  2. Is that market vertical or horizontal?
  3. What model is likely to win under which scenario? You may even see a mix.
    e.g. Apple has vertical integration of iphones, with some horizontal experimentation allowed within the app store, which they then take-over.
  4. You may even find that what wins in the early-stages becomes replaced later.
    e.g. Tableau was excellent software and got deployed at 1000s of companies
    However once it proves the model, the more successful it becomes the easier it may be to replace with an open source alternative.

Prediction: Open Source Eats it’s way up the Pyramid

Stack of oranges in pyramid shape against grey background - CSF015212 - Dieter Heinemann/Westend61

If you consider most companies as a stack, that software is expanding everywhere and that once it’s used by a significant number of users that an open source version becomes more likely. I think we will see open source companies appear at the bottom of the stack and continue to the top.

Question: What would stop it winning a layer?

Thoughts:

  • A small developer user base. If most users are not programmers, no one will write it.
  • A small user base. Without a wide base to support it, only 1% of users may pay or contribute for open source so it won’t be supportable. In fact if a piece of poor software is introduced it could result in a failed market. i.e. the open product is bad but good enough such that a “better” commercial alternative isn’t viable.

Technology Companies by Founding Year

Steve Case the Third Wave.
https://www.youtube.com/watch?v=u4WS4DhekWU

  • Hardware
  • Pure Software = Overnight
  • Hybrid – Real-Life+Software mixed. Internet integrated sometimes invisibly.

1963 – AMD BIG
1968 – Intel BIG
1974 – FoxConn BIG
1975 Microsoft BIG
1976 – Apple BIG
1977 – Oracle
1984 – Sybase Database, MathWorks Matlab, Cisco, Dell BIG
1985 – Corel Draw
1987 – McAfee virus, Wolfram, Peoplesoft ERP
1988 – Avast Security, Trend Micro Security
1989 – Citrix Remote
1990 – BusinessObjects SAP
1991 – AVG security
1991 – Macromedia Multimedia, Palm PDAs, SUSE linux
1993 – Informatica, Qlik Visualization, Redhat Linux, Tucows Domains, Nvidia
1994 – Amazon, RealNetworks Media
1995 – Cisco Webex, MySQL AB
1996 – Ancestry.com, Taleo HR, Sleepycat DB, Juniper Networks, F5 Networks
1997 – Blackboard Education, Kaspersky Lab Security, TIBCO
1998 – BroadSoft Networking, Symbian OS, VMware VMs, Google BIG
1999 – Apache Foundation, Basecamp, DivbX, Fieldglass, Napster, Salesforce
2000 – Tripadvisor, Mobipocket, Sportradar, Jetbrains Java, zipcar
2001 – Foxit, LumenVox Speech
2002 – Shazam, Linkedin BIG, Meetup, GoPro
2003 – Docusign, LogMeIn, Palintir, ServiceNOW, Splunk, tableau, Skype, Tesla
2004 – APIgee, Canonical OS, SugarCRM, Facebook BIG
2005 – Automattic WordPress, Infobright DB, Mozilla Corp, WorkDay HR, Etsy
2006 – MuleSoft, OpenDNS, Xero Accounting
2007 – Heroku, Lucidworks Search, ZenDesk HR, ZeroTurnaround Java, FitBit
2008 – Balsamiq, Github BIG, airbnb BIG, Twilio
2009 – Grindr, NetObjects, PagerDuty, Okta ID, SendGrid Email, WhatsApp BIG, Uber BIG
2010 – Datadog Monitoring
2011 – Firebase, Hortonworks Data, Zoom Video, Twitch
2012 – G2crowd, Looker, PlanGrid, Instagram BIG
2012 – Databricks, Docker

Developers, Code Cowboys and Architecture Astronauts

Developers, Code Cowboys and Architecture Astronauts.
Slums, Skyscrapers and Ghost Cities.
Similar to constructing buildings, there are (at least) three approaches to software development:

devs-coders-cowboys

Coders = Slums – Quickly built using material and knowledge at hand to develop for a small audience quickly. Good ideas will be copy-pasted from one area to another and modified to suit the individuals needs. We can cover a lot of ground quickly but it doesn’t scale, plumbing and electricity break down.

Developers = Skyscrapers – Construction takes longer, the outcome can result in a uniformity, often piecing together existing architectural concepts or libraries into a fairly standard shape. We can scale to a higher level (density of people) but we need more upfront planning and less individuality.

Architecture Astronauts = Ghost Cities = Master architects devise grand schemes of hugely scaleable systems but there are fundamental flaws in the plan and often the need of actual end users are ignored.

If this conceptual metaphor holds, what could we learn from the building industry?

  • Don’t employ a coder when you need an architect?
  • Sometimes you need to clear a slum, displeasing those residents to replace it with an efficient residential building, which will take time and investment?
  • Building quality needs enforced by external parties?
    Similar to governmental building inspections.
  • Always get the core plumbing right, the facade/paint can be changed later?
  • …?
  • Is there anything they could learn from software development?

Perhaps the most important thing is to decide which category you are aiming for.

 

Trillion Dollar Coach – Bill campbell – Book

Overall: 8/10

I initially breezed through this book in a week thinking it mostly contained nice stories and glib niceties. However going back to  trillion-doll-coach-bill-campbell

write the Book Notes took 3 weeks, I found myself scribbling down page upon page compared to my usual amount of notes. Upon reflection, it was a really good book with lots of good points and anecdotal stories to help remember them. If Bill was getting this many “easy” parts right, I can see how the overall impact would have been large.

My main take-away: Team First – A company is formed from teams, get the right people, built an envelope of trust, support and love them.

Actions:

  • Improve work roadmap meetings. Given we have the whole team present, anything but very effective use of that time is a waste.
  • Re-read project aristotle
  • Think about what makes a good meeting
  • Always set a measurable goal, sometimes a Big-Hairy-Goal to stretch people

Book Notes:

  1. Caddie and CEO
  2. Title makes you a Manager, your people make you a leader.
  3. Built an envelope of trust
  4. Team first
  5. The power of love
  6. The yardstick
  • Caddie and CEO
    • background and some hero-worshiping
    • Teams are building block of a company, not individuals.
    • pg26 Raises interesting possibility of coaches for managers.
      Given the leverage, why are there not coaches providing real-time feedback
    • Mentor vs coach
  • Title makes you a Manager, your people make you a leader.
    • A managers authority emerges as they establish credibility with subordinates, peers and superiors.
    • “It’s the people” – Support = Respect + Trust
      • Support = tools, info, roadmap, training
      • Respect = Career goals / Life choices
      • Trust = Autonomy and Decision Making
    • Lying in bed at night, the CEO should worry most about his staff
    • One to ones and staff meeting are critical.
    • Trip Reports – Having one person tell a personal story of their weekend at a Monday meeeting
    • Decision Making – “Making the right decision is important
      Just as important is getting the whole team there.”
    • Managers job to run decision making process, ensure voices heard, cut tie-breaks when stuck and to remind everyone of purpose and root truths.
  • Built an envelope of trust
    • The first thing some managers focus on is building a product or getting people working. The priority should be to build trust.
    • Bill saw the world as a network of people with different skills,
      learning to trust each other as a primary mechanism of achieving goals.
    • Psychological Safety – The ability for a team member to voice crazy ideas and feel safe from negative repercussions has been found to be critical to success.
    • Coach the coachable – pg86 “A coach is someone that tells you what you don’t want to hear, who has you see what you don’t want to see, so you can be who you have always known you can be.”
    • Honest, humility, perseverance and constant openness to learning.
    • Leadership is about service to something that is bigger than you.
    • Practice active-listening
    • Diane Greene – “When I’m really annoyed or frustrated with what someone is doing, I step back to think about what they are doing well and what their value is”
    • No gap between statements and facts. Give feedback close to the time, in public if good, in private if negative. Always give it from a place of love.
  • Team first
    • Work the team, then the problem.
      When faced with aproblem or opportunity, the first step is to ensure the right team is in place and working on it.
    • Pick the right players. The ability to learn fast, a willingness to work hard, integrity, grit, empathy, and a team first attitude.
    • Bill saw peer relationships as critical and instituted a regular survey amongst peers at google to asses performance at job/relationships/meetings/leadership/innovation.
    • Winning depends on having the best team and the best teams have more women.
    • Identify the biggest problem, the elephant in the room, bring it front and centre and tackle it first.
    • Listen, Observe and fill the communications gaps
  • The power of love
    • Get to know and care for people as individuals
    • Cheer people and their successes

The Unicorn Project – Gene Kim – Book

 

The Unicorn Project Book

Overall 5/10 – Having read and loved the phoenix project, I had high expectations for this book, perhaps too high. It felt like the same message and story regurgitated to sell another book. Perhaps if I hadn’t seen most the ideas before elsewhere it would have felt newer and more impactful.

Book Notes:

  • Compared to the previous book there is a lot more emphasis on people skills,
    it’s great to see this highlighted in a book for programmers where that kind of networking isn’t as common.
    Examples:

    • The “rebellion” team was formed as a ragtag coalition of people that wanted to make a difference
    • Kurt operated at the edge of permitted staff behaviour to get the resources the team needed
    • Maxine visited people outside her own department in person to build alliances
    • She asked how they completed their work and helped them find where they fitted into the overall flow to increase throughput overall
    • Sarahs toxic behaviour and the need for psychological safety
  • Some problems seem highly exaggerated to reach foregone conclusions to point at fashionable technology.
    • For example getting a working build takes weeks = containers.
    • Concurrency issue = Immutability and Functional programming solves the day
    • I wouldn’t disagree that those technologies are great for some problems, it just seemed they were thrown into the book to namedrop.
  • Near the very end it proposes that large companies can outpace their smaller rivals as they have the relationships, resources and data.
    I’m not sure I entirely buy that. One of the hardest things to change is values and perceptions.
  • Project Shamu sounded interesting, taking 23 API calls that have their own SLAs and reducing them to one dependency without caching. I wondered what technology this was referring to but googling didn’t help. Any ideas?

The Five Ideals

These are the ideals presented at the back of the book. I can certainly agree on their importance:

  1. Locality and Simplicity
  2. Focus, Flow and Joy
  3. Improvement of Daily Work
  4. Psychological Safety
  5. Customer Focus