[no.000008] pay is not just for you to write code

This is the first thing I say to every new employee in the team. This means that I don't care how quickly you get the job done, even if the code is bad, as long as it works like a lifeboat vent door. This is one of my favorite motto.
This is a very reasonable statement: Our job is to think about the questions the customer has asked and then develop a solution. Think first, code second, the company asked us not to write code, but to come up with a solution.
The words are not coarse.
Paying your salary is not for you to think about, nor does it allow you to write code, your purpose is to deliver the product. What is the point of your knowledge, your skills, your attitude, and all the features that make you an efficient programmer if you can't deliver an effective product to your customers?
No customer would say: "Well, if you can use a space instead of the TAB key to indicate indentation, the code will be more readable." And no customer would ask us to use a one-way hash store password, in fact they may not have heard of it. No customer will force us to come up with all the possible architectures and platforms, and then select them. More customers will be asked what code standards their projects use.
Customers don't care about the code, they don't care about the architecture, they don't care whether the whole system is bloated or not. What they want is to solve their problems.
The real challenge is to weigh the two extremes: our job is to write code, or to think that the two conditions of code and product can never be met at the same time.
Let's meet two novice programmers--sam and ted.ps: If there is a similarity, it is purely coincidental.

Sam is a new employee who has just graduated from a local university and is a standard genius. Her interview and Fizzbuzz Test performance was excellent, and now she officially started her first day of work as a programmer (hired!). You, as the head of the project, assigned her the first task. Because she's just getting started, so the task is not difficult, and you (as an experienced developer) think it will take about an hour to get it done, but based on conservative estimates, you think she might need a day.
She finally spent one weeks! From the next day, every time she checked, she swore that everything was going well and the code would be perfect. Finally finished, as she said: The code is perfect like a work of art. however, please note that It took her one weeks to finish the task, which should not have been more than a day.
Now, let's talk about Ted.

Ted and Sam were hired on the same day. His interview went well, though he did it very quickly. You also gave Ted a relatively simple task: it takes about a day.
But it only took him an hour! At your noon break, Ted had to come over and pay for the job--look at the pride and complacency, as if in kept said, "Praise, please!" But a look at his code, can only hehe: a lot of copy and paste to the code snippet, messy function naming, organization confusion, mirrors explanation, and so on, and so on, like a pot of mixed, you do not know me I do not know you.
Who does your team care about, Sam or Ted? Neither of these two actually offer real products? They are just as bad: one thinks too much and the other thinks too little.
So, keep in mind that paying your salary is not just about getting you to write code, it's not just about thinking, you need to develop a product that solves the problem.

[no.000008] pay is not just for you to write code