Люблю такие статьи в стиле lessons learned и сам люблю говорить на эту тему. Правда в последнее время прихожу к мысли что некоторые советы даже если их прочитать и понять логику, просто не получится применить или прочувствовать/понять. В молодости всегда хочется доказать, что ты умнее/сильнее и у тебя другой путь. Ну это как родительское "одевай шапку зимой" чувствуешь только после того как пару раз сляжешь с серьезным воспалением чего-нибудь.
Но! Это не значит, что про это не надо говорить, такие статьи помогают структурировать и уложить в голове хотя бы то, через что уже точно прошел сам, а значит может появится доверие и к другим советам.
Вынес пару советов которые понравились, остальные читайте в оригинальной статье.
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it. Build the thing in the simplest way you can, as fast as you can. You can improve it over time as needs demand.
The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over. I’ve lost track of all of the software I’ve delivered that isn’t running anywhere anymore. Some of that is because my career is 35 years long. But even some of the software I worked on five or ten years ago isn’t running anymore. This is another good reason to build small increments, just good enough, get them out there, and iterate from there. Anything more and you’ve overbuilt some software that isn’t going to run forever anyway.
https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/
Но! Это не значит, что про это не надо говорить, такие статьи помогают структурировать и уложить в голове хотя бы то, через что уже точно прошел сам, а значит может появится доверие и к другим советам.
Вынес пару советов которые понравились, остальные читайте в оригинальной статье.
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it. Build the thing in the simplest way you can, as fast as you can. You can improve it over time as needs demand.
The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over. I’ve lost track of all of the software I’ve delivered that isn’t running anywhere anymore. Some of that is because my career is 35 years long. But even some of the software I worked on five or ten years ago isn’t running anymore. This is another good reason to build small increments, just good enough, get them out there, and iterate from there. Anything more and you’ve overbuilt some software that isn’t going to run forever anyway.
https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/