Getting paid isn’t just for writing code

This is the first thing I say to every new employee on the team. What this means is, I don't care how fast you complete the task, even if the code is poor, as long as it works like a lifeboat vent. This quote is also one of my favorite mottos.

This statement is actually very reasonable: our job is to think about the problems raised by customers and then develop solutions. Thinking first, code second. The ultimate goal of the company asking us is not to write code, but to come up with solutions.

The words are crude but not rude.

We don’t pay you to think or write code. Your purpose is to deliver products. What's the point of having your knowledge, skills, attitude, and all the attributes that make you an effective programmer if you can't deliver an effective product to your customers? !

No customer is going to say, "Well, the code would be more readable if we could use spaces instead of tabs for indentation." And no customer is going to ask us to use one-way hashing of stored passwords, in fact they probably are. Never heard of it. No client will force us to come up with all possible architectures and platforms and then choose the best. Even more, no customers will ask what coding standards their projects use.

Customers don’t care about the code, nor the architecture, nor whether the entire system is bloated. All they want is a solution to their problems.

The real difficulty lies in weighing the two extremes: that our job is to write code, or that the two conditions of code and product can never be met at the same time.

Let’s get to know two novice programmers-Sam and Ted. ps: Any similarity is purely coincidental.

Sam is a new employee who has just graduated from a local university and is an excellent academic. She aced her interview and FizzBuzz test, and now she's officially on her first day at work as a programmer (and got hired!). You, as the project leader, assign her the first task. Since she is just getting started, the task is not difficult and you (as an experienced developer) think she can do it in about an hour. However, you are conservative and think it may take her a day.

It ended up taking her a week! From the next day, every time she checked, she vowed that everything was going smoothly and the code would be written perfectly. Finally it was completed, and it was just as she said: the code was as perfect as a work of art. Note, however, that it took her a week to complete a task that should have taken no more than a day.

Now, let’s talk about Ted.

Ted and Sam were hired on the same day. His interview also went well, although he completed the questions very quickly. You also give Ted a relatively simple task: it will take about a day.

But it only took him an hour! During your lunch break, Ted came over to hand in the task - look at that proud and smug look, as if he kept saying "please praise, please give me praise!" But when I looked at his code, I just It works: a lot of copied and pasted code snippets, messy function naming, confusing organization, vague explanations, etc., etc., it’s like a hodgepodge, you don’t know me and I don’t know you.

Who do you prefer in your team, Sam or Ted? neither. Neither of these actually offer a real product? They are equally bad: one thinks too much, the other too little.

So, keep this in mind, you’re being paid not just to write code, and not just to think, but to build products that solve problems.

What do you think about this? Everyone is welcome to express their opinions.

Receive LAMP Brothers original PHP tutorial CD/"Essential PHP in detail" for free. For details, please contact the official website customer service: http://www.lampbrother.net