(Star those things about programmers)
[Guide]: Yesterday, foreign programmers discussed an article on Hacker News, "You are not writing code, but solving problems".
The English author is Raul, let’s take a look at how he stated his views.
We are programmers, so writing code is our job, isn't it?
As the title suggests, our job is a little more complicated than typing on the keyboard all day long in front of the screen. If you go beyond programming languages, frameworks and processes, beyond test suites, Sprint, and Jira work orders, you will always find problems that need to be solved.
As programmers, we are the ones who solve the problems, get the problems encountered by others, and use all the available tools to find solutions.
Software is not the purpose
Software itself is not the purpose of our work. The written software must be connected with real-world problems/requirements, otherwise even if the code is beautifully written, it is still a useless embroidering pillow program.
More importantly, the software you write should be able to pass the assessment, whether it can well solve the problem/needs to be addressed. Software is a tool used to solve specific needs. Take the best software you can think of as an example: it's neat, easy to read, and the design patterns are all used correctly. But if it can't do what you need it to do, then it's useless.
Understand the problem/needs
The first step in software development should be to understand the problem/requirement. It cannot be overstated to spend more time doing this. This applies to both small tasks and entire projects. I think it is even more applicable to the entire project.
If you don't understand the requirements correctly, the problems caused by it are difficult to solve no matter how hard you work. Most of the time, they involve a lot of refactoring and a lot of work. You have to explain why the entire program is wrong, and forget about the embarrassment you are facing.
Perfection is your enemy
It has already been explained that we should focus on solving problems/requirements instead of writing code. I also want to mention the "rule of twenty-eight". As programmers, we are sometimes troubled by the problems we are solving, so that we forget to ask ourselves "Is my problem solving direction right?"
We need to take a break from time to time to see why we do it. When encountering problems, perhaps the following questions can help you:
How valuable is it to solve this problem?
Is there any other faster method?
Are there any compromises that are easier to implement?
These problems are not always something you can solve by yourself (unless you are working on a personal project). Talk to stakeholders and see what they really care about. If possible, collect user feedback.
Generally speaking, a quick A/B test is a great help for what you should do next. Experiment and iterate! Your project does not need to be perfect to succeed.
The best code you can write is no code at all/no code
Not every problem requires a technical solution. You don't need an app to handle all other things. Everything comes at a price. When you write code, it consumes your time and resources. In addition, the more code you have, the more code you need to maintain, and the greater the possibility of errors.
I believe you have already noticed that adding code is risky. Errors will appear sooner or later. There is a non-linear relationship between the number of lines of code you have and the work involved in maintaining it. In other words: more code means more problems.
Try to turn your code into the needs of others. I found that, usually, it takes time to find a ready-made solution. In software development, we have reached such a stage: Many things have a ready-made library or API. For common problems/needs, I suggest using ready-made solutions: such as identity verification, payment, etc.
In addition, it is worthwhile to find ready-made solutions for the entire project. Take WordPress as an example. My blog is based on WordPress and I did not write a line of code.
Reviews
Raul's article has aroused heated discussion in HN, let's extract a few:
Programmer muglug:
Raul's article throws a scarecrow argument-almost all programmers are solving some type of problem.
The biggest question is: who are you solving the problem for.
When I was a solo freelancer (as his article assumes), I was always solving problems for clients and their clients.
When I work with other programmers, I am also interested in solving their problems. Sometimes the code is improved in the form of large-scale refactoring, but some tools are also developed to improve the code base on a large scale.
Ozzie_osman：
I like this article, but it ignores one point, that is, a solution (which is more conducive to solving problems in the future) should be adopted. Many people make a mistake in this trade-off.
For example, it is important to write well-written and maintainable code. Because if you don’t, the problems that need to be solved in the future may change. These changes may reduce your ability to solve more problems. The code itself can be difficult to understand, reason, and modify, so it is difficult to make changes. The more time you spend on maintenance, the less time you have to progress forward accordingly.
liquidify：
I think it depends on the language. I found that with C++, I spent a lot of time studying the language, and with Python, I spent more time solving practical problems.
carlsborg：
Good software is made up of a series of good ideas. A deep understanding of computer science, tools and frameworks, and problem domains (including market mechanisms) can expand potential ideas.
Recommended reading Click the title to jump
Interviewed with a 46-year-old programmer, I was full of thoughts
I am a little accomplished, but I can't pass the whiteboard interview
Pay attention to "the programmer's things" star, don't miss the circle
Inside the circle, I'm watching ❤️