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

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.

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.

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.

Further reading

• OpenAPI - https://learn.openapis.org/specification/
• HTTP/2 Explained - https://http2-explained.haxx.se/
• HTTP/3 Explained - https://http3-explained.haxx.se/

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

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.

REST API design guidelines from Google - https://cloud.google.com/apis/design

From Microsoft - https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md

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.

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

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.

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.

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.

"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.

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?

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

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?

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.

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.

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.

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