Please don't let the programmer grope in the dark

I do not know if you have played Warcraft, x-com, civilized Empire, red alert and other strategy games.

These games use the so-called "fog of War." Just enter the game, each player's map is shrouded in darkness, want to move the only way is to constantly groping. As we continue to move, the map becomes more and more visible.

The disadvantage of this strategy is that players cannot see the dangers, obstacles and opportunities around them. Every success requires a little bit of luck.

A little familiar with the feeling of wood?

The "fog of war" perfectly describes the working situation of developers . They are always asked to fix a particular piece of code, but do not tell the task about the situation, it is to let themselves in the dark to grope.

For developers, it is necessary to see "The entire game map". Having a clear grasp of the overall situation helps them make the right decisions. Here are some of the things they need to know:

• Why do you want to create this feature? What convenience does it provide to the customer?
• How does the code around this function go through a process of development?
• What other parts of the application do this feature affect?
• Does this affect other parts of the business?
• How do we measure the success (or failure) of this project?

Once the developer has mastered the entire framework, it is possible to start working in a targeted manner. The success of the project is greatly facilitated by their deliberate and subsequent action.

There is also a huge incentive effect. Joe Stump concludes:

Developers often have to grope for the problem behind the task, which means that developers may not really think about the idea for a given object.

But if it is responsible, the developer will be immersed in the problem of thinking, because its work is more specific, more dependent on business success.

For example, if I am a backend developer and you tell me to implement some API endpoints, I need to consider why you need these endpoints.

This underscores the importance of understanding the goals and tasks behind each project:

• Purpose: Why are we doing this?
• Task: What is the goal? How to achieve the degree of completion?

After understanding the goals and tasks, developers become valuable partners in the planning process. They can foresee some potential "mines", lest you step on them and pay a high price. In a magazine article , Paul Boag describes the dangers of abandoning developers to a number of related meetings:

At the height of Digg, Daniel Burka (Digg's chief designer) and Joe Stump (its main developer) held a meeting to discuss a Digg button. Daniel wants to change his design because, from his point of view, it doesn't change much. But for Joe, he found that the small design would have a big impact on the performance of the site, forcing Digg to upgrade its processing power and server architecture because of such a button.

What can you do?

First of all, we should participate responsibly in the discussion of product, support and engineering planning meetings.

And can put forward their own constructive suggestions, in addition to application developers, few people will notice the security issues of application development, it will require the programmer according to their own experience, experience, and related research conclusions: with professional third-party security platform- mobile application Security Intelligence service Provider , to achieve the purpose of protection!

After the meeting, we can create the relevant specification file that we need next.

managers are not generals, and developers are not fighters.

Sometimes, managers do as if the project is a critical secret, just give some "basic knowledge to know".

But this protection does not lead to better code, more popular projects, and no increase in sales. Do not let developers grope in the dark, and they should be invited to participate in the overall strategic discussion.

Please do not let the programmer grope in the dark