4 ms·

> a well designed, beautifully architectured application I've seen everything during my career, bad code with lots of bugs, bad code running stable. Nice code

> a well designed, beautifully architectured application I've seen everything during my career, bad code with lots of bugs, bad code running stable. Nice code full of bugs, and nice stable code. The reason something was stable was never how the code looked, but how battle tested the product was. You will learn, don't worry. Plus, at a certain point, it's about tradoffs and compromises. I would love to see highly optimized code that is easy to read. > only tests can tell whether or not it works Tests are nice, but the real test will be when users start breaking your app. I'm curious, what kind of product are you writing?

mpfundstein 6y ago
you assume a little bit to much about your discussion partners. calling them inexperienced etc... this takes away the whole strength of your argument plus lets you sound like a douche. plz fix
- koonsolo 6y ago
  The original argument is what I consider one of the biggest beginner mistakes. So the inexperience argument is very much relevant. I was young and inexperienced once, and I had the same belief. But after bumping my head against the wall, I learned. In the mean time, I saw plenty of people bumping their head against the same wall. They all learned. So therefore I assume this person is indeed inexperienced. If I'm talking to some senior developer, then it's up to me to reassess my way of thinking, and looking where I'm missing something. But if not, then it's just the phase we all went through.
- Person5478 6y ago
  I agree with him. It's indicative of more idealism than practical sense, which is indicative of inexperience.
- deleted 6y ago
  [deleted]
gugagore 6y ago
> I would love to see highly optimized code that is easy to read. That that's a trade-off is [just] a deficiency in our programming languages and tooling around them. As we evolve are young field (and if you've had a long career, then it is even younger to you!) I trust we will find more and more highly-optimized code that is easy to read.
- koonsolo 6y ago
  Computer languages are a means of communication between a human and a computer. They clearly evolved closer to human readability and understanding, and away from computer language itself. When you optimize, your code needs to be closer to computer language again, and therefore further away from human readability. The only way to have both, is to have a system that can optimize the code automatically. We are getting closer to that, but still sometimes this is not enough.
brabel 6y ago
I've written code in all sorts of scenarios: government, web application back and front ends, auth, simulations, testing software, statical analysis, long-maintained products, throwaway but complex scripts for one-use-only, and multiple popular libraries I maintain. Difficult-to-read code always causes problems, either because it directly causes bugs due to its logic being obfuscated, or because no one can approach it to make necessary modifications when change is invevitably required. You claim that "The reason something was stable was never how the code looked, but how battle tested the product was". I am claiming that you're wrong and your counter-argument is that I will learn to be like you one day. This shows that you're the one who has to grow up. I am constantly looking for ways to write code that works in all scenarios, provably. I don't need to battle test code if I can do that. I only need battle tested code in the absence of that property. I will concede that in many occasions, this is all you can get, but that's due to a lack of time and skills, not an inherent property of a system or the process of writing software. It's sad to see people who gave up on creating good software (because if you only can create reliable software after it's battle tested, that means it was buggy all along before that - so for the majority of the life of your product, your software was buggy - that is not acceptable). If you believe I am a dreamer, an unexperienced developer, let me prove you wrong. Show me some code you believe it's impossible to make reliable without "battle-testing" it over a decade, and I will show you how.

mpfundstein 6y ago

you assume a little bit to much about your discussion partners. calling them inexperienced etc... this takes away the whole strength of your argument plus lets you sound like a douche. plz fix

koonsolo 6y ago
The original argument is what I consider one of the biggest beginner mistakes. So the inexperience argument is very much relevant. I was young and inexperienced once, and I had the same belief. But after bumping my head against the wall, I learned. In the mean time, I saw plenty of people bumping their head against the same wall. They all learned. So therefore I assume this person is indeed inexperienced. If I'm talking to some senior developer, then it's up to me to reassess my way of thinking, and looking where I'm missing something. But if not, then it's just the phase we all went through.
Person5478 6y ago
I agree with him. It's indicative of more idealism than practical sense, which is indicative of inexperience.
deleted 6y ago
[deleted]

gugagore 6y ago

> I would love to see highly optimized code that is easy to read. That that's a trade-off is [just] a deficiency in our programming languages and tooling around them. As we evolve are young field (and if you've had a long career, then it is even younger to you!) I trust we will find more and more highly-optimized code that is easy to read.

koonsolo 6y ago
Computer languages are a means of communication between a human and a computer. They clearly evolved closer to human readability and understanding, and away from computer language itself. When you optimize, your code needs to be closer to computer language again, and therefore further away from human readability. The only way to have both, is to have a system that can optimize the code automatically. We are getting closer to that, but still sometimes this is not enough.

brabel 6y ago

I've written code in all sorts of scenarios: government, web application back and front ends, auth, simulations, testing software, statical analysis, long-maintained products, throwaway but complex scripts for one-use-only, and multiple popular libraries I maintain. Difficult-to-read code always causes problems, either because it directly causes bugs due to its logic being obfuscated, or because no one can approach it to make necessary modifications when change is invevitably required. You claim that "The reason something was stable was never how the code looked, but how battle tested the product was". I am claiming that you're wrong and your counter-argument is that I will learn to be like you one day. This shows that you're the one who has to grow up. I am constantly looking for ways to write code that works in all scenarios, provably. I don't need to battle test code if I can do that. I only need battle tested code in the absence of that property. I will concede that in many occasions, this is all you can get, but that's due to a lack of time and skills, not an inherent property of a system or the process of writing software. It's sad to see people who gave up on creating good software (because if you only can create reliable software after it's battle tested, that means it was buggy all along before that - so for the majority of the life of your product, your software was buggy - that is not acceptable). If you believe I am a dreamer, an unexperienced developer, let me prove you wrong. Show me some code you believe it's impossible to make reliable without "battle-testing" it over a decade, and I will show you how.