Coding isn't about proving your smartness it's about making something people can use and work with.
Coding isn't about proving your smartness it's about making something people can use and work with.
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.
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.
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.
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): 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>https://chromium.googlesource.com/chromium/src/+/master/net/...
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.
No, that's what business is about. Coding isn't just for business.