Comment on page
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 just admitting the things are going poorly.
- 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.
- 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.
- Program teams - long-lived, cross-functional teams focused on products
- Platform Teams - specialized, technical mission, customers are other teams (mostly)
- 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.
- 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
- 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
- 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?
- 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.
- 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.- Make experimentation effortless
- Embrace reliable mainstream formats (JSON, RSS, etc)
- Write code that can be replaced
- Manual of Me. - simple document which helps you communicate your working preferences, motivations and needs, so we can all work better together.
- Just Don’t - Sometimes it’s wrong to begin a phrase with the word “just”, this article provides a few examples.
- 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.
- 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.
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.
Last modified 5mo ago