A programmer is like a bartender, he needs to live by principles. You can also compare it to a girl without principles, but that would be a sexist comparison, because principles are necessary not only for girls, but for any person, regardless of gender, just with real guys often talk about concepts.
Anyway, programming has its principles, too, so cool programmers can live by IT concepts. Today I decided to walk through the concepts and deal with them.

Very often I will explain in my own words, which may be different from what other programmers or book authors use. Take this work as my personal opinion and as my personal attempt at interpreting the principles. There will be NO official definitions.

Make it work
The first place to start is to just make a working prototype that will work. I only jump right into the final implementation if I’ve done the task before and already know exactly how to implement it. Most often I have to do something new, unique and you can’t jump right into implementation, first I write code to implement the task and it may not even be very nice and perfect. If you cover the code with tests then it’s easy and without problems to refactor and improve the code.

This notion can also be taken as – just implement the task, because the end user doesn’t care what language the application is written in, what server is running on, what cloud is used and so on. What’s most important to users is that the application works and performs the task at hand, so just do it.

This notion doesn’t mean that we can make stuff just because the user doesn’t care about what technology we use. We need to implement, but also think about quality.

KISS – keep it simple stupid.
I love the fact that the principle of “keep it simple stupid” tells us to keep it simple, but it consists of four letters and words, but you could keep it simple and say KIS and just Keep it Simple and the meaning would not change.

So let’s keep it simple and just say KIS, I even recorded a video once, that for me those three letters are hours important.

You Aren’t Gonna Need It
You Aren’t Gonna Need It is also a very good and important principle that is now very easy to follow. There were times when programmers would comment out code to turn it off, but leave it on in case they needed it. Worse, if it wasn’t commented out, it was just removed calls. That is, the function exists, but it is not used anywhere. So these are the clear cases where you have to kill the code mercilessly and leave no garbage behind.

Thanks to GIT, it’s very easy to find the right code in history that someone deleted years ago and, if necessary, restore it.

If we don’t need something now, we don’t do it. This statement overlaps with the KISS definition, but sometimes I see it applied to YAGNI as well.

Don’t repeat yourself
Don’t repeat yourself is a very old principle that hasn’t lost its relevance even now in many architectures. But there are exceptions here – microservices, which are desirable to make KISS beyond the end, so that there are fewer dependencies, because they are micro.

In general it is very desirable to write code in such a way that it doesn’t repeat itself. If the same piece of code is in different classes of the same application, there is obviously something wrong.

Standing On The Shoulder Of Giants
Standing On The Shoulder Of Giants tells us to choose industry-standard and already-formed technologies and not to write solutions ourselves. In general I agree with this statement, but here we are walking on thin ice, because sometimes it is more efficient to choose a small solution that is not an industry standard but solves the problem better than a monster.

Standing on the shoulders of giants can violate the KISS principle, so this statement is generally good and important, but very peculiar.

Yes, we should follow standards, use best practices, programming patterns, better and modern tools, but if we just need to write a static single page, then doing it on the .NET platform may be too expensive and a foolish choice. Note that I said “might be.” Everything in programming is very subtle and even a single-page can be a very complex SPA application.

Yes, we choose standards and stand on the shoulders of giants, but do not forget that the code must be as simple as possible.

Boy Scout Rule
The Boy Scout rule according to Uncle Bob says that we should leave behind cleaner code than the one before us. It’s almost a constant refactoring – improving the code so that it doesn’t turn into mush.

Every time you have to modify existing code, don’t just solve the problem at hand, but make sure the code at least stays as clean, or better yet make it even cleaner, if possible. With tests in place, this shouldn’t be a problem.