6 ms·

So one thing I think that gets lost is, to me, the most important quality in code is: how easy is it to debug. Like, I remember once having to maintain this guy

So one thing I think that gets lost is, to me, the most important quality in code is: how easy is it to debug. Like, I remember once having to maintain this guy's code where he just went crazy on C++ templates. And like, he proved that he's very smart and clever, but it made his code practically unusable since nobody could figure it out, and trying to debug a template masterpiece is like the hardest thing in c++ coding because the errors are impenetrable. Coding isn't about proving your smartness it's about making something people can use and work with.

joatmon-snoo 6y ago
Forget about inherent complexity, just having good error messages is hard! I spent hours this week debugging a test that kept failing in EXPECT_EQ(result.status(), SUCCESS) Since this was a codebase I hadn't ever worked in before, I spent quite a while flailing around trying to figure out where I needed to add logging and eventually realized that `result` had more error details that the assertion was hiding from me. I have a similar gripe with Python's unittest: because some of the assertions allow `expected` and `actual` to be interchangeable, there's always some extra mental overhead to remembering which is which. For example, compare this: >>> unittest.TestCase().assertEqual(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.9/unittest/case.py", line 831, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib/python3.9/unittest/case.py", line 824, in _baseAssertEqual raise self.failureException(msg) AssertionError: 1 != 2 with Java's Truth (https://truth.dev https://truth.dev): assertThat(actual).isEqualTo(expected) which results in errors like this: java.lang.AssertionError: expected:<[guava, dagger, truth, auto, caliper]> but was:<[dagger, auto, caliper, guava]> at org.junit.Assert.failNotEquals(Assert.java:835) <2 internal calls> at com.google.common.truth.example.DemoTest.testBuiltin(DemoTest.java:64) <19 internal calls>
- sail0rm00n 6y ago
  If only they had use VERIFY_OK/EXPECT_OK which prints out the error message :( https://chromium.googlesource.com/chromium/src/+/master/net/http2/platform/impl/http2_test_helpers_impl.h#144 https://chromium.googlesource.com/chromium/src/+/master/net/...
superkuh 6y ago
>Coding isn't about proving your smartness it's about making something people can use and work with. No, that's what business is about. Coding isn't just for business.
- overgard 6y ago
  Realistically who is studying your code? Probably nobody unless you made something super famous. Otherwise youre what trying to show off? It's a lot of effort to get people to be: "neat, im confused" (Believe me I say that as a person that's written a lot of "im being clever" things to the delight of nobody)
  - superkuh 6y ago
    Think of it like dancing. To dance with others you have to follow rules or at least communicate a lot. But dancing erratically by yourself is fun too even if no one sees it.
zelphirkalt 6y ago
Actually coding is about both. Proving your smartness _by_ making things people can work with, because they are simple. Creating a C++ template madness is not that smart in the end. Really smart people invest time into making their code very readable and at the same time manage to give it the required layers of abstraction and flexibility in a way that does not confuse the reader. They make their code in a way, that enables them or others to write tests for it. They think about the concepts needed in the project. Find a good trade-off between simplicity and flexibility and if you are a true master of finding good abstractions, manage to choose a simple abstraction to get simplicity and flexibility at the same time. At least that is being smart to me.
- overgard 6y ago
  "Proving" you're smart is a terrible idea, if you're smart it'll come across pretty quick and if it's not obvious to other people the attempt seems pretentious. I don't think you should guard smartness by pretending its the same thing as practicalness. I know a lot of people that spent time on brilliant work that had no point. They were smart as hell just impractical If I'm hiring a coder and I get one that writes the boringist work, or a brilliant person that writes their code as a quine, I respect quine guy but I want boring guy.
  - zelphirkalt 6y ago
    Yes, you raise an interesting point and I am not voting for going out of your way or intentionally trying to "prove" anything. No need for that. Just do good work and try to apply your smartness to find good solutions, keeping the ones coming after you in mind, who will have to deal with the stuff you write today. That might be yourself tomorrow anyway. Practicalness should include smartness, go hand-in-hand with it, and acting in a practical way should include not tripping yourself up in the future with things you do now. A quine might not be the best way to solve a problem without creating a new one. But perhaps it is in some situation. Always depends. I want to raise another point though, which is allowing developers to enjoy their profession as well. Imagine going to a master carpenter and telling them "I just need you to connect 3 plywood boards together." and then the next day you go into their shop and dictate them: "No, no, do not put that much effort into connecting them! It doesn't need to look pretty. Just use some glue, that will make them stick together! No need to be clean about it. Just leave redundant glue on it. It's going to be under the table anyway and no one will see it." That is how many developers are treated and I don't think it is a good thing. Developers need to be given some leeway, some room, to get creative and deliver great solutions. Of course it should be within certain limitations with clear goals set and all that. Just don't suffocate creativity, taking out all joy of the profession and let them be actual developers sometimes. Software development is a truly creative activity. Lets not forget that.
twistedpair 6y ago
This has been going on for over a thousand years. Read Ptolemy's book from the 2nd century to describe the solar system. It used hundreds of "epicycles" to make everything line up. Then Newton comes up with three tiny equations that describe the solar system's motion even better in the 18th century. As they say, "anyone can design a complicated system", but if you're really smart, you can make a simple system. It's no different in programming.

joatmon-snoo 6y ago

Forget about inherent complexity, just having good error messages is hard! I spent hours this week debugging a test that kept failing in EXPECT_EQ(result.status(), SUCCESS) Since this was a codebase I hadn't ever worked in before, I spent quite a while flailing around trying to figure out where I needed to add logging and eventually realized that `result` had more error details that the assertion was hiding from me. I have a similar gripe with Python's unittest: because some of the assertions allow `expected` and `actual` to be interchangeable, there's always some extra mental overhead to remembering which is which. For example, compare this: >>> unittest.TestCase().assertEqual(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.9/unittest/case.py", line 831, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib/python3.9/unittest/case.py", line 824, in _baseAssertEqual raise self.failureException(msg) AssertionError: 1 != 2 with Java's Truth (https://truth.dev https://truth.dev): assertThat(actual).isEqualTo(expected) which results in errors like this: java.lang.AssertionError: expected:<[guava, dagger, truth, auto, caliper]> but was:<[dagger, auto, caliper, guava]> at org.junit.Assert.failNotEquals(Assert.java:835) <2 internal calls> at com.google.common.truth.example.DemoTest.testBuiltin(DemoTest.java:64) <19 internal calls>

sail0rm00n 6y ago
If only they had use VERIFY_OK/EXPECT_OK which prints out the error message :( https://chromium.googlesource.com/chromium/src/+/master/net/http2/platform/impl/http2_test_helpers_impl.h#144 https://chromium.googlesource.com/chromium/src/+/master/net/...

superkuh 6y ago

>Coding isn't about proving your smartness it's about making something people can use and work with. No, that's what business is about. Coding isn't just for business.

overgard 6y ago
Realistically who is studying your code? Probably nobody unless you made something super famous. Otherwise youre what trying to show off? It's a lot of effort to get people to be: "neat, im confused" (Believe me I say that as a person that's written a lot of "im being clever" things to the delight of nobody)
- superkuh 6y ago
  Think of it like dancing. To dance with others you have to follow rules or at least communicate a lot. But dancing erratically by yourself is fun too even if no one sees it.

zelphirkalt 6y ago

Actually coding is about both. Proving your smartness _by_ making things people can work with, because they are simple. Creating a C++ template madness is not that smart in the end. Really smart people invest time into making their code very readable and at the same time manage to give it the required layers of abstraction and flexibility in a way that does not confuse the reader. They make their code in a way, that enables them or others to write tests for it. They think about the concepts needed in the project. Find a good trade-off between simplicity and flexibility and if you are a true master of finding good abstractions, manage to choose a simple abstraction to get simplicity and flexibility at the same time. At least that is being smart to me.

overgard 6y ago
"Proving" you're smart is a terrible idea, if you're smart it'll come across pretty quick and if it's not obvious to other people the attempt seems pretentious. I don't think you should guard smartness by pretending its the same thing as practicalness. I know a lot of people that spent time on brilliant work that had no point. They were smart as hell just impractical If I'm hiring a coder and I get one that writes the boringist work, or a brilliant person that writes their code as a quine, I respect quine guy but I want boring guy.
- zelphirkalt 6y ago
  Yes, you raise an interesting point and I am not voting for going out of your way or intentionally trying to "prove" anything. No need for that. Just do good work and try to apply your smartness to find good solutions, keeping the ones coming after you in mind, who will have to deal with the stuff you write today. That might be yourself tomorrow anyway. Practicalness should include smartness, go hand-in-hand with it, and acting in a practical way should include not tripping yourself up in the future with things you do now. A quine might not be the best way to solve a problem without creating a new one. But perhaps it is in some situation. Always depends. I want to raise another point though, which is allowing developers to enjoy their profession as well. Imagine going to a master carpenter and telling them "I just need you to connect 3 plywood boards together." and then the next day you go into their shop and dictate them: "No, no, do not put that much effort into connecting them! It doesn't need to look pretty. Just use some glue, that will make them stick together! No need to be clean about it. Just leave redundant glue on it. It's going to be under the table anyway and no one will see it." That is how many developers are treated and I don't think it is a good thing. Developers need to be given some leeway, some room, to get creative and deliver great solutions. Of course it should be within certain limitations with clear goals set and all that. Just don't suffocate creativity, taking out all joy of the profession and let them be actual developers sometimes. Software development is a truly creative activity. Lets not forget that.

twistedpair 6y ago

This has been going on for over a thousand years. Read Ptolemy's book from the 2nd century to describe the solar system. It used hundreds of "epicycles" to make everything line up. Then Newton comes up with three tiny equations that describe the solar system's motion even better in the 18th century. As they say, "anyone can design a complicated system", but if you're really smart, you can make a simple system. It's no different in programming.