开源日报 - Page 137 of 262

开源日报第496期：《做 ppt 的 nodeppt》

24 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《做 ppt 的 nodeppt》
今日推荐英文原文：《How to Solve Any Code Challenge or Algorithm》

今日推荐开源项目：《做 PPT 的 nodeppt》传送门：GitHub链接
推荐理由：一个能用 markdown 文件生成 PPT 的项目，支持各种样式，布局以及方便强大的语法。它还扩展了 markdown-it-container 语法，简而言之，你可以像通过 HTML 里的各个标签以及它们的 class 来控制样式一样控制一段 markdown 文件的样式，而这能够更灵活的控制生成的 PPT 的效果。

今日推荐英文原文：《How to Solve Any Code Challenge or Algorithm》作者：James Dorr
原文链接：https://medium.com/swlh/how-to-solve-any-code-challenge-or-algorithm-c66e0bed9dc9
推荐理由：解决代码或者算法问题的通用步骤
How to Solve Any Code Challenge or Algorithm
“Know algorithms!” When you’re searching for jobs in tech, this is frequent advice. Most articles about algorithms and coding challenges seem to recommend practicing them so much that you‘ll recognize almost anything an interviewer might ask you. Practicing algorithms and explaining the solutions out loud are very important — you want to be able to explain your ideas — but problem solving in software and web development requires more than rote memorization.
Computer Science is a science of abstraction. -Alfred Aho

Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. -Edsger Dijkstra
Good code is abstract, so let’s apply that same logic to our problem solving! These steps are not specific and can be applied to most code challenges.
Summary
We only need a few oft-repeated steps to solve any code challenge.
1. Understand the Problem
2. Choose a general direction
3. Identify what you can do
4. Search for what you cannot do (and need to do)
5. After finishing, try to improve it
We’ll use LeetCode.com’s problem 130, “Surrounded Regions” for examples. If you’re looking for the optimized answer, skip down to the section Try to Improve It at any time.
Understand the Problem
Thoroughly understand the problem before you dive in. Ask questions, if necessary! You can do it! They wouldn’t ask this if you couldn’t.

I chose this problem for many reasons. First of all, this question isn’t obvious. It’s not a question we have probably ever been asked before. Read it as many times as needed and study the expected input and output (if available).

This problem wants us to only leave Os that have a path to a border. “Surrounded Regions” of Os are converted to Xs.

Change the matrix on the left to the matrix on the right
Choose a general direction
When working on projects, this might mean deciding where the solution should go. Is this better suited for the frontend or the backend? In the frontend, is this the right component for that logic? In the backend, how can we use RESTful routes? Do we want that RESTful route to always perform this logic?

For LeetCode, I chose JavaScript because I am trying to fine-tune those skills.
Identify What You Can Do
Do anything you can do that moves towards solving the problem, no matter how small. Even getting “Hello, World!” on the screen is better than a blank screen.

Especially if you’re feeling overwhelmed, make sure the code is behaving as expected. Console.log or print! Maybe we don’t know much, but we now know the input (if we didn’t before) and we know that we wrote our function correctly. Any confidence boost is welcome!

For the LeetCode problem, I used console.log to print the board, then its rows, and finally the characters in the rows — just to make sure I was iterating over the entire input correctly.

What can we do next? A huge, huge part of problem solving is breaking it down into smaller chunks. Even if it’s minuscule, what do you know how to do next?

I chose to see if I could write code to identify which Os were on the border.
```
function isOnBorder(y,x){
    return y===0 || y===board.length-1 || x===1 || x===board[y].length-1
}
```
Sometimes in coding, it’s easier or more helpful to do the opposite.

This code will console.log(‘noooo’) every time there is an O in the interior

Great! What small step can we take next? Let’s check that Os neighbors to see if they are Os!

The function checkFriendsOnBorder(y,x) prints out ‘VEIN!’ if the O has a neighboring O

I also put in comparisons at the beginning of the “if” statements because I knew JavaScript would throw an error or give the wrong information if the indices were negative or higher than the length of the arrays. But how would the indices be past safe ranges if this function was only run on Os that were in the interior, not on the border?

The intent was to eventually iterate over an array and add all of the O neighbors to that array, thus moving across the “board,” finding the group of Os that the original interior O belonged to. Then, if any of the Os were on the exterior, that original O could stay. However, this got confusing and ugly quickly, so there must be a better way. If you’re feeling confused during your own projects, it’s time to circle back to the steps Understand the Problem and Choose a General Direction, or maybe a more specific direction, now. Here, we will continue and I will explain my problem solving chronologically.
Search for What You Cannot Do
If you have an idea but are not sure how to implement it, search for the answer online! Maybe you haven’t learned a certain function of your computer language yet, or maybe someone has a piece of the puzzle you can borrow!

In this problem, I searched for iterating over a growing array and found that functions assume the source data is not mutated, so that was a no-go. My own experiments within LeetCode yielded similar results — using “array.forEach…” never continued with the information that was added (.push()) onto the array, but “for(let i=0;…” occasionally did. I didn’t understand why the “for” loops were inconsistent, so I labeled that approach unlikely to succeed.

Next, I tried to use recursion and got errors because the Os were looping infinitely back and forth with their neighbors. Then I made arrays of “veins” for each O to make sure the code was not running over any O twice while making the vein. That also taught me that JavaScript arrays cannot use .includes([‘an’,’array’]) or .includes({an: ‘object’}) because they check for matching memory locations, not values.

In short, you can learn a ton from this step, and that inspired me to combine a few of the above ideas.

My first successful solution

First, I iterated over each character on the board and put the Os that were on the border in an array to be iterated over later. I put the coordinates of the Os in the array because they were necessary for moving across the board and changing the character, if necessary. Those coordinates had to be in a string to be found by .includes(), so I separated them by a dash just in case some test boards had indices in double digits.

Then, I used a “for” loop to iterate over the border Os and add all of their neighboring Os to the same array (still in the crazy string format). For some reason, I was still having trouble with recursion, so I used a “for” loop, instead. This “for” loop worked with the expansion of its source array, gathering all of the Os with any degree of separation from the border. It checked to make sure not to add them twice, otherwise we would be in an infinite loop.

Lastly, the code iterated over the board characters again and changed each O to an X if its coordinates were not in the borderVeins array.
Try to Improve It
Success! I clicked “submit” and saw “Accepted.” Yes! And it also said “Faster than 15% of submissions” and “Your memory usage beats 32% of submissions.” We can do better!

Play around with the code! Try to make it more efficient.

After that, look at some other people’s answers! Both LeetCode and CodeWars have other answers available. I clicked on the answer with the most votes and looked at it just long enough to see that
1. They iterated over the code multiple times, changing border Os and their groups to 1s and then back to Os at the end
2. They used recursion!
I carefully studied the recursion, even though it was in C++ — You can learn about other languages like this on LeetCode, too! Keeping those details in mind and aiming not to directly copy the entire answer, I headed back to my code to optimize. A more optimized solution Faster than 91.12% of submissions, memory usage less than 100% of submissions
Ta-da! The code looks much cleaner, and LeetCode tells us that it also runs faster with less memory usage. Wonderful!
Takeaways
Another reason I chose this problem was because it was not easy. I got discouraged, but I kept telling myself I could solve it, and I did! I also understand recursion better, as a result. I don’t remember what I was doing wrong before, but now I have successfully used recursion in JavaScript, and I have that tool in my toolbox!

The best reward is proving the little negative voices in your head wrong. You did it! It was just imposter syndrome. You can solve these, as long as you keep believing you can. Stick to these steps, with an emphasis on taking small steps that you know you can accomplish, and go solve more problems!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第495期：《工具箱 hutool》

23 7 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《工具箱 hutool》
今日推荐英文原文：《Should You Use Machine Learning?》

今日推荐开源项目：《工具箱 hutool》传送门：GitHub链接
推荐理由：一个为 Java 语言提供的工具包，旨在将一些常用的代码融合为一个函数方便使用。诸如发送邮件，使用 md5 加密等等代码在实际使用中并不算是少见，与其复制这些代码到各处，不如直接作为函数使用它们，于是就有了这些函数组成的工具包。如果刚好需要这其中的一些功能的话，引入它们所属的模块来简化操作是个不错的选择。
今日推荐英文原文：《Should You Use Machine Learning?》作者：Devin Soni
原文链接：https://medium.com/better-programming/should-you-use-machine-learning-73a7746f7280
推荐理由：机器学习可不是解决问题的万能药
Should You Use Machine Learning?

How to know if machine learning can solve your engineering or business problem

Introduction
It’s become very trendy to use machine learning to solve technical problems. Companies spend a lot of time and effort finding employees who can leverage these techniques to approach complex tasks which may have previously been unsolvable with traditional methods.

However, how do you know if you really need machine learning?

Even though these techniques can be very useful, they don’t fit every situation. If you try to apply machine learning to an inappropriate task, you may waste time and money, and could end up with a poorly-performing model that is not useful.

In this article, I will go through some questions you should ask when determining whether or not machine learning is right for your situation. These should act as a framework to guide your decision-making process.
The Task
The first thing to think about is whether or not your task is well suited to machine learning.

Do you have a well-defined problem with clear inputs and outputs? It is essential that you have a clear idea of what your model would have as inputs and outputs. Otherwise, you may have a difficult time in the feature engineering and evaluation stages of producing a machine learning model.

Do you have metrics that you can use to evaluate a model’s performance and to compare different models? Without an easy way to evaluate models, you will have a difficult time determining whether your model was successful, and in choosing which model to use. You will also have a difficult time iterating upon, and improving, your model as your use-case evolves over time.

Does the problem require an approximate solution? Most machine learning algorithms are used in situations where there is no exact way to find a solution, or the exact solution is too costly to implement. If your problem does have a method to solve it exactly, such as through the use of regular expressions, classical optimization techniques such as linear programming, or older AI techniques such as constraint satisfaction problems, then you may be better off using these methods instead.

Does the problem fit the machine learning paradigm? Most machine learning algorithms rely on the idea that current data will be useful in predicting or classifying future data. If your situation is prone to external events invalidating previous data, then machine learning will most likely not be effective. Similarly, if previous data has no relevance to future data, your model will not learn any useful trends that help you understand incoming data in a real-world setting. It is essential that your model sees relevant past data in order to use machine learning effectively.
The Data
Next, you must determine whether or not your data is suitable for machine learning.

Do you have reliable data labels? Most machine learning methods (the supervised kind) rely on the presence of labels for each data point you have. These labels should be as free of noise as possible, and should be obtainable at a reasonable cost. If your labels are too noisy, either due to inherent situational difficulty in data collection, or due to poor labeling quality, then your models will most likely fail to properly learn the relationships in your data. Additionally, if it is too costly to obtain labels, you may not be able to obtain enough training data over your model’s lifetime for it to be able to learn properly.

Does the data suit machine learning? The data you use to train your model must accurately represent the real-world data that it will be used on. This does not mean that it must perfectly reflect it, but the closer it does, the more useful and accurate your model will be. Even though there are techniques to ameliorate issues surrounding class imbalance and lack of data availability, it is always best if you can sufficiently supply your models with training data that reflects its real-world inputs. If you train your model with biased training data, and the available feature engineering and preprocessing methods are not sufficient, your model may perform unexpectedly poorly when it faces real-world data. For example, this may occur if you train your model with a heavily imbalanced data set in a classification setting. If your model is expecting to see 1% class A and 99% class B based on its training data, it will perform poorly if the real-world situation has 50% class A and 50% class B (assuming your goal is to maximize accuracy).
The Model
Finally, you must investigate the events that may occur during the life cycle of your machine learning model.

Are the effects and risks of the model well-understood? Are you fully aware of the societal effects of your machine learning model? For example, have you researched whether or not this model may further socioeconomic inequality, or if it may create divisions between people in different socioeconomic groups? It is important that you fully understand the effects of your model beyond your specific engineering or business problem. If your model is prone to algorithmic bias, it is important that you try to address this problem ahead of time, and try to create a training pipeline that removes as much bias as possible from the data. In addition, it is important to be aware of how this model may be abused by adversaries. Are there any ways for personal information to be obtained by reverse engineering the model’s outputs? Can industry secrets be leaked? With respect to these issues, it is important that you understand what data is visible through the outputs of your model, and who is able to access these outputs directly. It may be useful to obfuscate the outputs, so that you can control what information is revealed, and provide strictly what is necessary.

Can you maintain the model over time? In most cases, machine learning models are used throughout time, and are not confined to a single instance of usage. So, it is important that your organization has people who can maintain the model over time. As real-world situations change and drift over time, you are likely to need to retrain your model on current data. For example, a model that inputs natural language will need to be retrained periodically to incorporate changes in language usage such as slang. Even if the real-world data does not change over time, you may want to study the model’s errors and continuously iterate on the model in order to improve performance. Therefore, you most likely need a dedicated group of employees who are able to monitor and improve upon the model. Otherwise, it may quickly become obsolete or even useless, depending on how prone its domain is to change.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第494期：《排版指南 chinese-copywriting-guidelines》

22 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《排版指南 chinese-copywriting-guidelines》
今日推荐英文原文：《5 Key Principles of Software Architecture》

今日推荐开源项目：《排版指南 chinese-copywriting-guidelines》传送门：GitHub链接
推荐理由：使用中文文案时的排版技巧，达成最起码的排版统一可以让团队更像一支团队。排版方面有许多细节是需要通过统一来实现美感的，中英文的空格、标点的使用、专有名词的书写等等，拥有统一排版的文案相较于没有的来说要更为美观这一点是不争的事实。不过不管怎么说，都不要把 github 写成和象形文字一样的 gｲんĤЦ8 才好……
今日推荐英文原文：《5 Key Principles of Software Architecture》作者：Semi Koen
原文链接：https://towardsdatascience.com/5-key-principles-of-software-architecture-e5379cb10fd5
推荐理由：设计软件架构时的关键技巧
5 Key Principles of Software Architecture

What great software architects hide under their belts
Solution architects are the designated experts responsible for a system’s architecture as well as the technical standards (inc. technologies, platforms, infrastructure) of a particular product. They set the vision and their analysis is key to the product’s successful definition, design, delivery and life-time support. They therefore need to understand not only what the business need, but also what is logical, scalable, cost effective and in-line with the overall technology goals of the organisation.

One of the vital skills of an architect is to be able to view the architecture from many different standpoints: each one of them individually might not be fully relevant, but combining them together gives a helicopter view of the product. These standpoints comprise of principles, standards, patterns and anti-patterns, rules of thumb and empirical practices which are essential for decision making towards a particular direction and also evaluating the project’s success.

In this article we will cover those architectural principles that attribute to you ‘sinking or swimming’ in your role as an architect!
“If you think good architecture is expensive, try bad architecture!” — Brian Foote & Joseph Yoder

Solid principles
Let’s start with my favourite subject:

The SOLID principles do not only apply on software development but also when architecting a system.

We will now see how…
Single Responsibility Principle
Each system capability (e.g. service/module/api) should have only one responsibility and as such one reason to change. Keeping the responsibilities as narrow as possible means that the users know of the intended purpose, which leads to less errors.
Open-Closed Principle
This principle postulates that it is preferable to extend a system behaviour, without modifying it. Although it is often not a good idea to try to anticipate changes in requirements ahead of time (as it can lead to over-complex designs), being able to adapt new functionality with minimum changes to existing components is key to the application’s longevity.
Liskov Substitution Principle
In Software Development, this means that derived classes must be substitutable for their base classes, but this principle’s resemblance with Bertrand Meyer’s Design by Contract is how it can be applied to Distributed Architecture: two services communicate effectively and repeatedly when there is a common ‘contract’ between them, which defines the inputs/outputs, their structure and their constraints. Therefore: given two distributed components with the same contract, one should be replaceable with other component with the same contract without altering the correctness of the system.
Interface Segregation Principle
Interfaces/contracts must be as fine grained as possible and client specific, so calling clients do not depend on functionality they don’t use. This goes hand in hand with the Single Responsibility principle: by breaking down interfaces, we favour Composition by separating by roles/responsibilities, and Decoupling by not coupling derivative modules with unneeded responsibilities.
Dependency Inversion Principle
High level modules should not depend on low level ones; they should both depend on abstractions. Likewise, abstractions should not depend on details, but details should depend on abstractions. As such this principle introduces an interface abstraction between higher-level and lower-level software components or layers to remove the dependencies between them.

Courtesy: Being a Data Scientist does not make you a Software Engineer!
The ‘Least’ principles
I am grouping these together due to their naming convention:
The principle of Least Astonishment
The principle of least astonishment (or Least Surprise) suggests that a solution or approach would not surprise a reasonably knowledgeable person in the subject area when encountered for the first time (the audience may vary e.g. end-user, programmer, tester etc). In more practical terms, the principle aims to leverage the pre-existing knowledge of users to minimise their learning curve when using a module, so anything with high unpredictability factor is a good candidate for re-design.

It applies to every single aspect of the architecture: from naming services, to the visualisation of user interfaces, to the design of the domain model.

There are good surprises and then there are bad surprises…
The principle of Least Effort
This principle (also called Zipf’s Law) stems from a basic human behaviour: Everyone tends to follow the path that is as close to effortless as possible. So for example if our design follows a particular pattern, the next developer will follow the same pattern again and again unless there is a significantly easier way to perform the task, in which case they will change! Or, taking this further, once they find acceptable results for a task, there is no immediate need to improve the current solution.
Least effort is a variant of least work
As such it is imperative to aim for a strong start by putting the right architecture in place: it sets high expectations and ensures everyone understands that the quality is not compromised in the project’s lifecycle and it will be adhered to in case of future changes.

For me, the greatness of this principle lies in the fact that its benefits extrapolate: once we put a right design in place, we can create an architectural framework which will be the basis of the next systems we build. In other words, we are able to establish a successful and future-proof template for the organisation’s software systems.

Path of least resistance
The principles of ‘Ecomonics’
These two principles have a common theme: the cost of making the most of an opportunity and the cost of delaying making decisions.
The principle of Opportunity Cost
Every time we make a choice, there is a certain value we place on that choice. Value has two parts: benefits and costs. The opportunity cost of a choice is what we give up to get it. To make a good economic decision, we want to choose the option with the greatest benefit to us but the lowest cost.

For example, if we have two choices, either an in-house built system or an off-the-shelf vendor product and we choose the latter, then our opportunity cost is the shiny new system our development team could have developed but didn’t.

This is what architecture is all about: weighing choices against each other and trying to make an informed decision on which one will add the most value for the project. For instance, a very common dichotomy is whether to create a tactical solution with quick time to market or a more strategic one which will be more expensive now with the view to leverage it in future projects and hence minimise the cost later down the line.

Here are some points to consider:
- What is the time available for the architectural analysis/evaluation? It is challenging enough to come up with one solution, let alone a few!
- What is the product pipeline for the next 1–3 years? And what other projects are lined up? Can you see any synergies?
- What is your current technical debt that you could potentially address?
- And turning this around: How much new technical debt will incur if you pursue a tactical solution?
- Which quality attributes tend to be the most important for systems in your organisation and how will they be compromised by the proposed solution?
- Apart from the architecture team who else is a stakeholder that will affect the decision? The Business? Your boss? The Technical Design Authority? What are the key objectives of each stakeholder? How will you mitigate conflicting needs?
Courtesy: What is opportunity cost
The principle of Last Responsible Moment
This principle (aka Cost of Delay) originates from Lean Software Development and emphasises holding on taking important actions and crucial decisions for as long as possible. This is done so as to not eliminate important alternatives until the last possible moment i.e. wait to narrow the options down until you are better informed.

A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.

One way to mitigate the risk of deciding too late is to build Proof of Concepts (POCs) to prototype the alternative options and demonstrate to the stakeholders what they are asking for.

Early in a project we should make as few binding decisions as possible!
Epilogue
Architectural principles help us evaluate the decisions we make throughout the project and also ensure we are in line with the overall goals, not only for the project but also the organisation’s technology. This is an amalgamation of the five principles we elaborated on:

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第493期：《解决数据问题 bad-data-guide》

21 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《解决数据问题 bad-data-guide》
今日推荐英文原文：《The 3 Capacities of a Good Manager》

今日推荐开源项目：《解决数据问题 bad-data-guide》传送门：GitHub链接
推荐理由：在处理数据时容易遇上的一些问题——比如一年数据除以十二得出每月数据这样的，要知道这十二个月里有冬夏之分等等各种差别，而兴许其中一种正影响着手头上的数据。这个项目介绍了处理数据的一些需要知道的小技巧，不需要太多的统计学知识也能避开一些常见的错误。
今日推荐英文原文：《The 3 Capacities of a Good Manager》作者：Matthew Werner
原文链接：https://medium.com/better-programming/the-3-capacities-of-a-good-manager-a950e798aaaa
推荐理由：不仅是编码能力，管理团队的能力一样不可或缺
The 3 Capacities of a Good Manager

A framework to help you be there for your team

Photo by Startup Stock Photos on Pexels

I recently had a friend lament to me about the stresses at her work brought about by her manager. Let’s call him Josh.

Josh is highly respected where my friend works. He’s great to have in whiteboarding sessions, he seems to always come up with clever solutions, and on top of that, he’s not afraid to roll up his sleeves and jump into the code.

At first, my friend was excited to work with Josh. He’s super talented and very experienced, and so she felt like she could learn a lot. However, after spending a while on the team, she noticed the time between whiteboarding sessions could be pretty stressful, including things like:
- Unplanned work regularly shows up mid-sprint, oftentimes loaded with urgency right before another team’s deadline.
- Pager-duty rotation is notoriously painful. Sometimes you can’t even find the person that owns the code that broke.
- She feels like she’s always doing interviews, but hasn’t seen anyone new join to help add bandwidth.
- It kind of feels like she’s going from performance review to performance review, not really knowing what she’s working toward.
- Twice last quarter, one of the projects her team was working on got cut or had a minor MVP rollout before the team moved on.
On top of all that, she wasn’t sure how to go about fixing these problems. When she talked to Josh about how this stresses her out, he just commiserated and said, “Yeah, hopefully getting this project out before the end of the quarter will give us some breathing room.”

She really enjoyed the content of the work she was doing, but in the end, she asked to be transferred to a different team to have a more sane day-to-day.
The Traits of Good Managers
Even though Josh is adding tons of value when he’s working with the team on a tough problem, the members of the team are stressed and want to leave. There’s more to management than technical excellence. The technical ability forms a foundation to build on top of, but it isn’t sufficient in and of itself. Good managers need capacity in three separate domains:
- Operational
- Organizational
- Cross-functional
Each of these capacities includes several managerial responsibilities that contribute to a well-operating team. Over-indexing on any one domain can leave your team feeling pain on other fronts.

Some responsibilities will come more naturally than others. At the very least, you need to know where your strengths and weaknesses are, or you’ll have people leaving your team. Let’s go over each of the capacities in more detail to better understand how they cover the distinct concerns of being a manager.
There’s More to Management Than Expertise
Operational work is a manager’s ability to weigh in on technical conversations, review code, or help ensure a rigorous technical process is being followed on a project. For non-technical work, it’s the subject matter of the individual contributors you need to be familiar with. This is an important basis for the manager to work from, but it shouldn’t be the primary way in which you’re helping the team succeed.

There are a few problems that come about when a manager regularly swoops in on their team to finish a project:
- Ownership is usurped from the ICs and slows their growth and learning.
- The manager’s time won’t scale with the team’s work.
- The manager’s other responsibilities are neglected (one on ones, quarterly planning, etc.).
- It overworks the manager, often blocking progress on the project.
It’s common for very talented contributors to move into a management role. When doing so, they often see their contributions decrease and their time in meetings increase. This can be extremely frustrating if you view your job as IC++; i.e. doing great work on the given subject matter and handling some one-on-ones sometimes.

Josh had this view of management. Before he was a manager, Josh’s performance was evaluated based on the quality and speed of his contributions. Josh is neglecting the majority of his responsibilities as a manager by continuing to prioritize the domain of operational work. This happens most often when a deadline is approaching and the stresses of making sure his team ships in time convinces him he needs to take over.
Support the project, don’t drive it
For a manager, operational work is really about facilitating the technical work on your team. Technical knowledge is required to be able to do this, but the focus should be on making the people on your team more capable. That way, you can focus your attention on other responsibilities.

Finding the balance can be challenging, especially when those driving the project are making decisions differently than you had expected. Some good examples of involvement include:
- Trust your team to make significant decisions. Instead of deciding for them, challenge them to defend their choices. When they can do so, support their direction.
- Identify edge cases during whiteboarding sessions. As soon as everyone feels good on the direction of the discussion, challenge them to consider a different possibility. This will help them solidify their current view of the problem.
- Don’t insert yourself to the critical path. If you are required to commit some code or sign off on something, you become a single point of failure. Instead, work with your team earlier in the process to be sure you’re aligned.
- After a project is over, check in with the owners to discuss how things went. Go over what went well in just as much detail as what can be improved for next time. This isn’t to create accountability — it’s to foster individual growth.
Playing a supporting role in technical work has a compounding effect over time. Your team learns how to ship their work start-to-finish because they were the owners throughout. By fielding your questions, they start asking themselves the same questions on subsequent work. They’ll start critiquing their own work after a project without you needing to be there.

It’s a great feeling when you see one of your team members guiding another in the same way you had guided them on a previous project.
Crafting Your Organization
Organizational work is any work that crafts the culture of your team. It’s very easy to overlook this sort of work. Or, if you’re on the fence about management, you may roll your eyes when you hear things like “sprint process” or “performance review.”

First-time managers can find organizational work the most awkward or unpleasant in their transition. It’s easy to overlook or to put off. Organizational work is an investment in your team’s ability to function. Without it, you see a variety of symptoms:
- Inconsistent quality and shipment process when delivering a project.
- Unclear ownership or escalation process when dealing with bugs or incidents.
- Differing views within members of the team. Do we move fast and break things or move diligently and fix things?
- Fear of speaking up, whether it be in a meeting or to your manager.
When organizational work is done well, the members of the team don’t notice it. Everything works smoothly, everyone is engaged, and we can focus on the subject matter instead of organizational overhead. It’s a fine balance that changes as your team grows, and it requires continued attention in tune with what your team needs at the time.

Photo by Binyamin Mellish on Pexels

Organizational work can also be some of the most fun a new manager can have. It’s the first opportunity to make decisions that have a bearing on the way your team works. Planting these seeds on your team is some of the highest leverage work you can pursue. It also produces a much more resilient and exciting environment for people to work in. Some of the work includes:
- Setting up a pragmatic and effective sprint process.
- Establishing an incident process, including retrospectives.
- Working with individuals on your team to help them grow in their career.
- Running performance reviews that help you candidly check in with people on your team.
An example of organizational work: sprint reviews
If your team isn’t currently holding sprint reviews, your first work is to set those meetings up. Changing process on a team can be tricky, so you’ll need to clearly communicate what the change is and why you’re doing it. Also, make sure everyone is on board with the change. I call this winning the hearts and minds of your reports. The last thing you want is a meeting no one really cares about and doesn’t participate in. Then, you’re just wasting everyone’s time.

In the sprint review, you want an environment where people can speak freely and openly about the things that went well or could have gone better. It needs to be a safe space that is free from any kind of judgment or retribution. This means, especially the first few times you hold the meeting, you need to foster that environment and keep things relaxed. It’s also a good idea to take notes as a group of what everyone is saying. This will allow folks on the team to share what’s really going on and feel heard by their coworkers.

After the sprint retrospective, you now have a list of all the things that are important to your team. Congratulate and recognize any accomplishments and address any problems or concerns. The organizational work of addressing problems raised in sprint review is one of the highest leverage ways to directly make your reports’ lives better.

This is a significant amount of work, over several weeks, to get to a place where you can solicit feedback from your team and act on it to improve their experience and make them more productive. This work isn’t technical, but it’s entirely possible you’re adding more value here than if you prioritized technical involvement over setting this up.

The most compelling part of organizational work is if you think this approach to sprint reviews is dumb, you can run yours in a totally different way, or not at all. The organizational work you do crafts the culture of your team. It’s important to respect organizational work; if you don’t put much thought into it, you may not know what your team’s culture will turn out to be.
Succeeding With Others
Cross-functional work is any work that requires the manager to be a liaison to stakeholders outside the team. This domain is often the most challenging because it involves stakeholders that aren’t within the reporting structure of the team. This means they have their own agendas, constraints, and goals. As the team’s manager, you need to make sure your team is on the same page with what other teams are doing. You also have to make sure your team is meeting expectations.

Photo by Pixabay on Pexels

Identifying cross-functional work is challenging and often only apparent when you feel symptoms of a problem. Knowing your customers and where friction is being felt is the best starting point for understanding what cross-functional work is required for your role.

You’ll notice symptoms like:
- Last second details of a project prevent it from shipping on time because it won’t line up with another team’s work.
- Your engineers are spending a lot of time nailing down the scope or requirements of a project.
- The various projects your team is working on seem unrelated to a shared direction or company strategy.
- Other teams aren’t aware of what your team works on or why it’s important.
- You have a hard time convincing people to join your team or understand how your team fits in with the company.
When you are working cross-functionally, there are many more variables, and it’s much easier for things to go astray. A common issue is when one team’s vision or roadmap conflicts with another team’s. The manager’s job is to talk with the other teams that they interact with, find the best path forward for everyone, and very clearly communicate it both to the external teams as well as everyone within their team.

The way you handle such a complex domain is through diligent and consistent effort toward a common goal. I had a product manager that did this best. He scheduled sitdown conversations with every team we interacted with, asked them what else they were looking for, and read them back everything they said at the end. We stated clearly what we could or couldn’t do and we were able to move forward cross-functionally.

It’s difficult to know if you’re working well cross-functionally — you can only tell if you’re doing poorly. It’s the kind of thing that isn’t a problem at all until it’s a big one. However, there are some habits that can help you get going in the right direction:
- Routinely check in and talk with external stakeholders. You should have a good enough relationship with them that when a random consideration comes up that might impact you, they think of letting you know.
- Communicate new information multiple times over multiple channels (Slack, in person, email, etc.). It feels strange repeating yourself, but it needs to happen if you really want to get everyone on the same page.
- Have a good understanding of what you expect your team will be working on in a year’s time. Be completely comfortable with that changing along the way.
- Get into the habit of communicating concerns to select external stakeholders well ahead of time. This helps align their groups and mitigate last-second urgency. Think of it as a “Road Work Ahead” sign that helps cars on the highway slow down, rather than suddenly slamming on the brakes.
A strong capacity for cross-functional work is always a work in progress. There’s a reason why a new startup shows up every few months, trying to solve how teams work together. Clearly identifying the work that needs to be done and what you’ve found to be effective is a great place to start.
Knowing Your Strengths, Expanding Your Capacity
No manager is perfect in every capacity. Some leaders are compelling visionaries, but can’t speak to the “how” that well. Others are heads-down “do-ers” that don’t have much stomach for fine-tuning their team’s process.

Some examples of the three capacities

Understanding what you do well and where your gaps are can go a long ways toward building a resilient team. You can take measures to cover the things you know you aren’t as good at and double down on where you excel as a manager.

The important thing is that you understand the needs of your team, and how your participation as a manger improves or hinders their ability to do great work.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/