31–40 of 52 posts
jwz's response is worth reading as well: https://www.jwz.org/blog/2009/09/that-duct-tape-silliness/ "It's such a strange article, in that it's mostly favorable to my point of view but with such a breathless amazement to it, like he's just discovered an actual unicorn or something. "Look, everybody! Here's a hacker who actually accomplished things and yet he doesn't fetishize the latest fads that I and all of my frien…
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++ codi…
I spent hours this week debugging a test that kept failing in
EXPECT_EQ(result.status(), SUCCESS)
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 "", line 1, in
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
assertThat(actual).isEqualTo(expected)
java.lang.AssertionError: expected: but was:
at org.junit.Assert.failNotEquals(Assert.java:835)
at com.google.common.truth.example.DemoTest.testBuiltin(DemoTest.java:64) 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++ codi…
No, that's what business is about. Coding isn't just for business.
I always liked this quote by Jamie Zawinski, from Coders at Work "I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework…release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor’s six-mo…
Shouldn't that worry you, rather than excite you? He's just saying "worse is faster", not "worse is better". Especially that last sentence is kind of terrifying: "they can rewrite it because you don’t have a job anymore." Basically, everyone who takes the time to write good code will be outcompeted by bad code written quickly, until eventually everything is bad.
What a lot of these conversations boil down to is finding the sweet spot between over/under engineering which is subjective. Are we wasting time solving problems that dont matter or are we shipping with a 'just enough' type of mentality and risk exposing our users to buggy software?
No one likes to work with bad code but if its siloing itself into inconsequential CRUD apps or frivilous games/social media it's just annoying to experience/work with. Its when it creeps into systems or applications where consequences for failure are dire, think Lion Air crash in 2018, that Im worried.
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++ codi…
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.
> xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits I suppose that it's true that if you were coming from the item pointed to by 'prev' you could xor your previous address with the linked list pointer to get the value of 'next'. Is that from an actual implementation? Was anyone crazy enough to actually do that?
It can be done even better. I read an article about that recently. Nowadays pointers are 64-bit. So the simple xoring already saves 64 bits. But, in most cases allocated memory blocks are close together, so that xoring of those 64-bit values gives a 32-bit value. So if you ignore the upper half and store the result in 32-bit, you basically save 96 bits. For the cases where the upper half matters, you can store it in…
The XOR-trick is curious (if weird) because it preserves most* of the properties of the list structure. Traversal is almost identical to that of the original list in machine terms. Maybe an additional cycle on the critical path; probably not the worst thing in pointer chasing code.
* you do need to double the size of your iterator, so if you were needing to stash large numbers of iterators relative to the number of linked list elements, this wouldn't be a particularly nice trick.
jwz's response is worth reading as well: https://www.jwz.org/blog/2009/09/that-duct-tape-silliness/ "It's such a strange article, in that it's mostly favorable to my point of view but with such a breathless amazement to it, like he's just discovered an actual unicorn or something. "Look, everybody! Here's a hacker who actually accomplished things and yet he doesn't fetishize the latest fads that I and all of my frien…
Lol that ddos banner. Hey @jwz, you should look into serverless or something
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++ codi…
>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.
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++ codi…
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…
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 always liked this quote by Jamie Zawinski, from Coders at Work "I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework…release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor’s six-mo…
I know we are not hired "to write code" but "to ship products", and that everything is done in "sprints" and we must be very agile in doing them because they're always non-stop, and quality comes second (unless, of course, you are really skilled and can ship high quality code in half the time it usually takes), and customers first and "we'll polish it in version 2" and...
I guess I feel "guilty" of writing good code just for the sake of writing good code (and taking time for doing so). At work code comes second, product comes first. I accept it and I try my best, but at the end of the day the code I write at my own pace at home for side projects, now that's the code I like to write.