Three months to successfully "turn over" the software project!

author | James Simone

translator | Meniscus

Produce | CSDN（ID：CSDNnews）

In the past three months , The efficiency of our team has reached an amazing level . We have achieved many of our past goals , And more than expected , Many new features have been submitted , And each of us is immersed in the fun of work . How do we do it ？ How do we maintain this state ？ In the past few months , I've been thinking about these questions , I also discussed some of these issues with my teammates .

In short , Just actively share success , And take responsibility for failure , The whole team can perform well . In the past few months , Our team has achieved a series of successes ：

• Our product owner has got the opportunity to be promoted . Of course, they also made great efforts , The promotion was well deserved .

• The project of one of our team members （Nebula Logger） stay GitHub On the road 200 star . This time last year , He has worked hard for this project for many years , But to the star has been 50 Wandering around . lately , The whole community suddenly realized the great value that this tool brings to administrators and developers , It's unbelievable ！

• Our new teammates have grown into real engineers . Our team is responsible for 10 Multiple applications , The pressure is very high , But our new teammates are growing rapidly , Familiar with complex logic , More and more contributions to the team .

• Last , I also got a promotion , Thank you very much for the support of my team ！

In addition to the celebration , I also understand that our project is under great pressure , If we weren't meticulous 、 Work hard and conscientiously , Maybe this project is going to fail .

Deep analysis of engineering problems

In the eight years of software development , I see a lot of failed projects , Even more than successful projects . For a long time, I have been involved in this industry , You will feel that your life is also a part of failure , Sometimes the failure of a project is beyond our control , Just like it is inevitable for startups to burn money . However , In general , The project will slowly embark on the path of failure . below , Let's review the reasons .

The danger of laying off the best employees

The long-term health of the project will be affected by some factors , One of them is to lay off the best employees . In English , There is a special word to describe this situation ：brightsizing, The definition of a dictionary is ：

Giving redundancy to the hardest-working / most talented employees of a company.

Lay off the most hardworking employees in the company / The most talented employees .

Many definitions give examples of employees being fired , But before the epidemic , I thought there was brightsizing The reason is not that the company is in a recession , Instead, they refuse to acknowledge and share the performance of individuals or groups . Many companies have few incentives to retain employees , Or the reward and punishment regulations are not clear enough . In many traditional views , Labor is just an input , Under the same conditions , If a person leaves , Then it's easy to find another person to replace .

During the outbreak , People began to realize that people cannot be compared with each other , Want to really “ replace ” Talented and knowledgeable professionals often take years . these years ,brightsizing It has always been a hot topic in company staffing , And now because of “ The tide of resignation ” This dilemma is more frequent than before , Especially in the field of science and technology . let me put it another way , Losing the most talented people is one of the reasons why software projects fail . In the last eight years , I see many projects fail for this reason .

It's easy to think that , Poor architecture and poor quality code are the causes of project failure , But I think actually these are just brightsizing Symptoms . let me put it another way , If you can keep and reward talented people , You won't face problems such as bad architecture and poor quality code . Our company once had a “ Technical director ” The following code is submitted ：

const removeLastNCharacters = (string: string, number: number) => {
var stringToRemove = new RegExp(".{" + number + "}$", "i");
return string.replace(stringToRemove, "");
};

I had to refactor ：

const removeLastNCharacters = (string: string, number: number) =>
string.slice(0, string.length - number);

I want to make one point , The first version of this function was copied directly from an online post . It's easy to search for answers from the Internet , But the “ Technical director ” Not familiar with basic library functions .

There are many problems caused by brightsizing As a result of , Here I would like to emphasize two ：

• If your attitude is “ This is the code I wrote , What can I do for you ？”（ Like the example above ）, Then your men will not be successful .

• If the key personnel of the project leave , Then the rest of us are unlikely to succeed , They may not be able to advance the project at all , Or ignore the problem , It usually has disastrous consequences .

Let me give another example to illustrate the difference between these two points . Five years ago , It took me several months to get through a series of administrative red tape , Got access to the code base of another department . At that time, I naively thought it was just a “ Simple changes ”, However, after several months, the problem has not been solved , Because only one person on that team knows their application , And he's very “ busy ”. Actually , I just want to add a property to an object ……

/ this should have been a type, not an interface
// but hey, let's pick on one thing at at time, right?
interface ImageProps = {
path: string;
title: string;
// my new awesome property!!
label?: string;
// etc ...
}
// the question mark indicates a property is nullable,
// which would later on allow us to write something like ...
const createProps = (path: string, title: string, label?: string) : ImageProps => {
const imageProps = {
path,
title,
label: label ?? title // fallback to title when label not provided
// etc ... other assignments
};
return imageProps;
}

however , When I visit this new label Attribute ,TypeScript Tell me this property is not available . I'm a little confused , I just added this attribute ？ Then I saw the following code , Each use ImageProps Are repeatedly defined in ImageProps：

interface ImageProps = {
path: string;
title: string;
}

For those who refuse to acknowledge talent 、 Hard working people bring value to the organization ,brightsizing It's a very real problem . Code bloated 、Copypasta（ It means that people often cut on forums or social networks 、 Copy 、 Paste text ）、 Bad architecture, etc , Problems began to surface , And then spread quickly . in my opinion , Just change two lines of code （ first line , Add attributes to the interface ; The second line , Will create a new label Attributes are correctly assigned to the created <img> Elements ）, As a result, I had to modify the... In dozens of files 100 Many lines of code . No standardization , No inspection . I made a suggestion during the code review , Focus on problematic interfaces , And create img label , But they laughed at my suggestion . It wasn't long before I left .

That company has been having problems with human resources , They don't know how to retain talents , Often force good employees to leave . The average duration of employment of employees is less than two years . Many people left their jobs in a hurry within two years . Although I mentioned above the general trend nowadays , But there are always companies that fall behind , That's why “ The tide of resignation ”.

I always compare my first company , Although that company is also a failure , At that time our CRM Existing system 20 many years , Face elimination （ The entire life cycle of the system costs tens of millions of dollars ）. Although the system has only been used for a few years , But they decided to regroup the team , Build custom CRM System , And they think it's more cost-effective than improving the existing system . However , The products they are trying to increase staff and maintain have nothing to do with their core business , I really can't find the right words to describe this behavior . Of course , It does Hubspot Such companies really do this , But the key difference is Hubspot Looking for opportunities to enter a new market , To sell the fruits of their labor .HubSpot The salary offered is very attractive , And partly because of the revival of entrepreneurial culture in the greater Boston area . I'm sure they created CRM The system is not just to support internal business , Otherwise, the real senior management or shareholders will certainly not be able to afford this long-term cost .

Sometimes , The consequences of laying off good employees do not immediately manifest , Especially when you just joined a new organization . But gradually , You will notice that there is strange code 、 Tightly coupled architecture 、 Lack of rigorous testing and organizational knowledge accumulation . These are the sequelae of laying off excellent employees . That's why interviews are so important , Because you can take the opportunity to know whether the person interviewing you likes your company . let me put it another way , If team members hate their jobs , They hired you to fill the vacancy left by other people leaving , Then you certainly don't want to join them .

Code review considerations

lately , I'm reading a Book 《Accelerate》, The book mentions that one of the biggest problems faced by unhealthy and inefficient teams is the unnecessary review process . I reflected on the reviews we are doing now and some of the review processes I have seen , Obviously, the way and content of the review are equally important . We should introduce the principle of Nonviolent Communication . These are prerequisites for code review , Any spirit in the review process / Language hostility can lead to a complete collapse of censorship .

Some bad habits can easily destroy the review process ,《Accelerate》 Demonstrates the change review process rather than putting up with it , It would be better not to have any review process , But I prefer to say , Compromise is the ideal .

Code reviews can provide opportunities for teams , Get everyone to agree . Sometimes , You need to review your past views , I often do code reviews of my open source work , Even some functions can be changed in one day , It will also be revised frequently during the review . Review the code later , More likely to find problems . about Mob Programming , What I like most is that it attaches great importance to receiving feedback . lately , We are developing a feature with a decoupled architecture , But eventually some of the tests went wrong , Let's start refactoring . It is suggested that we should investigate deeply Jest API, If we can't pass the existing tests , Then decoupling makes no sense . Speeding up the feedback loop saves us hours of time , And let's quickly roll back to the previously working code , Then test .

About code review , There are several key issues that need attention ：

• Is there a problem if you deploy this code as is ？

• Is this code consistent with the patterns used elsewhere , Or is this code a unique existence , There is no precedent ？

• Will constructive feedback from code reviews be a learning opportunity for submitters ？

If your proposal does not fall into any of the above , There is no need to mention , Nitpicking only makes people hate code reviews , A waste of time , It will also make people lose confidence in code review . Code review should be the part that everyone expects , Don't be too critical ！

Imagine that , After I left my second company , A friend revealed to me , Our code base is the cleanest he has ever seen . Over the years , His praise has been bothering me , In particular, I thought of some of our shortcomings , And some areas that can still be improved . One of them is our style guide . I spent a lot of time formatting the code , Just to make my code more close to the style guide , Every time I think of these , I feel very painful . Each of us has our own little quirks , Even if you completely follow pair programming , We also have to check our own subconscious writing style before submitting the code . If you are reviewing the code , And there are questions about the format of the code , Then you should find a tool that can automatically adjust the code format .

friction -> Weariness -> disaster

In case of friction , First time solution is the most effective way . otherwise , Friction can lead to burnout , And burnout can lead to disaster . What I'm talking about here “ friction ” refer to ：

• Heavy code reviews ;

• Difficult deployment ;

• All deployments can only be done by one person ;

• After deployment, regression testing is required , Some people are afraid of being blamed for this .

• Corporate values that discourage vacations ;

• The values of the enterprise are very different from your own values ;

• The management of the company is terrible , So that values have no effect at all .

• Unable to balance work and life ;

• Isolated working environment ;

• Don't know what's next in your career .

• Unrealistic estimates and schedules .

Here are some examples of eliminating friction ：

• Code reviews are concerned only with the necessary cleanup and architectural issues ;

• CI/CD;

• Project summaries do not blame each other ;

• Unlimited paid leave , And encourage vacations （ Every year, 5～6 Zhou ）;

• Good scheduling , The time of beginning and ending is the same ;

• Highly visible 、 Easy to understand promotion channels and promotion objectives ;

• A helpful team ;

• Modify the schedule according to the new information ;

• focus “ improve ”, Reduce the difficulty of maintenance .

What kind of friction do I often encounter ？ People think that engineers always want to accept tough challenges , Use cutting-edge technology . In my submission , If you ask engineers what is most important to them in their work , Most engineers start with the second most important thing , Because in their mind, the first one is people . If every task at work is difficult , Then burnout will be inevitable . If everything requires cutting-edge technology , That means you need to spend a lot of time to solve the undocumented errors 、 Handle functional differences between tools , It also takes a lot of effort to isolate the new infrastructure 、 Platform and code , Until the system stabilizes .

I've seen a lot of teams and people iterate quickly , Adopt cutting-edge technology to solve today's problems , And solved many thorny problems , But I believe they are able to do these things because they work in a low friction environment . If you feel that the culture of the company or team is out of tune with yourself 、 Out of line with your work goals 、 There is no opportunity for career development , Then you are unlikely to endure the ordeal of every day , Not to mention long-term persistence until the project is successful .

Let's think about it again “ Failure ” Project .

Working in a harsh environment , It is not uncommon for team members to unite , They support each other , Share the difficulties . This structure , Like a lattice of snowflakes , Not sustainable for a long time , If one day it breaks , that HR Will face a big breach of the levee . The failed company I mentioned earlier had such an experience , Two of our most talented engineers have left , Later, within half a year , Other members of the team （ Including myself ） They all left one after another .

Known factors for project success

that , What makes the engineering team strong , What makes high-performance teams stay healthy and fast ？

High performing teams can enjoy working

During the outbreak , I once participated in a project , Everyone works remotely , But we are very happy together . When I first joined the team , The project manager called me , Warmly welcome me to join .

Although later I left , But I miss that happy time very much , I still keep in touch with them . I feel very lucky to have the opportunity to cooperate with them , Not every team can trust each other , Take the initiative to take responsibility . therefore , In my submission , Work together happily , Welcome new people to join us gracefully , Such a team is more flexible , More efficient .

The importance of trust

For a long time , I've been thinking “ trust ” The word （ This is the first core value of our company ）. Although this is a simple word , It has different meanings for different people , But I find that teams that trust each other are more united , Get along well , Active communication , And surpass other teams . Trust takes many different forms ：

• Willing to show vulnerability , Admit that you don't know ;

• Be able to listen to someone's heart , Will not be interrupted ;

• Be able to learn new technologies , I believe that the time invested will not be wasted ;

• There is not much micro management .

• In a collaborative work environment , Trust and lack of micro management have a great positive impact on the team's workflow .

Trust and friction are opposites . Teams that trust each other can minimize the complexity of social interactions , The whole team is like a machine that works well . Team members will be happy with each other's achievements , Instead of mutual jealousy .

Only have enough trust in the team or individual , Power can be delegated . A successful team can be made up of people with many differences , As long as they trust each other , And be able to keep similarities and differences in work . This reminds me of an old colleague , Although his personality and interests outside of work are very different from mine , But we can still work together happily . It is good for a group of like-minded people to work together , But people from all over the world get together , It is also a good story to unite and work for a common goal . We have a common goal , And it is consistent with the values of the enterprise , This is one of the factors that make an effective team full of vitality , Even if ：

• Demand is constantly changing ;

• The work to be done is accumulating ;

• There are many errors that need to be fixed ;

• Everyone is facing great changes in work and life .

But we will still strive for lofty goals , It is trust that can help us reach the other side .

The importance of coaching

Appropriate guidance can also help the success of the project . Experienced people can pass on knowledge to new people through guidance . In practice , Good coaching is two-way , Because both sides can grow . I was lucky , The first teacher I met at work was amazing . in my opinion , Organizations that provide technical guidance are more flexible , Because their team has a greater ability to share institutional knowledge .

The key is , Mentoring is very different from management , Having a manager as a mentor is not a wise choice , Because the role of a mentor is different from that of a manager . The instructor will introduce you to the concepts and cases in the browsing application , You can also look at the code that implements these concepts . If the manager has the time and energy to act as a mentor , And students are willing to , Then you can also let the same person play two roles . But the nature of guidance and management is completely different , Not every manager is fit to coach others . Again , Not every rookie is suitable to be guided by a manager .

There are two kinds of learning process ： First of all , Grow by making mistakes （ Your code will produce bug, Or the code doesn't work as expected ）; second , Learn by observing others . Coaching allows me to understand the critical thinking behind decision making , So as to move forward more quickly .

At work , I also had the honor to guide several excellent junior engineers . I like pair programming very much , Because we can learn more knowledge through guidance in this process . As a team , The reason why we succeeded , Because we can explore interesting patterns or software architectures , The process of sharing learning results can make us change . below , Let me tell you an example of pair programming ：

type Data = {
fieldOne: string;
fieldTwo: string;
// etc, other properties
};
type DataOverrideConfig = {
fieldOne?: string;
fieldTwo?: string;
// etc, other properties
};
const updateBasedOnConfig = (data: Data, config: DataOverrideConfig) => {
data.fieldOne = config.fieldOne ? config.fieldOne : data.fieldOne;
data.fieldTwo = config.fieldTwo ? config.fieldTwo : data.fieldTwo;
// etc ...
};

My colleagues and I found this code by chance , We were going to merge several different code paths into one class , This class is responsible for handling configuration changes of data . We're just going to move the function into the same class , There is no intention of fundamentally changing the code . However , When you see the two triples above , I can't help laughing , I would like to take this opportunity to show how to modify this code ：

const updateBasedOnConfig = (data: Data, config: DataOverrideConfig) => {
if (config.fieldOne) {
data.fieldOne = config.fieldOne;
}
if (config.fieldTwo) {
data.fieldTwo = config.fieldTwo;
}
// etc ...
};

Note that this code is not meant to use JavaScript Compiling （ Otherwise, you can implement this function in a more idempotent way ）. I modified the variable reading , When a field in the configuration override does not exist , Avoid unnecessary write operations ：

• The triples defined in the first code section mean ：“ This property must be set at all times , Even if no configuration overrides , Also write... With the original value of this attribute ”.

• add if After the statement , This code means ：“ If the configuration overrides contain matching properties , Then use it to overwrite the existing values of the data ”.

The latter is more consistent with the description of business rules , We can review why improving the readability of the code is good for everyone .

Correct guidance can help new people grow quickly , And improve their self-study ability . I have the honor to meet many excellent tutors in my career , Here I would like to thank them .

Collaboration during the outbreak

During the epidemic , Great changes have taken place in everyone's work and life , Teamwork is especially important in this period . The demand of various companies for scientific and technological talents has reached an unprecedented level , In addition, they also realized that telecommuting can not only let developers work anytime and anywhere , And the talent pool will not be restricted by region , Expanded several times . Of course , The city is no longer an important factor affecting salary , Because developers may live outside the city , Or live in a small city with a lower cost of living . People's thoughts also changed during the epidemic , We all hope that companies can attach importance to talents , Not where they are , Everyone wants to return to their hometown or live in other cities , And then through telecommuting .

Can be free from geographical restrictions , Freely choose the city where you work and live , Employees will be more motivated , More desire to pursue success .《Accelerate》 It is also mentioned in the book ：

…… Stocks of companies with a highly trusted work environment outperform the market index by three times ……

If employees can devote themselves to their work , Keep in a good mood , And the ability to do the best , Then everyone will benefit . Besides , Mental health professionals also point out that , During the outbreak , Due to the friction in work and the comprehensive influence of Family Psychology , The demand for mental health services has also reached an unprecedented level . This is a constant change , Is constantly infiltrating our culture and values . Although I don't know how the epidemic has affected our office culture and personal lifestyle , But we know that ：

• People are talking about “ Video conferencing fatigue ”.

• Although many software developers like to work alone , But they are also an important part of the wave of resignations .

Compared with the past , It seems that we are even more unable to “ Endure ” The difference between enterprise values and their own values . We are becoming impatient with our work , More and more critical . Coupled with a strong sense of isolation , It is easy to understand why the number of resignations during this period reached a record .

We need to keep a positive attitude . Although I have never met with some team members , But we talk on video every day , I don't feel strange to them at all , Work is always full of laughter .

This feeling is very important , All this is based on trust . We have successfully released many features , He also launched two projects in two sprints . Sometimes , We are under a lot of pressure , Sometimes you have to patch the program overnight . Although it's hard , But I am very happy to join this team ,

Attaches great importance to “ improve ”

“Kaizen Focus” Medium Kaizen From Japanese , Writing Chinese characters is to improve , It means the process of continuous improvement . This is an idea that the agile framework draws from Japanese manufacturing . When implementing agile methods , This is a common practice , That is, let the team identify an improvement item in each sprint that can help them speed up their action . A friend and I once sighed , We spend even more time maintaining code than writing it , So through “ improve ” It is so important to reduce the difficulty of maintenance . Speaking of this , I thought of the following two questions ：

• After the code is written , Will immediately enter maintenance mode （ There is another way of saying “ Technical debt comes not just from inherited code , Even the code you just wrote is technical debt ”）.

• It's harder to read than to write .

Let's think about the difference between successful projects and failed projects . Some projects are successful , It's not that the code you write at the beginning is excellent , I haven't moved since . contrary , The code went through many iterations . let me put it another way , Successful projects are well maintained .

Conclusion

I spent a month writing this article , During this process, I reflected on the positive and negative experiences in my personal career . In my submission , In a way , All of us are looking for “ The change you want to see ”, But in the wrong company 、 The project and / Or team work can make people feel trapped , Overwhelmed .

As for how to improve the quality of code written by individuals or teams , I think we should keep a positive attitude , Make meaningful contributions to the team . Reflect on what we did right and wrong in software engineering , Maybe it is a good starting point .

Original address ：https://www.jamessimone.net/blog/joys-of-apex/the-life-and-death-of-software/

— Recommended reading —

*“ I am an idiot , If you get a bunch of them, you will only ‘ Google ’ The programmer ！”
* Microsoft banned Russian downloads  Windows  The Book of Revelation 
* A hundred years later , What language do people use to develop software ？（ Book presented at the end of the article ）

— Click here ↓↓↓ Remember to pay attention to the target star ~—