It's not just for you to write code.

It's not just for you to write code.

This is the first thing I say to every new employee in the team. It means that I don't care how quickly you complete the task, even if the code is poor, as long as it works like a rescue vehicle ventilation door. This sentence is also one of my favorite motto. This statement is actually quite reasonable: Our job is to think about the customer's problems and then develop solutions. Thinking first, code second, the company asks us not to write code, but to come up with a solution. Not crude. Paying your salary is not something you think about, or writing code. your goal is to deliver products. If you cannot deliver valid products to customers, what is your knowledge, skills, attitude, and all the features that make people become efficient programmers ?! No customer would say, "Well, if the tab key can be replaced by spaces, the code will be more readable ." No customer will ask us to use a one-way hashed storage password. In fact, they may have never heard of it. No customer will force us to come up with all possible architectures and platforms, and then choose the best choice. Even less, customers will ask what code standards their projects use. Customers do not care about code, architecture, or whether the entire system is bloated. What they want is to solve their problems. The real difficulty is to weigh the following two extremes: Our job is to write code, or think that the two conditions of code and product can never be met at the same time. Let's get to know two new programmers-Sam and Ted. Ps: If there are similarities, it is a coincidence. Sam is a new employee who has just graduated from a local university and is a standard student. Her interview and FizzBuzz test are both outstanding. now she officially starts her first day of programmer career (HIRED !). You, as the project owner, assigned her the first task. Because she was just getting started, the task is not difficult. you (as an experienced developer) think it can be done in about an hour. However, based on your conservative estimation, it may take one day. It took her a week! Starting from the next day, every time she checked, she vowed that everything was going well and the code was very well written. Finally, it was done. as she said, the code is perfect like a work of art. However, please note that it took her a week to complete the task that should have been less than one day. Now, let's talk about Ted. Ted and Sam were hired on the same day. His interview was successful, even though he completed the problem very quickly. You also gave Ted a relatively simple task: it may take about one day. But it only took him an hour! During your noon break, Ted was so proud that he ran and handed in the task. he looked so proud and complacent as if he was saying, "praise, please give it a thumbs up !" But when I look at his code, I can only look at it: a lot of copy-and-paste code snippets, messy function names, messy organization, and confused explanations, etc, just like a pot of hodgedge, you don't know me or me. Who do your team prefer, Sam or Ted? None. Are these two actually unable to provide real products? They are equally bad: one thinks too much, and the other thinks too little. Therefore, keep this in mind. to pay your salary, you must not only write code, but also develop products that can solve the problem. What do you think about this? You are welcome to express your own opinions. Get free LAMP Brothers original php Tutorial CD/the elaborate PHP Essentials edition, details consulting official website Customer Service: http://www.lampbrother.net