4 ms·

Some clarity: 1) Experts don’t say fuck you user by intentionally doing hostile things for their own convenience or emotional satisfaction. 2) Elegance direct

Some clarity: 1) Experts don’t say fuck you user by intentionally doing hostile things for their own convenience or emotional satisfaction. 2) Elegance directly suggests simplicity and polish where simple means few: https://en.m.wikipedia.org/wiki/Elegance https://en.m.wikipedia.org/wiki/Elegance https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/ That’s fewer shit in the code, which eliminates decoration and unnecessary conventions many developers cannot live without. 3) Beginners and weak insecure developers focus on composition. Experts focus on the end state.

lmilcin 5y ago
Oh, of course, that's all true. The difference between elegance and simplicity is when you start to talk to developers who learned just enough to be able to put patterns in their projects but not enough to know when to do so. > 3) Beginners and weak insecure developers focus on composition. Experts focus on the end state. That is one more way to say that experts use programming as a tool and that programming is not a problem for them and so the biggest issue they see is that the end result is the right one. It is easier to focus on the end goal when you trust you have some kind of solution for any problem that can happen on the way. On the other hand novice and intermediate developers focus on technical because this is the challenge they are facing. And they don't yet feel they can solve every problem they will face. You can't tell them to not focus on technical because it is useless advice -- they need to learn technical first before they can become experts and focus fully on the end goal. The best you can do is to remind that the end goal is important and keep it on the back of their heads even when they are immersed in technical challenges. ** As to "insecure" developers, I think there is something to it. Moving from purely technical problems to other kinds of problems (looking at big picture of the product, the client and the development team) requires a little bit of courage (don't laugh). It is easy to keep working within the same types of problems that you are comfortable with, and make illusion of progress by changing technologies, working with larger applications and so on. I had a prospective client some time ago. They wanted me to help with their application. They had trouble delivering and additionally their application was unreliable. So on the meeting with the director, architect and tech lead they asked me to start by upgrading Java from 6 to 11. Mind, that this is discussion with a director that had some 40 devs and reached out to me personally to get help. So I asked "Guys, do you really want to say that people were not able to deliver reliable application with Java 6? Or maybe the problems are somewhere else?"

lmilcin 5y ago

Oh, of course, that's all true. The difference between elegance and simplicity is when you start to talk to developers who learned just enough to be able to put patterns in their projects but not enough to know when to do so. > 3) Beginners and weak insecure developers focus on composition. Experts focus on the end state. That is one more way to say that experts use programming as a tool and that programming is not a problem for them and so the biggest issue they see is that the end result is the right one. It is easier to focus on the end goal when you trust you have some kind of solution for any problem that can happen on the way. On the other hand novice and intermediate developers focus on technical because this is the challenge they are facing. And they don't yet feel they can solve every problem they will face. You can't tell them to not focus on technical because it is useless advice -- they need to learn technical first before they can become experts and focus fully on the end goal. The best you can do is to remind that the end goal is important and keep it on the back of their heads even when they are immersed in technical challenges. ** As to "insecure" developers, I think there is something to it. Moving from purely technical problems to other kinds of problems (looking at big picture of the product, the client and the development team) requires a little bit of courage (don't laugh). It is easy to keep working within the same types of problems that you are comfortable with, and make illusion of progress by changing technologies, working with larger applications and so on. I had a prospective client some time ago. They wanted me to help with their application. They had trouble delivering and additionally their application was unreliable. So on the meeting with the director, architect and tech lead they asked me to start by upgrading Java from 6 to 11. Mind, that this is discussion with a director that had some 40 devs and reached out to me personally to get help. So I asked "Guys, do you really want to say that people were not able to deliver reliable application with Java 6? Or maybe the problems are somewhere else?"