21 Matching Annotations
  1. Dec 2023
    1. four critical aspects of supporting: Attending Acknowledging Affirming Appreciating

      This seems like a good model for parenting as well. It gives a framework on how to support your kids well.

  2. learning.oreilly.com learning.oreilly.com
    1. When you are involved in a coaching relationship you communicate via words (what you actually say), paralinguistics (how you say your words) and body language (what you do while talking and listening to others)

      Eye contact and making the person feel like all you're doing is being present for them is what I've found to be crucial in establishing a trusting relationship and to get them to open up more.

  3. learning.oreilly.com learning.oreilly.com
    1. what is a good question? A good question is one that does not make assumptions or judgements, either in the way it is framed or in the tone in which it is asked.

      This hints at the question springing from genuine curiosity over anything else. There could be a lot of questions asked for bad reasons, like for the optics of it, where the person wants to make themselves visible, or show off their knowledge or expertise.

  4. learning.oreilly.com learning.oreilly.com
    1. ‘You’re always dealing with probabilities. No issue comes to my desk that is perfectly solvable, because if people were absolutely certain, then it would have been decided by somebody else.’

      said by Barack Obama.

      This highlights the importance of the kind of people who can manage and lead effectively. In addition to being competent in the core attribute of the job, like technical proficiency, they have to be good at managing complexity, whether it's in the way of managing information flow through the organization, or political winds across.

    1. Summary
    2. Modeling Exchanges and Choosing an API Format

      Volume of traffic has a significant impact of the choice of the API architecture, like REST, RPC and GraphQL

      Footprint of the payload and performance considerations also do.

      Generally speaking, RPC mechanisms make sense for East-West traffic and a REST-based system for North-South traffic

    3. Specifying REST APIs Using OpenAPI

      Why OpenAPI? What problems does it solve? What are the limitations?

      Code generation - It helps generate producer and consumer codes that will accelerate developer productivity, by the way of removing manual drudgery and by speeding up contract negotiations

      Reduced cognitive load - Although not as acknowledged, standard ways of defining, and communicating things reduce the cognitive load on the consumers.

      Validation - Standards help build tools that solve problems like request/response validation against a specification

      Examples and mocking - Again, better tooling helps with things like code generation for testing the API, and to generate example requests and responses

      Detecting changes - It makes it easier to diff different versions of the APIs, again reducing the cognitive load on the developers.

    4. guidelines
    5. Remote Procedure Call (RPC)

      Differences between RPC and REST:

      Architecture: RPC follows a client-server architecture with tight coupling between client and server, while REST uses a layered architecture with loose coupling based on HTTP verbs and resource representations.

      Data format: RPC typically uses custom data formats for efficiency, while REST primarily uses JSON or XML. Flexibility: REST offers more flexibility in resource access and manipulation through different HTTP verbs, while RPC is focused on specific procedures and functions.

      Scalability: REST can be more scalable due to its stateless nature and separation of concerns, while RPC might require additional considerations for scalability.

      Communication style: RPC is synchronous, meaning the calling program waits for the remote procedure to finish and return a result before continuing. REST is asynchronous, meaning the calling program can continue without waiting for a response.

      Resource representation: RPC focuses on procedures and functions, while REST focuses on resources and their representations (e.g., JSON, XML).

      Standardization: RPC protocols are often specific to a particular framework or platform, while REST is based on well-defined HTTP methods and well-known principles like HATEOAS (Hypertext as the Engine of Application State).

      Complexity: RPC can be more complex to implement and debug compared to the simpler, standardized approach of REST.

      If you need high performance, tight coupling, and efficient data transfer, RPC might be a good choice. However, if you value flexibility, loose coupling, and integration with existing web technologies, REST might be a better fit.

    6. Level 2 - Verbs (Methods)

      Level 2 introduces verbs and error codes on top of resources, from Level 1.

    7. Level 1 - Resources

      This goes a step beyond Level ), and introduces "resources", but the behavior, on a given resource, is still determined by the information contained in the headers, or arguments, since it doesn't work with verbs.

    8. Level 0 - HTTP/RPC

      This feels more like GraphQL where there's a single URI exposed by a service/producer and the shape/form of the request determines the action by the service and the corresponding response. It's similar to function overloading in spirit where the shape of arguments determine the behavior of the function.

    9. REpresentation State Transfer (REST) is a set of architectural constraints, most commonly applied using HTTP as the underlying transport protocol

      The guiding principles gear towards simplicity, interoperability, and scalability.

      Simplicity - Entities are modeled using "resources" located using a URL, which are consistent, semantic and predictable. You interact with the resource using logical actions/verbs.- GET, PUT, POST, DELETE and PATCH

      Interoperability - They use interfaces that are standard, like HTTP as the protocol, and JSON, or XML and such as the data formats

      Scalability - The requests are stateless, which means that a request from a consumer can be forwarded to any producer of the same resource. The requests/responses are cacheable by the consumers, mainly through information via the headers.

    1. Performance

      "Core performance" would probably describe this better, since this talks about the performance in the core competence dimension of a software developer. A generic name like "Performance" can be misleading since performance of a software engineer is much more than the quality of code.

    2. Burnout

      Questions to managers for their directs - * How good or bad do you feel on Mondays going back to work after a weekend? * What part of your work do you hate most, in other words, what part of your work stresses you the most?

    3. Developer efficacy

      Questions to managers for their directs - * What do you think about the amount of friction or overhead you face to get things done?

    4. Employee satisfaction

      Questions that managers could ask their direct reports to gauge this -

      1. How satisfied do you feel working in the team, and with the projects that you're in?
      2. What are two things that you'd change about your team?
      3. How do you like the projects you work on? If you had a choice, what other projects you'd work on instead?
    5. Often the critical work needed to keep the environment and culture healthy can be "invisible" to many members of the organization or to metrics traditionally used for measuring productivity. Work such as morale building, mentoring, and knowledge sharing are all critical to supporting a productive work environment and yet are often not measured. The "invisible" work that benefits the overall productivity of the team is just as important as other more commonly-measured dimensions

      This speaks to the myth that developer productivity is solely the responsibility of the developer. In fact, the culture, the opportunities, and the feedback play an significant role in developer productivity, which is evident from the fact that an engineer might be the most productive person on one team, and a sub-par one at a different one.

    6. Myth: Productivity is all about developer activity

      In this case, the activity could be an input metric, like the # of hours a developer is working, or an output metric, like the # of lines of code, or the # of PRs and so on, both of which are tricky to be used as sole indicators of productivity.

      Adding to this, developer activity is often seen through a narrow lens of code. While that's true for junior engineers, software engineering is much more than writing code, especially in senior positions, and involves planning, documenting, communicating/collaborating, execution, monitoring and maintenance.

    7. Myth: Productivity is only about individual performance

      This highlights the "tension" between metrics that the authors talk about earlier in the article. Sole focus on individual performance might result in a "shitty" team full of rockstars. In other words, team performance and individual performance both need to be considered and leaders should strive to strike a healthy balance between the two.

    8. The most important takeaway from exposing these myths is that productivity cannot be reduced to a single dimension (or metric!). The prevalence of these myths and the need to bust them motivated our work to develop a practical multidimensional framework, because only by examining a constellation of metrics in tension can we understand and influence developer productivity. This framework, called SPACE, captures the most important dimensions of developer productivity: satisfaction and well-being; performance; activity; communication and collaboration; and efficiency and flow

      A good thing about this framework is that while it's intended to measure productivity in a more objective manner, it doesn't eschew subjective dimensions like satisfaction and well-being, which are largely personal and self-reported