Over time, people's views on certain things will continue to change. In the software development industry, this principle still applies. As a programmer, after Chris Kiehl worked for 6 years, many of his original ideas have changed, but there are also some old ideas that remain unchanged.
1
My views on these things have changed. For the
following things, in the past, I would argue endlessly, but now I believe it.
If your team members have varying levels of technical experience, it is better to use a strongly typed programming language.
The stand-up meeting is actually very useful for following newcomers.
As long as it is for correcting the course of action, then the Sprint review is very useful. This is not agile for the sake of "agility" and waste everyone's time.
Software architecture may be more important than anything else. A good abstraction layer, even if its realization is like a pile of shit, will not bring pure harm to the project. However, a bad abstraction layer can ruin the entire project.
Java is not a terrible programming language.
Appearing smart code is usually not good code. Clarity trumps everything.
Following any paradigm can lead to bad code.
The so-called "best practices" are related to actual conditions and are not widely applicable. Following them blindly will make you an idiot.
Designing a scalable system when it is not necessary will make you a bad engineer.
Static code analysis is very useful.
The DRY principle is to avoid certain specific problems, not its own ultimate goal.
Generally speaking, RDBMS is better than NoSQL.
Functional programming is another optional tool, but it is not a panacea.
2
new ideas formed the years
to follow this order YAGNI, SOLID, DRY.
Pencil and paper are actually the best programming tools, but they have been overlooked.
It is usually a good choice to trade purity for practicality.
Adding too much technology is rarely a good choice.
Direct communication with customers will always reveal more problems with less time and greater accuracy.
The word "scalable" has a mysterious and shocking power for software engineers, enough to make them fall into a kind of depraved madness.
Although developers are called "engineers", most of their decisions are purely Cargo Cult, with no analysis, data or numbers as the basis.
90% (probably 93%) of project managers may disappear in the future, because they will not bring efficiency improvements.
After doing more than 100 interviews, I found that the format of interviews is completely invalid, but I don't know how to make it better.
3
Those old ideas that stay the same.
Those who emphasize coding style, lint rules, or other details are crazy weirdos.
Code coverage has nothing to do with code quality.
In most cases, a monolithic system is sufficient.
TDD purists are the worst. Their fragile little heads cannot tolerate the existence of different workflows.
After the tenth year, let's see which views have been reversed or changed.