Been in development for so many years and recently worked with some new colleagues (a few years younger than me). Found a big difference in communication and thinking.
There are two main points:
1: Who will do the demand analysis;
2: To realize the function, or to solve the problem;
for example:
1: Who will do the demand analysis;
Requirements are always unclear, especially in web page UI and interaction. Frequently looking for PM ( there are few people, and the project manager does pre-sales + demand analysis at the same time ) to ask: How to do a certain function, and what does it look like? But once the mail reaches the manager, it's like a mud ox into the sea. Often a page is done for 4 or 5 days, and most of the time is waiting for demand (waiting for phone calls, waiting for emails).
This approach is understandable: after all, programmers have no decision-making power, and if they make their own decisions, they will rework themselves. But I don't advocate this way of doing things. Small companies do more with less people, and everyone can do more, and the company will get better and better.
When encountering functions with unclear requirements, programmers should take the initiative to assume the role of requirements analysis, rather than simply throwing the problem to the requirements personnel. Demand people are busy, especially PMs with multiple roles. The programmer throws the problem at him, and he usually doesn't have time to think about it, or doesn't think about it in depth.
The way I received a similar email was: " This function is to solve the problem of XXXXX, how to solve it, how to do it, and what is the best way to make it, it is up to you to think about it, and I will confirm it ." When discussing issues, some students will think that this is a matter of the demand personnel (or PM), and it should not be my responsibility.
If programmers don't think actively, they can only be code farmers all the time.
2: Implement the function, or solve the problem
Implementing the functionality is relatively easy. The problem is analyzed clearly, the solution is also out, and only the code is left. Anyone with a little programming experience can do it. I often ask the development classmates for the needs: what is this function for? The answer that gets the most is: I don't know, the (manager) client asks to do it. Look, it's "not thinking" again.
I have seen a lot of engineers who can think actively. When the work is handed over to him, he will consider it comprehensively and don’t have to worry about it at all. If there is a problem, he will take the initiative to ask me to confirm. On the contrary, the work is often handed over to the "non-thinking code farmer".
Doing everything requires thinking, especially in the IT development industry.
Don't be a "code farmer who can't think"