12 ms·

I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts are

by atoav 3y ago

I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong. Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures. Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team. This isn't always a simple thing, but it must be done. The saddest aspect is that you see many experienced software developers who never experienced things working well. And as someone who sometimes writes code for fun I cannot understand that at all. What I get is that throughout your professional life you can never had the chance to be in a project where you could write good code. However you can write good or even perfect code at home where nobody pressures you. And if it is possible there, why wouldn't it be in a professional context?

whstl 3y ago
But what is "good code", even? For some people that's thousands of two-line methods in hundreds of classes where each part is easy to understand. For others it is more direct code that is optimized for debugging, but not as aesthetically pleasant. Very often those two groups people dislike each other's code a lot. And there's even more other "groups" than those obvious two.
- atoav 3y ago
  Does that question really matter for this discussion? Every developer will have their own flavour of what constitutes good or bad code, but independent of their flavour isn't a software engineer who doesn't believe in the possibility of achieving good code a somewhat sad thing? Imagine being a cook that doesn't believe in the possibility of cooking good food — sure what constitutes good food is a matter of discussion, but if you have a cook that doesn't believe in it that alone is remarkable in itself.
  - whstl 3y ago
    It does matter because what constitutes good code for some people is often terrible code for others, to the point of people making jokes about it [1]. With food, at least there is a wider agreement of what consists of good and bad. [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
    - atoav 3y ago
      But we are talking about self-judgment here. What does it matter which flavour of good you expect your code to be if you actually don't believe good code by your definition can be realistically achieved?
      - whstl 3y ago
        I agree with the sentiment, never said anywhere that it couldn't be achieved in a personal level. Just that defining "good code" is difficult. If you narrow down "good code" to mean "good to myself" then of course it is sad that someone doesn't believe in it. On the other hand, I find that someone saying that "universally good code" is not possible as understandable. I personally believe it is only really achievable in certain domains, for some others (especially for code handling a lot of essential complexity) it is borderline impossible to not have at least some uneven corners. And there's only so much you can sweep under the carpet of indirection.
matjazmuhic 3y ago
Now imagine a carpenter who can build the most beautiful, elegant piece of furniture in 30 days, but you force them to make it in 10. Or you forbid them from using a certain tool. Or force them to use a tool you prefer. Or … Yes, not every programmer cares about good code. But of those that do, also not all of them can agree on what good code is. And not all good programmers can write good code, for one reason or another. It is way less black and white than good vs bad/mediocre programmers.
- quietbritishjim 3y ago
  > Now imagine a carpenter who can build the most beautiful, elegant piece of furniture in 30 days, but you force them to make it in 10. Or you forbid them from using a certain tool. Or force them to use a tool you prefer. Or … Some of these are not like the others. Not allowing a carpenter to use the most suitable tools is petty. Not allowing them 30 days may make sense depending on the business context. What if it's a stool that's going to be sat on once and then thrown away? Or there's only 10 days salary in the bank but then an invester will see it and may pay for 100 days work? Good code usually takes more time than bad code (depending on the reason!) and often it is worth that extra time (and the fight to get it). But sometimes it's better not to and that's OK.
  - matjazmuhic 3y ago
    Completely agree. It’s all about trade-offs. Which many developers don’t - or just refuse to - understand. My point was that without some context this kind of conversations - about good and bad code and good and bad coders - are not very useful.
    - atoav 3y ago
      Yeah sure, but in the context of my argument (it is sad that there are aoftware developers who don't believe the product of their craft can ever be good) it doesn't actually matter. Sure, maybe that just means coders have impossible standards that cannot be reached, ever. Or it could mean that typical projects tend to be manages in a way that leads to code that those who wrote it don't consider good (to such a degree where they don't believe good code is actually possible). Personally I believe good code is an reliable, maintainable, transparent and well designed solution for a problem (or a set of problems). And that means for a small problem aome ad hoc script can be good, while for a big complicated set of problems an elaborate well coded project with a build system can be good code. But what I believe is that there are ideal solutions from an engineering standpoint, and there are ideal solutions from an business standpoint. And those sometimes don't align with each other. E.g. when you solve a core problem that should really be dealt with properly with a quick fix that might be a cheap way to reach the short term business goals, but it could shape a lot of engineering decisions in the future in a bad way and maybe even become a business problem in the long term.
pjmlp 3y ago
Imagine that the carpenter already gets the wood cut from a far far away land, and has to make due to the way they were prepared. After nailing a couple of them together, it has to send them to another far far away land, for some glue job. Afterwards he gets them back, he applies varnish over the wood pieces, and sends them yet again to another far far away land for the paint job. Those people on the far far away lands don't have any carpentery training and do whatever they feel like to meet the description of what they are supposed to deliver back. While the carpenter tries to rescue what is possible from each delivery, so that the table and chairs only look half as bad, people can still seat on them without falling, and the tables have four legs about the same size.
- jacquesm 3y ago
  This is a very concise description of a lot of modern manufacturing. I just took apart a bunch of stuff on a VW van: the bus itself was nominally manufactured in Poland. According to some of the labels the guts of the servo that I took apart and repaired was made in Switzerland. But the servo itself was made in Germany. When you look at the guts parts of it were made in China, parts in Japan and probably some parts in Switzerland but it's unclear which those would be. The parts of that car have collectively already traveled more than the car ever will by the time it gets delivered to the customer (in the Netherlands).
  - pjmlp 3y ago
    Indeed, it is everywhere.

by atoav 3y ago

whstl 3y ago

But what is "good code", even? For some people that's thousands of two-line methods in hundreds of classes where each part is easy to understand. For others it is more direct code that is optimized for debugging, but not as aesthetically pleasant. Very often those two groups people dislike each other's code a lot. And there's even more other "groups" than those obvious two.

atoav 3y ago
Does that question really matter for this discussion? Every developer will have their own flavour of what constitutes good or bad code, but independent of their flavour isn't a software engineer who doesn't believe in the possibility of achieving good code a somewhat sad thing? Imagine being a cook that doesn't believe in the possibility of cooking good food — sure what constitutes good food is a matter of discussion, but if you have a cook that doesn't believe in it that alone is remarkable in itself.
- whstl 3y ago
  It does matter because what constitutes good code for some people is often terrible code for others, to the point of people making jokes about it [1]. With food, at least there is a wider agreement of what consists of good and bad. [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - atoav 3y ago
    But we are talking about self-judgment here. What does it matter which flavour of good you expect your code to be if you actually don't believe good code by your definition can be realistically achieved?
    - whstl 3y ago
      I agree with the sentiment, never said anywhere that it couldn't be achieved in a personal level. Just that defining "good code" is difficult. If you narrow down "good code" to mean "good to myself" then of course it is sad that someone doesn't believe in it. On the other hand, I find that someone saying that "universally good code" is not possible as understandable. I personally believe it is only really achievable in certain domains, for some others (especially for code handling a lot of essential complexity) it is borderline impossible to not have at least some uneven corners. And there's only so much you can sweep under the carpet of indirection.

matjazmuhic 3y ago

Now imagine a carpenter who can build the most beautiful, elegant piece of furniture in 30 days, but you force them to make it in 10. Or you forbid them from using a certain tool. Or force them to use a tool you prefer. Or … Yes, not every programmer cares about good code. But of those that do, also not all of them can agree on what good code is. And not all good programmers can write good code, for one reason or another. It is way less black and white than good vs bad/mediocre programmers.

quietbritishjim 3y ago
> Now imagine a carpenter who can build the most beautiful, elegant piece of furniture in 30 days, but you force them to make it in 10. Or you forbid them from using a certain tool. Or force them to use a tool you prefer. Or … Some of these are not like the others. Not allowing a carpenter to use the most suitable tools is petty. Not allowing them 30 days may make sense depending on the business context. What if it's a stool that's going to be sat on once and then thrown away? Or there's only 10 days salary in the bank but then an invester will see it and may pay for 100 days work? Good code usually takes more time than bad code (depending on the reason!) and often it is worth that extra time (and the fight to get it). But sometimes it's better not to and that's OK.
- matjazmuhic 3y ago
  Completely agree. It’s all about trade-offs. Which many developers don’t - or just refuse to - understand. My point was that without some context this kind of conversations - about good and bad code and good and bad coders - are not very useful.
  - atoav 3y ago
    Yeah sure, but in the context of my argument (it is sad that there are aoftware developers who don't believe the product of their craft can ever be good) it doesn't actually matter. Sure, maybe that just means coders have impossible standards that cannot be reached, ever. Or it could mean that typical projects tend to be manages in a way that leads to code that those who wrote it don't consider good (to such a degree where they don't believe good code is actually possible). Personally I believe good code is an reliable, maintainable, transparent and well designed solution for a problem (or a set of problems). And that means for a small problem aome ad hoc script can be good, while for a big complicated set of problems an elaborate well coded project with a build system can be good code. But what I believe is that there are ideal solutions from an engineering standpoint, and there are ideal solutions from an business standpoint. And those sometimes don't align with each other. E.g. when you solve a core problem that should really be dealt with properly with a quick fix that might be a cheap way to reach the short term business goals, but it could shape a lot of engineering decisions in the future in a bad way and maybe even become a business problem in the long term.

pjmlp 3y ago

Imagine that the carpenter already gets the wood cut from a far far away land, and has to make due to the way they were prepared. After nailing a couple of them together, it has to send them to another far far away land, for some glue job. Afterwards he gets them back, he applies varnish over the wood pieces, and sends them yet again to another far far away land for the paint job. Those people on the far far away lands don't have any carpentery training and do whatever they feel like to meet the description of what they are supposed to deliver back. While the carpenter tries to rescue what is possible from each delivery, so that the table and chairs only look half as bad, people can still seat on them without falling, and the tables have four legs about the same size.

jacquesm 3y ago
This is a very concise description of a lot of modern manufacturing. I just took apart a bunch of stuff on a VW van: the bus itself was nominally manufactured in Poland. According to some of the labels the guts of the servo that I took apart and repaired was made in Switzerland. But the servo itself was made in Germany. When you look at the guts parts of it were made in China, parts in Japan and probably some parts in Switzerland but it's unclear which those would be. The parts of that car have collectively already traveled more than the car ever will by the time it gets delivered to the customer (in the Netherlands).
- pjmlp 3y ago
  Indeed, it is everywhere.