6 ms·

How do I know? No bugs were reported. People take % of code coverage as some insurance and spend time writing stupid tests instead of writing robust code. Peo

by nikolay 11y ago

How do I know? No bugs were reported. People take % of code coverage as some insurance and spend time writing stupid tests instead of writing robust code. People also don't think that unit tests are constant maintenance burden and a time waster - you change this and that and then you need to spend time entertaining the tests. Again, use your brain, not your fingers - it's that easy! Oh, and don't program using a dynamic language saving keystrokes, but wasting, even more, writing brainless unit tests! At least in my personal career, most, though, and real issues come from race conditions. But I've been fortunate to catch them quickly by using my brain. And that's what we lack today - developers who use their brains, who don't spend too much time on emoji reactions in Slack and finding the right GIF. There's plenty lots of code monkeys and code gluers today that can't even implement a bubble sort without googling it!

onion2k 11y ago
People also don't think that unit tests are constant maintenance and time waster - you change this and then, you need to spend time tweaking tests. That's why you test interfaces, that you've spent time designing so they don't change often. You, or someone else who isn't as good as you, can change the internals of a block without updating the tests. Given the choice of working with a dev who knows how to write a bubble sort[1] and a dev doesn't but does write tests, I'd go for the latter. [1] To be honest, if someone in my team even considered writing their own sort function, from memory or by googling, I'd have a quiet word. Use a library. Preferably a well-tested one.
- nikolay 11y ago
  This is not about memorizing useless stuff, but about knowing the foundation of Computer Science. Our brains are full of emojis today, not algorithms. It's been scientifically proven that the Internet is making us more stupid by tweaking our brains' modus operandi to offload memory to Google and StackOverflow. We think memorizing has just a storage function, but it doesn't - when knowledge is planted in our brains, it just doesn't sit passively in there, but its accumulation improves our thought process by using things like generalizations, drawing analogies, etc. So, again, this is not about being dependent on the Internet as much as it is about growing better brains. I don't think we're smarter than people 100 years ago - we just have more tools to compensate for our shrinking brains. By the way, I also test my code - just not the way the newly-bred "ninjas" do it - pair program, peer review, and all this fancy useless stuff! By the way, I have over 30 years of software development (not coding!) experience. I've attended many programming contests (not hackathons) since childhood and won most of them. You don't hear about such contests anymore - gluing up a quick POC together is the big deal today, and this is just pathetic. And no wonder we have so much POC-quality code in Production (with a capital "P") today! And a craziness like CD to Production is considered the cool new trend - Production is not sacred anymore, and everybody can dishonor it as they wish! Again, I'm talking about the large gray mass of developers; there are still a lot of true developers alive today, but they are becoming extinct, unfortunately!
  - crummy 11y ago
    How do you test your code?
    - nikolay 11y ago
      Honestly? Mainly, reviewing it and debugging it in my mind. It works - you should try it! It makes you a smarter and a better developer as well. The try-refresh-repeat cycle is for amateurs. But that comes with the way I write my code - modular, i.e. broken into small, readable and reusable units. Well, if I'm doing a something that requires shaving off any redundant CPU cycle, that's another story, but as we know, premature optimization is the root of all evil. You won't see anywhere in my code long functions/methods, endlessly nested IF-THENs, and similar junk - writing simple, unfancy, DRY code drops the need for unit tests to almost zero. Using long, but meaningful identifiers drop the need for inline documentation. I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! There are way too many coders today and very few engineers!
      - onion2k 11y ago
        I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! I don't really understand this point. UnitTest and SUnit, that all subsequent unit testing frameworks are based on, were released in about 1990. "Extreme Programming" was a big thing in the mid-90s and that featured test frameworks as a core component. Automated testing isn't new. There are plenty of old books that advocate exactly the "new and trendy" processes you decry. If your argument is "Write code like engineers did 20+ years ago!", then that includes automated testing. I strongly suspect that we're not actually that far apart in our thinking. I don't believe that unit tests magically make your code better. You can't develop a solution to a problem you don't fully understand by throwing more and more tests at it. Developers still need to take the time to think. I believe a lot of my enthusiasm for testing comes from the belief (...experience...) that there are plenty of developers out there who, as you put it it, are coders rather than engineers. My tests pick up their mistakes (and mine, because sometimes I'm not at my best). Maybe, if you're very fortunate, you've managed to surround yourself with a team who are all really good engineers who genuinely don't need to test things because they're rigorous to the point of infallibility. I haven't, and I work in an industry that means I probably never will, so tests are necessary. Advocating testing is much, much more productive, and will lead to better software in the long run, than advocating developers write better code.
- nikolay 11y ago
  Oh, I forgot to mention the ever-shrinking attention span. Our lives become fuller and fuller of distractions and interruptions. With the increasing load of notifications, alerts, and news feed updates, we can't really concentrate and grasp hard concepts. And we, the people involved in startups and being behind these distractions, are eating our own dogfood and suffering from the same evil.

by nikolay 11y ago

onion2k 11y ago

People also don't think that unit tests are constant maintenance and time waster - you change this and then, you need to spend time tweaking tests. That's why you test interfaces, that you've spent time designing so they don't change often. You, or someone else who isn't as good as you, can change the internals of a block without updating the tests. Given the choice of working with a dev who knows how to write a bubble sort[1] and a dev doesn't but does write tests, I'd go for the latter. [1] To be honest, if someone in my team even considered writing their own sort function, from memory or by googling, I'd have a quiet word. Use a library. Preferably a well-tested one.

nikolay 11y ago
This is not about memorizing useless stuff, but about knowing the foundation of Computer Science. Our brains are full of emojis today, not algorithms. It's been scientifically proven that the Internet is making us more stupid by tweaking our brains' modus operandi to offload memory to Google and StackOverflow. We think memorizing has just a storage function, but it doesn't - when knowledge is planted in our brains, it just doesn't sit passively in there, but its accumulation improves our thought process by using things like generalizations, drawing analogies, etc. So, again, this is not about being dependent on the Internet as much as it is about growing better brains. I don't think we're smarter than people 100 years ago - we just have more tools to compensate for our shrinking brains. By the way, I also test my code - just not the way the newly-bred "ninjas" do it - pair program, peer review, and all this fancy useless stuff! By the way, I have over 30 years of software development (not coding!) experience. I've attended many programming contests (not hackathons) since childhood and won most of them. You don't hear about such contests anymore - gluing up a quick POC together is the big deal today, and this is just pathetic. And no wonder we have so much POC-quality code in Production (with a capital "P") today! And a craziness like CD to Production is considered the cool new trend - Production is not sacred anymore, and everybody can dishonor it as they wish! Again, I'm talking about the large gray mass of developers; there are still a lot of true developers alive today, but they are becoming extinct, unfortunately!
- crummy 11y ago
  How do you test your code?
  - nikolay 11y ago
    Honestly? Mainly, reviewing it and debugging it in my mind. It works - you should try it! It makes you a smarter and a better developer as well. The try-refresh-repeat cycle is for amateurs. But that comes with the way I write my code - modular, i.e. broken into small, readable and reusable units. Well, if I'm doing a something that requires shaving off any redundant CPU cycle, that's another story, but as we know, premature optimization is the root of all evil. You won't see anywhere in my code long functions/methods, endlessly nested IF-THENs, and similar junk - writing simple, unfancy, DRY code drops the need for unit tests to almost zero. Using long, but meaningful identifiers drop the need for inline documentation. I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! There are way too many coders today and very few engineers!
    - onion2k 11y ago
      I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! I don't really understand this point. UnitTest and SUnit, that all subsequent unit testing frameworks are based on, were released in about 1990. "Extreme Programming" was a big thing in the mid-90s and that featured test frameworks as a core component. Automated testing isn't new. There are plenty of old books that advocate exactly the "new and trendy" processes you decry. If your argument is "Write code like engineers did 20+ years ago!", then that includes automated testing. I strongly suspect that we're not actually that far apart in our thinking. I don't believe that unit tests magically make your code better. You can't develop a solution to a problem you don't fully understand by throwing more and more tests at it. Developers still need to take the time to think. I believe a lot of my enthusiasm for testing comes from the belief (...experience...) that there are plenty of developers out there who, as you put it it, are coders rather than engineers. My tests pick up their mistakes (and mine, because sometimes I'm not at my best). Maybe, if you're very fortunate, you've managed to surround yourself with a team who are all really good engineers who genuinely don't need to test things because they're rigorous to the point of infallibility. I haven't, and I work in an industry that means I probably never will, so tests are necessary. Advocating testing is much, much more productive, and will lead to better software in the long run, than advocating developers write better code.
nikolay 11y ago
Oh, I forgot to mention the ever-shrinking attention span. Our lives become fuller and fuller of distractions and interruptions. With the increasing load of notifications, alerts, and news feed updates, we can't really concentrate and grasp hard concepts. And we, the people involved in startups and being behind these distractions, are eating our own dogfood and suffering from the same evil.