The confusion of a 39-year-old programmer: The more you know, the slower the program will be.

ZILK1988 began programming at the age of 14, after several careers, and finally decided to become a professional programmer in 1997 (also known as Code Agriculture), now 39 years old, the choice is still no regrets.

But then he found a problem, the richer his experience, the longer it would be to complete a project or task. Because he had seen too many situations that might have gone wrong and hesitated to choose. Suppose, for example, that he had just thought about writing a piece of code to write to a file, and he was beginning to worry about the following series of questions: Permissions, locks, concurrency, atomic manipulation, circuitous/framework, different file systems, number of files in the directory, predictable temporary file names, PRNG (pseudo-random number generator) Randomness quality enough, how to do during the operation, how to write the API to understand, how the document should be written and so on.

In short, his question has changed from "How To Do" to "how best/safest".

The result is that he made the version rock solid, but also caused him to complete the project longer than the rookie.

Zilk says he is proficient in algorithms, loves mathematics, enjoys complex projects, and has no problem with concentration. Perhaps experience is problematic (though already 39 years old), causing fear of making mistakes and making projects time-consuming. So he invited his peers to help him solve the problem on the Stackexchange.

Here's a selection of solutions:

Telastyn:

You are not slow to finish the project. You used to think your rookie project was done, but it wasn't really over. You should sell the quality to the customer. "The company can do it faster and cheaper, but is the project really done?" Or are you willing to spend years looking for bugs? In addition, you should know and accept the old saying: "Perfection is a good enemy." ”

Sevenseacat:

"Good, fast, save only 3 election 2". Before you know how little so sacrifice "good", now you know more and sacrificed "fast."

Mouviciel:

It seems that your experience is indeed insufficient. Lesson: Comply with demand, do not think of other. This will not implement unwanted functionality.

Satish:

Agile methodologies should be considered rather than waterfall streams. Deliver first and then iterate. This helps reduce risk and cost.

DXM:

It seems that you are joining the dark side: It's time to manage.

I'm not suggesting that you give up programming to become a manager. But from your point of view your experience is limited to the technical level. Write a file So simple things you can think of 10 aspects of the problem, a little bit of the developer is absolutely not to come out. It's not a bad thing, but ...

Everything on the dark side is related to the present value. It is about how to achieve maximum output (cost-benefit analysis) with minimal input. Everything in business comes down to costs, odds of success, failure probabilities, potential rewards, and so on. Do the math and take action.

Even if you're a developer, it's OK to build a temporary file for 5 minutes without ignoring permissions and naming conflicts. Net income: Other team members can begin to rely on code writing for this file. Is this a perfect solution? Of course not. What about 99%? Ci？ 90%? These possibilities exist.

And ask you a question: How do you feel about technical debt (note: A quick fix but a way to increase the cost of subsequent maintenance)? Some people think that there should be no technical debt. I don't agree. Like business, technical debt allows you to borrow "money" and "time" to deliver something later. 2 years to make a perfect solution, or 4 months to solve the Gordian knot to make the customer can use and buy something, which is better? The judgment certainly depends on the situation, but most of the time if you have to keep the customer waiting for two years, the customer may have already signed up with the competitor.

The key is to manage your technical debt as well as manage business debt. If you don't borrow enough money, you won't get the best return on your investment. But when the debt is too high, the interest will crush you.

My advice is to use the tomato working method. Focus on small time intervals (tomatoes), then allocate these time periods for future work/research, and constantly adjust to the priorities of the events in the process of execution.

Saul:

One of the keys to programming is managing and controlling complexity, which is one of my top priorities. The complexity management is ignored, either the defect is frequent, or the ETA (estimated time of arrival) of the software increases dramatically.

There are many different management levels and approaches to software complexity: "The highest priority for any software project is customer satisfaction, which is the function the customer expects." ”

In other words, software complexity depends on how you control the level of customer expectations.

If you accept this view, then the following two points are also obvious:

You cite a good example of "writing directly" or "countless other considerations". Consider, if someone has written down the requirements of both, is the functional description of the two sides the same?

The same is to build airplanes, F16 can fly, model aircraft can fly, but that can be the same?

Originally I intended to extract all the suggestions, but given the above insights to solve the zilk puzzle, and in order to practice these suggestions, this article stops, interested parties can see the full discussion.

Finally, I only add one sentence:

You can also look at McDonald's theory.