Work

Get it done - the mandate of your job is not do the best you can but get it done even if the means asking for help, more resources, or admitting that things are going poorly.[^get_it_done]

yak shaving - It refers to engaging in a meaningless task that has no obvious relationship to what's supposed to be worked on but may be necessary to troubleshoot a larger problem. The process of making a simple task unnecessarily complicated may also qualify as yak shaving.

Bikeshedding (also Law of triviality) - tendency to devote a disproportionate amount of our time to menial and trivial matters while leaving important matters unattended.

Truck Factor (TF) is a tool to identify concentration of knowledge in software development environments. It states the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated.

Resources

• Time management
• First-Time Startup Entrepreneurs: Stop Fucking Around
• How to Negotiate a Remote Work Arrangement
• The Importance of Written Communication for Engineering Teams
• How to Work Hard
• Delegation is an art, not a science
• How to feel engaged at work: a software engineer's guide
• Working Multiple Jobs
• Giving a Shit as a Service

  So, I suppose the moral of the story is: find yourself work you can give a shit about. And work with people who give a shit. It’ll make shit a lot more pleasant – I guarantee it.

• Average Software Engineering Salaries by Country in 2022 (Comparison of 20+ Countries)
• Key Capabilities to drive improvements in Software Delivery Performance
• Be good-argument-driven, not data-driven
  • Prefer good arguments over bad data when making decisions. The metrics need to be well-understood and free from human/social factors if one wants to make decisions based on them.
• The Platform and Program Split at Uber: A Milestone Special
  • Program teams - long-lived, cross-functional teams focused on products
  • Platform Teams - specialized, technical mission, customers are other teams (mostly)
• The Hierarchy Is Bullshit (And Bad For Business)
• The Product Culture Shift
• On the team as a system
• How to plan?
• What to do when a beloved employee quits
• Engineering Ladders - This framework allows software engineering managers to have meaningful conversations with their direct reports around the expectations of each position and how to plan for the next level in their career ladder.
• Heroes and Juniors: Increasing Engineering Team Velocity
• Facebook Engineering Process with Kent Beck
• It's Time to Do More With Less
• Why Groups Struggle to Solve Problems Together
  • Leaders are too lazy to craft thoughtful agendas.
  • Managers hold pointless meetings as a way to flex their power.
  • Distracted attendees, selfishly preoccupied with their own work, come woefully unprepared.
  • 5 stages to solve a problem:
    • define the problem
    • generate solutions
    • evaluate solutions
    • pick a solution
    • make a plan
  • we move between the stages back and forth, it's not a linear progress
• I’ve been employed in tech for years, but I’ve almost never worked #work #antiwork
  • task bloating - overestimating the time a task will require
• Andrew Bosworth's Blog - blog that cosues on work, impact, workplace behaviour, and more. Shortform articles. #blog #work #workplace #productivity

Engineering

• Practical Guide to Solving Hard Problems
• Oncall Compensation
• 6 Tips to Overcome Scaling Challenges Like Design Decisions, Tech Debt, and Developer Satisfaction
• Flo Health’s path to the hiring strategy in engineering
• The Future of Ops Is Platform Engineering
• Daily Standups: The complete guide to productive meetings
  • keep it short, 15 minutes
  • what to discuss:
    • What did you do yesterday?
    • What are you planning to do today?
    • Are you facing any blockers?
• Addressing Tech Debt
• The 25 Percent Rule for Tackling Technical Debt
• Cynefin for Developers
  • classifies 4 kinds of problems:
    1. Obvious: tightly constrained, no degrees of freedom, sense-categorise-respond, apply best practice. E.g. a bike chain falling off - the reaction is "Oh, it's one of these problems", there's one and only best practice to solving it.
    2. Complicated: governing constraints, tightly coupled, sense-analyse-respond, apply good practice. E.g. repairing a watch, the solution is predictable but requires expertise, usually have more than one way to solve.
    3. Complex: enabling constraints, loosly coupled, probe-sense-respond, emergent practice. Acting in this space causes the space to change, cause and effect can only be understood in retrospect. Try solution that can fail, safely, to understand the problem. We need to change our practices around the problem.
    4. Chaotic: lacking constraints, decoupled, act-sense-respond, novel pratice. E.g. the hause catching fire - first we act. New practices emerge that can make us help things safer in the future.
  • If you’ve done it before, requirements are known.
  • If someone else has done it before, requirements are knowable, having conversations about the problem can provide understanding of the domain.
  • If it’s never been done before by anyone, requirements will change.
• The Ambiguous Zone - about finding the balance between Do what I'm told and Do what I want. Good engineers operate well in between those two zones.
• Being Right Doesn’t Matter - "Being Right is a Booby Prize If You Can’t Persuade Others"
• OKRs are hard
• You Want Modules, Not Microservices
• A Framework for Prioritizing Tech Debt
• Rewrite, refactor, or reinvent?
• How to be a -10x Engineer - how to be the oposit of 10x engineer
• Why Engineers Need To Write #writing #engineering #technical-writing
• Accountability for Effective Teams #accountability #work
  • Accountability is caring and being able to explain yourself
  • Accountability should focus on behaviour, not numbers - numbers are often outside the people's control and basing accountability purely on numbers can lead to undesirable outcomes, e.g.:

  This accountability-to-understand is compatible with systems in ways that accountability-for-outcomes is not. If your job depends on moving a number, you’ll move that number, even if it puts your widget in everyone’s way and pisses off customers. If your job depends on the whole business succeeding with your contributions, then you’ll make your widget compatible with its surroundings, and highlight it in ways that improve the product.

• How Google Measures and Manages Tech Debt
• IKEA-Oriented Development #software-engineering
  • Make experimentation effortless
  • Embrace reliable mainstream formats (JSON, RSS, etc)
  • Write code that can be replaced
• Team Topologies
• Reasonable Person Principle
  • Everyone will be reasonable.
  • Everyone expects everyone else to be reasonable.
  • No one is special.
  • Do not be offended if someone suggests you are not being reasonable.

Soft Skills

• Software Engineering - The Soft Parts
• Manual of Me. - simple document which helps you communicate your working preferences, motivations and needs, so we can all work better together.
• Questions for our first 1:1
• Just Don’t - Sometimes it’s wrong to begin a phrase with the word “just”, this article provides a few examples.

Other jobs

• Fredericton-based YouTuber woodworks his way to 1.72 million subscribers

Notes

Agile

Four values of Agile

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and
• responding to change over following a plan.

The 12 principles

• Satisfying customers through early and continuous delivery of valuable work.
• Breaking big work down into smaller tasks that can be completed quickly.
• Recognizing that the best work emerges from self-organized teams.
• Providing motivated individuals with the environment and support they need and trusting them to get the job done.
• Creating processes that promote sustainable efforts.
• Maintaining a constant pace for completed work.
• Welcoming changing requirements, even late in a project.
• Assembling the project team and business owners on a daily basis throughout the project.
• Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
• Measuring progress by the amount of completed work.
• Continually seeking excellence.
• Harnessing change for a competitive advantage.

CAP Theorem

The CAP theorem, states that any distributed data store can provide only two of the following three guarantees:

• Consistency - Every read receives the most recent write or an error.

• Availability - Every request receives a (non-error) response, without the guarantee that it contains the most recent write.

• Partition tolerance - The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

• A Critique of the CAP Theorem

[^get_it_done]: Get It Done by Andrew Bosworth