• The Complexity of AWS Lambda Stems From the Need to Internalize the Runtime Model

    On it’s surface, AWS Lambda seems simpleβ€”it merely invokes a function with some arguments. However, the complexity is deceptively high. This is best highlighted when something goes wrong.

    Debugging can’t be done remotely so you need to rely on logging, which you need to get from CloudWatch (which is clunky in it’s own way). If you don’t have a log line in just the right place you need to do a full deploy which includes zipping all files that are needed to execute the functionβ€”for Node, that includes the entirety of node_modules which, even for simple things, can be 10s of MBs.

    You also need to contend with the async nature of Node. It’s easy to write your handler only to find that it runs, but doesn’t fully execute. Somewhere you are not awaiting a result and so an early return means the event loop is empty and the runtime thinks you are done. In one case, I could invoke the function locally and it worked just fine (using the serverless cli tool), but in Lambda it failed.

    Finally, the arguments passed in (an event and a context object) are themselves opaque. If you invoke a Lambda from a specific context, it may or may not include some authentication information when using AWS Cognito. You need to keep all of these details in your head, most of which can only be discovered by runtime failures (which I already mentioned are clunky to debug).

    The overall feedback loop is slow (slowness begets more slowness) and difficult to debug due to incidental complexity.


  • Replace Kb With Lbs to Better Internalize Website Bloat

    Modern websites are filled with javascript, assets, tracking, and third-party tracking. This makes websites slow and sluggish (bloat). This is partly due to developers not having the right mental models for how the size of requests impacts performance and taking for granted that modern network speeds and browsers are fast. By replacing kb (kilobytes) with lbs (pounds) when looking at request size you can better internalize the weight of the requests your website is serving.

    Imagine delivering a package (some page request) to a user based on weight. 10 kb -> 10 lbs, no problem! 500 kb -> 500 lbs and that’s like trying to deliver two refrigerators.

    See also:


  • Projections Onto Different Dimensions Aids in Understanding

    A way of making concepts and abstractions easier to understand is to project them onto another dimension and scale. For example, the passage of time and what you can do with it is difficult to fully comprehend so a common projection is ‘time is money’. We understand money as a tangible asset and generally how much things cost (another projection is what you can buy with that money) which makes it easier to value time appropriately.

    However, choosing the wrong dimension is a logical fallacy. For example, asking ‘how red is the temperature?’


  • Heterarchical Note Taking

    Notes can be organized and structured into heterarchies (nodes with multiple relationships without a strict hierarchy) by creating an entry note that encompasses other notes (a note of notes). In Zettelkasten, this is referred to as a ‘structure note’. This has the advantage of late binding, you don’t need to worry about the hierarchy of information up front and multiple associations can be created using the same notes (which would not be possible without duplication in a strictly hierarchical system).

    Heterarchies provide a layer of abstraction over the constituent notes which makes it easier to make connections between areas of thinking. For example, when creating a new note you could review a structure note’s contents to spark ideas for how it might be related without doing an O(n) search through every note in the collection to see if there are connections.

    See also:


  • Performance Archetype of Engineers I've Managed

    Below are some shapes of engineers I’ve managed in my career and what I’ve learned about them. Pattern matching based on experience is important in an experiential field like management.

    Trait Behaviors Lessons learned
    Brilliant, unfocused Extremely productive and helpful, spends time on the wrong thing and spreading their impact too wide Reduce quantity of extracurricular activities, taking on tasks outside of the team should meet the ‘uniquely capable’ threshold
    Unproductive, un-engaged Has the skills, but not delivering enough impact This is very difficult to recover, move them off to another team or manage out
    High output, needs to be pointed at the right problem Highest output on the team, but needs guidance on applying that raw output to be effective Defining the right problem on their own can be difficult, identify the right altitude of problem for them to work on to unlock their abilities
    Technically focused on a product team Tends to raise the importance of building higher quality or new abstractions not taking into account the context of the product, market, or user Set a decision framework for incremental code improvements, avoid rewrites, coach on the business needs and product thinking
    Hard working, low skill Works really late, always busy, but low output or low quality Improve hiring bar, don’t overvalue hard work and avoid spending large amounts of time with low-performers
    Learned helplessness, blames others or codebase often Avoids accountability, low quality output or slow, very unhappy or pessimistic Tends to be an environment mismatch, deliver strong and clear feedback and move quickly to manage out
    Self-righteous, dogmatic, disruptive Strong opinions tightly held, thinks everyone else is wrong or doing a bad job, teammates complain about code reviews Coaching can work, but if there is any negative impact (e.g. people don’t like working with them) need to act very quickly or top performers will leave
    Higher ownership, generalist Tend to act as the founders would act, with a wide range of skill they are company builders Nurture by giving stretch opportunities, encourage stepping out of role, build a better framework for measuring their success
    Disagrees in private, disruptive to management Talking to them everything is fine, even when addressing a disagreement, but shares resentment privately Disruptive for the management team, can be difficult to address. Address directly, if there’s a pattern then move on
    Low output, says all the right things When given feedback they say all the right things, some immediate improvement made, but same issue recurs Recurring low output feedback is a big red flag, especially for senior engineers
    Highly skilled, entitled Doesn’t feel fully utilized, complains about compensation, moves around a lot Ask if they really want to be here, turn their feelings into a challenge and action

    See also:


  • Lowering the Federal Funds Rate Causes All Asset Classes Increase in Value

    Lowering the interest rate has the effect of decreasing the risk for every asset class. This causes the expected return to go up and thus the value of the asset which leads to more buying of assets (for example getting a mortgage for fear of missing out) and greater optimism in the market (more risk taking). This is how the Fed tries to stimulate the economy.

    However, this also makes it harder for lower risk investing (for example pension funds with a 5-7% target return), they will need.

    Low rates make risk aversion harder to practice and risk taking more palatable.

    See also:


  • Perfomance Management Calibrations

    A process for managers and senior leaders to discuss the performance across the organization with the goal of consistently and fairly applying expectations for all roles and levels. This helps to decrease the importance of individual’s personal judgment and biasesβ€”managers are more of an instrument of the performance process rather than the sole arbiter.

    Calibration meetings are scheduled where managers and org leaders review all the performance snapshot packets for the organization and decide on final performance designations. The outcomes are reviewed by organizational leaders and the leadership team to spot check for consistency/fairness and review special cases (low performance, high performance, promotions). Sometimes follow-up information is needed to finalize the designation the manager will be asked to gather.

    See also:


  • Tech Debt

    Accumulated short-term compromises and hacks in a codebase that must be paid down over time. Side effects large amounts of tech debt include decreased velocity of making changes and frequent breakages. However, used well, tech debt can increase the velocity of a team and get more done in less time.

    See also:


  • We Want Stateful Servers, We Got Serverless Complexity

    The rise, and stagnation, of serverless computing could be interpreted as it was too hard (security, reliability, speed) and expensive to run your own server (configuring linux, wordpress/rails). With static websites and serverless compute APIs we get the speed, security, and price that are much more attractive, but it comes at the cost of being more complicated for interactivity (applications, auth, email list subscriptions, payments). You are then forced to patch together a hard to test and brittle series of tools to do more than host static pages such as AWS API Gateway + Lambda + SQS + SES.

    See also:


  • Kelly Criterion

    A formula for figuring out how much you should bet to maximize the outcome.

    Simplified formula:

    O = (P * 2) - 1
    

    Where O is the optimal wager size, P is the probability to win a game that pays out 1:1 (even money payoff where you gain what you bet if you win).

    For example, with a game that has a 60% chance to win with an even money payoff, the optimal wager as a percentage of available funds is (0.6 * 2) - 1, or 20% of available funds.

    See also:


  • Gate's Law

    People are bad at understanding exponential growth. They over estimate short term results and under estimate long term results.

    Full quote:

    Most people overestimate what they can achieve in a year and underestimate what they can achieve in ten years.


  • Most Compounding Interest Benefits Occur at the End

    Due to the nature of compounding interests growing exponentially over time, the immediate benefits of such an effect are small compared to the benefits at the end. This can make it hard to see how certain actions and behaviors lead to compounding because it can take a long time. It makes intuitive sense for things like money (people understand to contribute to a 401k for example), but requires more faith for actions like reading a lot. This explains why a lot of good advice is unlikely to be followed and example of Gate’s Law.

    See also:

    • Naval Ravikant talks about the importance of compounding interests in life and wealth creation.