Summary of 20 things I learned after working as a software engineer for 20 years

By Sergey Galyonkin

Justin Eseridge , the founder of software development company Simple Thread , has published 20 important points in learning and points to be aware of in coding based on 20 years of experience as a software engineer. I am.

20 Things I've Learned in my 20 Years as a Software Engineer --Simple Thread
https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

◆ 1: Realize that you don't know much yet
Even if he worked as a software engineer for decades, Eserridge argues that each engineer has different knowledge and can learn a lot from other software engineers. Also, if you realize that you are ignorant, you can learn from others and, conversely, get the joy of teaching others.

◆ 2: The most difficult part of software development is 'designing correctly'
Most software engineers disregard design because they think it 'reduces the value of their work.' Eserridge points out that if not properly designed, the work will be complicated and a lot of time will be lost. He claims that many benefits can be gained by relying on dedicated design members or improving one's own design ability without disregarding design.

◆ 3: The best software engineers think from the user's perspective
A good software engineer thinks about 'who', 'why' and 'how' to use the software he develops, and what is important to the user. To achieve a great user experience, it's important to keep in mind your needs.

◆ 4: The best code is a code that does not require maintenance
Most software engineers make a few mistakes when writing code. Nonetheless, engineering teams tend to fall into the 'NIH syndrome ' of trying to develop new software where existing software can be used. 'Developing new software can grow software engineers, but keep in mind that you risk making mistakes,' said Eserridge.

◆ 5: Software is a means
Software is a means to solve a purpose, and the job of a software engineer is to provide a means. Eseridge warns that if you aim to develop software, you may develop software that does not meet your needs.

◆ 6: If you get stuck, stop your hand
Some software engineers start writing code intuitively, while others analyze the problem in detail before writing code. At this time, if you put too much effort into analyzing the problem, you may end up in a situation called 'analysis paralysis' where you cannot move on to work. To avoid this, Eserridge recommends setting a deadline for problem analysis.

◆ 7: Grasp the feasible range when designing the system
Eserridge argues that it is impossible to design a rational solution if the system under development does not understand 'what is possible' and 'what is available'. .. Also, be careful, especially if someone who hasn't written the code for a long time is in charge of the design.

◆ 8: On the premise of failure, gain the ability to overcome it
It is impossible to develop perfect software. It is important for software engineers to accept this fact and aim for continuous improvement.

◆ 9: Continue asking questions until the answer is clear
Eserridge argues that 'the way it always is' should be questioned. For example, if you receive a feature request from a client whose purpose is unclear, you need to keep asking questions until it becomes clear 'why you need this feature' and 'where you need it' instead of implementing it as is. ... apparently ...

◆ 10: Focus should be placed on avoiding programmers who are dragging the team rather than finding programmers with transcendental skills
According to Mr. Eselridge, the idea that 'if you find a good programmer, you can produce what other programmers produce in two weeks in one day' is stupid. Rather than finding a good programmer, it should be more important to keep the programmers who are stuck in the team, such as 'do not ask for feedback', 'do not test the code', 'do not consider extreme cases', from the team.

◆ 11: Skilled engineers have their own opinions about tools
Experienced software engineers try many tools and approaches and form their own opinions about them. If you don't have your own opinion about a particular tool, you should actively seek ways to perform tasks using tools and techniques that are different from those of other users.

◆ 12: People do not want innovation
People talk a lot about innovation, but when software engineers actually try to implement innovation, they get mostly negative feedback. If you believe that innovation really improves things, you need to prepare for a long battle with negative opinions.

◆ 13: Customer data is the most important part of the system
When developing a system where data integrity is important, nightmarish correction work may be required due to the format of the data received from the customer. Eselridge says that the cost of keeping the data received from customers tidy will make the system easier to maintain and reward in the long run.

◆ 14: Utilize withered technology
'Withered technology' is a technology that has gained high stability through many years of accumulation and has survived the major changes that occur in the world of technology. These technologies are not flashy, but by adopting them, you can avoid situations such as 'the stability of the system is uncertain and you cannot sleep at night'.

◆ 15: Do not misunderstand a humble person as ignorance
Many software engineers do not give their opinions unless asked. Therefore, do not judge the other person as ignorant because he / she does not give his / her opinion. You can get a lot of feedback by asking for feedback and advice from yourself before you consider others ignorant.

◆ 16: Write sentences regularly
'Software engineers need to write blog journal documents on a regular basis to keep their written communication skills sharp,' Eselridge claims. According to Eserridge, writing those documents helps you think about your problems and communicate effectively with your team.

◆ 17: Keep the process as slim as possible
In recent years, many companies have introduced 'agile development, ' which repeats planning, design, implementation, and testing in a short cycle. However, Eserige said, 'If someone persistently recommends agile development, you may be trying to sell something.' 'Until you know what else you need, rely on the process. If you trust your team, your team members will pay off.'

◆ 18: Software engineers should also be involved in product operation
If you pull a software engineer away from the results of the product you develop, the software engineer will not be interested in the job. In recent years, as a development method that can prevent this problem, ' DevOps ', in which developers and operations staff work together, has become increasingly popular. 'If you give your passionate development team full design, build, and operational rights, you'll be amazed,' said Eserridge, recommending that software engineers build an environment where they can be involved in product operations. doing.

◆ 19: It is impossible to determine the ability of the engineer team who is enrolled in the company at the time of the interview
There are no interviewers who reveal that 'there are members with a power harassment' or 'there are members who have a habit of being late' at the interview. Therefore, Mr. Eseridge said, 'It is a wasteful effort to determine the ability and knowledge of the engineer team during the interview. What kind of interest do you have in your area of expertise during the interview? It's much better to focus on getting people to understand. '

◆ 20: Always strive to reduce the size of the system
The system that software engineers have to develop grows bloated due to reasons such as 'convenience of budget allocation', 'cannot determine in advance how much functionality can be reduced', and 'want to provide the' optimal version 'of the system'. That is often the case. 'You should face this. If you learn a lot while building a system, you can end up with a system that is much better than the one you originally designed.' He claims that by developing the system many times, he can acquire the ability to miniaturize the system.