3 ms·

Hi, my notes: 1) Experts involve the user. Also, experts do not let the user design the software. The user will frequently want to tell you what the software

Hi, my notes: 1) Experts involve the user. Also, experts do not let the user design the software. The user will frequently want to tell you what the software "must" be doing. An expert will disregard this and will want to first understand the domain and then work with the user to find a good mapping to a useful interface. 2) Experts design elegant abstractions I don't agree on this. Oftentimes, I have seen "experts" use solutions because they seemed elegant, intelligent, "nifty". I did that myself. An expert will design simple abstractions that let the job done with little fuss. The software needs to be as simple as possible but not simpler than is needed. Replace "elegant" with "simple", and it sounds about right. An expert software looks dumb and simple, not necessarily super elegant and intelligent. Also, bad software can look dumb and simple. 3) Experts focus on the essence Experts start by focusing on the essence. Then verify by testing how the distilled essence is useful at solving entirety of the problem.

dgb23 5y ago
> Replace "elegant" with "simple", and it sounds about right. Good point, but I would argue they are identical.
- lmilcin 5y ago
  I don't think so. Let me explain from my experience. I have been asked to create a payment gateway for a company. We found an elegant solution that consisted of general components that we could just configure and wire together so that we will never need to write another payment gateway. This was a mistake and we found it on next project that involved adding new payment method. We found that yes, it could be rewired and configured without any development at all. But the process to do so took so much effort, that we would just be able to write a new payment gateway in less time. The simpler (but less elegant) solution would be to just write the minimum code necessary (of course still neatly and nicely), and then implement the other payment gateway separately. We should have then extracted common model and infrastructure until there is nothing left and we again are left with a single, coherent application. We have prematurely optimized, put a lot of upfront effort for unknown benefit. The benefit happened to be negligible and the resulting code was complex and costly to work with. But sure it looked elegant. Now that I am wiser for this lesson I am trying to use patterns to produce simple dumb code that models the problem well enough without details that are not necessary for the particular instance of the problem.
  - dgb23 5y ago
    If I understand correctly you exposed an interface that was too general (AKA low level) for the user's semantics. It seems to me that this interface was fitting for you as the developers to write new features on top of though? In other words, if with think in terms of simplicity then maybe the right approach was to have the general interface as your abstraction layer and on the higher layer you have something that is semantically close to what your users understand. The general layer would be simple as I understand it and provide the building blocks for the more specifically designed user interface.
austincheney 5y ago
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?"
AnimalMuppet 5y ago
I think that experts design what the user needs, not what the user says that they want. Real experts have enough experience, wisdom, and listening skills to get this right; non-expert-but-wanna-bees have enough arrogance to think that they think they get it right, but they don't.

dgb23 5y ago

> Replace "elegant" with "simple", and it sounds about right. Good point, but I would argue they are identical.

lmilcin 5y ago
I don't think so. Let me explain from my experience. I have been asked to create a payment gateway for a company. We found an elegant solution that consisted of general components that we could just configure and wire together so that we will never need to write another payment gateway. This was a mistake and we found it on next project that involved adding new payment method. We found that yes, it could be rewired and configured without any development at all. But the process to do so took so much effort, that we would just be able to write a new payment gateway in less time. The simpler (but less elegant) solution would be to just write the minimum code necessary (of course still neatly and nicely), and then implement the other payment gateway separately. We should have then extracted common model and infrastructure until there is nothing left and we again are left with a single, coherent application. We have prematurely optimized, put a lot of upfront effort for unknown benefit. The benefit happened to be negligible and the resulting code was complex and costly to work with. But sure it looked elegant. Now that I am wiser for this lesson I am trying to use patterns to produce simple dumb code that models the problem well enough without details that are not necessary for the particular instance of the problem.
- dgb23 5y ago
  If I understand correctly you exposed an interface that was too general (AKA low level) for the user's semantics. It seems to me that this interface was fitting for you as the developers to write new features on top of though? In other words, if with think in terms of simplicity then maybe the right approach was to have the general interface as your abstraction layer and on the higher layer you have something that is semantically close to what your users understand. The general layer would be simple as I understand it and provide the building blocks for the more specifically designed user interface.

austincheney 5y ago

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?"

AnimalMuppet 5y ago

I think that experts design what the user needs, not what the user says that they want. Real experts have enough experience, wisdom, and listening skills to get this right; non-expert-but-wanna-bees have enough arrogance to think that they think they get it right, but they don't.