9 ms·

My bag of tricks – loose notes, design patterns, rules-of-thumb

412 points by necrodome 8y ago

AllegedAlec 8y ago
> Not Rocket Science Rule I've been trying to introduce this into my current company for as long as I've been working there, with no success so far, with varying reasons: - Unit tests for existing projects often fail - Unit tests for existing projects take several minutes to run - Our current build process cannot be automated. Quite frustrating, especially since I've seen a lot of cases where it could've saved us from near-disasters. EDIT: I think on the subject of Emergence, the writer has missed one key point: emergence requires interplay between different levels of the system.
- LandR 8y ago
  > Unit tests for existing projects often fail - Unit tests for existing projects take several minutes to run - Our current build process cannot be automated. Same here. Except we have no almost no unit tests because 1) Most of the devs don't know how to write unit tests 2) Most of the devs don't know hot to write code that is testable, even if they could write the actual unit tests. About a year or so ago we had a project that got a few unit tests added to it, within days they were broken nad failing. The dev just added a [TestCategory("Blah")] and excluded them from being run...
  - AllegedAlec 8y ago
    > Except we have no almost no unit tests because > 1) Most of the devs don't know how to write unit tests > 2) Most of the devs don't know hot to write code that is testable, even if they could write the actual unit tests. Sounds really familiar... I'd like to add the following one: > 3) Cannot make the distinction between code that needs unit testsand code that does not need unit tests
    - fatoons21 8y ago
      I'm new to development, would you recommend any resource out there that covers points 1) 2) and 3)? Thanks
      - AllegedAlec 8y ago
        To be fair: much of it it practice and prior knowledge. I personally found the book Pragmatic Unit Testing helpful, as well as the Clean Code chapter on unit tests. Others may be more able to find you more readily available sources.
      - TeMPOraL 8y ago
        I'm old to development, and would like to ask for the same thing. But something beyond "Pragmatic Unit Testing". You see, I've read that. I've read one other book on unit tests too, and been on 2-day long training in TDD, and spent many hours trying to write unit tests, and yet the skill still eludes me. It's like I have a blind spot there, because I can't for the best of me figure out how to test most of the code I write. In the projects I'm working on, I find roughly 10% of the code to be unit-testable even in principle. That's the core logic, the tricky parts - like the clever pathfinding algorithm I wrote for routing arrows in diagrams, or the clever code that diffs configurations to output an executable changeset (add this, delete that, move this there...). This I usually write functional-style (regardless of language), I expect specific inputs and outputs, so I can test such code effectively. Beyond that, I can also test some trivial utilities (usually also written in functional style). But the remaining 80-90% of any program I work on turns out to be a combination of: - code already tested by someone else - external dependencies - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people I'm having trouble even imagining how to unit-test the three things above, and it's not something covered in unit testing books, tutorials or courses I've seen - they all focus on the basics, like assertions and red-green-refactor, which are the dumb part of writing test. I'm looking for something for the difficult part - how to test the three categories of code I mentioned above.
    - frobozz 8y ago
      I'd like to add: 4) Don't know how to mock effectively I've seen three flavours of this one: - tests that take forever because they don't mock a slow external process that gets called 100s of times in the suite. - tests that randomly break because someone left a file in /tmp/ or some other lack-of-isolation mystery. - tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested.
      - polygotdomain 8y ago
        >tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested. Can you expand on this a bit? I've always worked under the impression that tests should be focused on testing a narrow slice of code. So if my SUT has some dependencies, those will be mocked with the expected result from the dependency, and possibly even with the expected parameters in the arguments. The asserts will check the result from the SUT, but also that the expected method on the mock was called. This way, I'm just testing the code for the SUT, nothing more.
        merlincorey 8y ago
        I'm not the GP in question, but I have worked on code that I think fits this phrasing. In that project's case, 99% of tests were mocks where the only thing being tested was whether or not the mocked function got called the expected number of times or with expected arguments. So the many thousands of tests ran very quickly, and over 90% of the code was covered by tests; however, nothing was actually being functionally tested in those cases. In other words, the tests ran like shit off a shiny shovel.
        frobozz 8y ago
        Yes. This. What then happens is that the mocked out functions change what they return, or the order of what they do inside (e.g so that for a given set of inputs now throws a different exception). Someone forgets to update the mocks. All the tests continue to pass, even though none of the conditions are actually possible in the program.
  - BeetleB 8y ago
    Depending on the language: Unit testing is easy for beginners. Unit testing done well is much less so. This results in many inexperienced people writing poor unit tests. In my last job, I worked on a legacy C++ code base. 500K lines of thorough testing, but none was a unit test. It took 10 hours to run the full test suite. I set about the task of converting portions for unit testability. I was surprised how much of a challenge it was (and I learned a lot). There were few resources on proper unit testing in C++. Mostly learned from Stack Overflow. Lessons learned: 1. If your code did not have unit tests, then likely your code will need a lot of rearchitecting just to enable a single unit test. The good news is that the rearchitecting made the code better. As a corollary: You'll never know how much coupling there is in your code until you write unit tests for it. Our code looked fairly good, but when I wanted to test one part, I found too many dependencies I needed to bring in just to test it. In the end, to test one part, I was involving code from all over the code base. Not good. Most of my effort was writing interface classes to separate the parts so that I could unit test them. 2. For C++, this means your code will look very enterprisey. For once, this was a good thing. 3. Mocking is an art. There's no ideal rule/guideline for it. Overmock and you are just encoding bugs into your tests. Undermock and you are testing too many things at once. 4. For the love of God, don't do a 1:1 mapping between functions/methods and tests. It's OK if your test involves more than one method. Even Robert Martin (Uncle Bob) says so. I know I go against much dogma, but make your unit tests test features, not functions. 5. If your unit tests keep breaking due to trivial refactors, then architect your unit tests to be less sensitive to refactors. 6. For classes, don't test private methods directly. Test them through your public interface. If you cannot reach some code in a private method via the public interface, throw the code away! 7. Perhaps the most important: Assume a hostile management (which is what I had). For every code change you make so that you can write a unit test, can you justify that code change assuming your project never will have unit tests? There are multiple ways to write unit tests - many of them are bad. This guideline will keep you from taking convenient shortcuts. This advice is all about unit tests, and not TDD. With TDD, it is not hard to test yourself into a corner where you then throw everything away and restart. If you insist on TDD, then at least follow Uncle Bob's heuristic. For your function/feature, think of the most complicated result/boundary input, and make that your first unit test. This way you're less likely to develop the function into the wrong corner. When I completed my proof of work, the team rejected it. The feedback was it required too much skill for some of the people in the team (40+ developers across 4 sites), and the likelihood that all of them will get it was miniscule. And too much of the code would need to change to add unit tests. I later read this book: https://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890 https://www.amazon.com/Art-Unit-Testing-examples/dp/16172908... And it contains quite a bit of what I learned from unit testing.
- Cthulhu_ 8y ago
  Well that they fail and that they take minutes to run isn't a bad thing; what is bad is that broken things end up on master. Think of it this way: Any time the build is broken, everyone working on the project is interrupted. If you have 10 people working on the codebase and the build is broken for an hour, that's a whole workday and then some wasted. You could start a grassroots movement - create a pre-push or pre-commit hook that runs tests before it ends up on the remote. Don't worry about the tests taking minutes to run, if you're waiting on that several times a day you're probably publishing too many small changes over the course of a day.
  - AllegedAlec 8y ago
    > Well that they fail and that they take minutes to run isn't a bad thing; what is bad is that broken things end up on master. You don't understand; they are continually broken on master. Furthermore, you assume that we only commit to master after reviews etc have been done. This isn't the case. Commits, even intermittent commits, are pushed to master, and reviewed from there.
    - pc86 8y ago
      > Commits, even intermittent commits, are pushed to master, and reviewed from there. I think most people would agree that's an objectively wrong way to do it.
      - AllegedAlec 8y ago
        Agreed. I've been saying for a long time we should do it differently, but so far I've had no success.
        sopooneo 8y ago
        You have to make the people love you. Then they will follow your good advice joyfully. In fact they'll follow your bad advice just as much, so be careful you don't get promoted to VP.
- pc86 8y ago
  It's an important distinction between "our current build process cannot be automated" and "our current build process is needlessly complicated and thus the ROI from automating it is questionable." You can do a lot of things between bash scripts, PowerShell, etc. Even custom executables.
- da02 8y ago
  What is the environment like? C? Assembly? Windows or Unix?
  - AllegedAlec 8y ago
    c#
- chacham15 8y ago
  I'm a big believer in unit tests, but to be fair, this rule isnt quite accurate. Suppose I write a test as follows: Assert(rand() % 2 == 0); When the test gets run the first time, it can pass and the code can be admitted, but when the next person goes to add code, it can fail. At this point, you've broken your defining principle: that all the code in the test base is correct. The answer of what to do here isnt clear as its a tradeoff in time spent fixing the tests (or potentially the test framework) and developing features. If you have deadlines this becomes more tenuous. Then you figure out that the reason the test is flaky is because it isnt being run in a real environment...etc. All I'm saying is that it isnt as simple as this "Rule" would like to have you believe.
icc97 8y ago
Ma [0] was also referenced by Alan Kay when talking about smalltalk messages [1]: > The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". [0]: http://gordonbrander.com/pattern/ma/ http://gordonbrander.com/pattern/ma/ [1]: http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging
chrisweekly 8y ago
+1 for an awesome personal site. Thanks for sharing! Keep it up! :)
brennebeck 8y ago
This is an awesome archive. Definitely bookmarking and sharing. Thank you.
- emmanueloga_ 8y ago
  ...you missed "and never getting back to it again" :-p I suspect the main value of this particular list was actually producing the list, and mainly for the author's sake. The presentation is actually pretty, and I'm glad people share their favorite learning/knowledge resources. But I guess I'm coming mainly from my frustration of finding so many things interesting but so hard to choose what to focus my attention on.
  - brennebeck 8y ago
    Maybe, actually. But I’ll definitely share with others I’m mentoring or training while doing such. And I think I will also finally put the time in collating my version. Thanks (for indirectly inspiring me, heh).
  - brennebeck 8y ago
    And yes my queue is long and intended as well. So I can relate to having “too much interesting”.
megamindbrian2 8y ago
https://en.m.wikipedia.org/wiki/Rule_of_thumb https://en.m.wikipedia.org/wiki/Rule_of_thumb
pure-awesome 8y ago
Thanks for this. I've thought of making my own blog (or at least part of it) in a similar style. (I've got the blog and the domain set up, I just need to start adding content).
- xaedes 8y ago
  Just add one single item now.
  - extragood 8y ago
    Excellent general life advice
Rainymood 8y ago
>http://gordonbrander.com/pattern/start-with-a-toy/ http://gordonbrander.com/pattern/start-with-a-toy/ This post reminds me of some PG essay I once read (too lazy to look it up). Did you use the PG essay as reference material? Because if yes it might be nice to put some links that served as inspiration for the article?
- VladimirGolovin 8y ago
  I remember reading a book about game design (can't remember the title) that viewed game design through the concept of 'lenses'. One of the lenses was "first make a toy, then make a game around it". For example, a ball is a toy, and football, basketball and volleyball are games.
  - meheleventyone 8y ago
    Yeah the book is The Art of Game Design: A Book of Lenses by Jesse Schell. It seems likely this principle was inspired by the book, the author recommends it on a different page. It’s a good book which would also be great as a set of prompt cards IDEO style. Edit: On a whim I googled and it does exist as a card deck as well!
    - napsterbr 8y ago
      As long as we are here: that book by Jesse Schell is wonderful, I highly recommend it!
- lioeters 8y ago
  Possibly related: Why Toys - https://blog.ycombinator.com/why-toys/ https://blog.ycombinator.com/why-toys/ The Next Big Thing Will Start Out Looking Like a Toy - http://cdixon.org/2010/01/03/the-next-big-thing-will-start-out-looking-like-a-toy/ http://cdixon.org/2010/01/03/the-next-big-thing-will-start-o...
conatus 8y ago
This is very cool.
csbartus 8y ago
And this is mine: https://morethemes.baby/archives/ https://morethemes.baby/archives/
- spicytunacone 8y ago
  Lovely design. The first time in a very long time I was just clicking around just to see what would happen. Captures the playfulness of the old web, but still modern enough. Works especially great on my rotated monitor whereas the sidebar background becomes increasingly straining on wider displays.
  - csbartus 8y ago
    Thanks :) That’s the idea ... bring back the joy of blogging and meantime capture and grow knowledge.
mrob 8y ago
Any single page version? As discussed here recently, "Skim reading is the new normal"[0], and this version with lots of tiny pages is impossible to skim. [0] https://news.ycombinator.com/item?id=17841431 https://news.ycombinator.com/item?id=17841431
- dang 8y ago
  We usually moderate pages that are just lists of things, because they're rarely as interesting as the best single item on the list. But I made an exception because this one seemed unusual.
  - mcqueenjordan 8y ago
    Good judgment. I'm really glad I read this today.
epage 8y ago
I'm regretting I didn't collect my thoughts like this earlier in my career. I personally learned and internalized many principles but by the time I was tech leading and mentoring, they had all fallen to the level of intuition and I couldn't clearly explain the "why"s of things.
- nextos 8y ago
  That's a personal wiki. I think it's invaluable, and since I started building mine with org-mode I feel much more accomplished. That's because some tasks' natural outcome is a knowledge bit, which you can't store otherwise. In the old times, many Germanic scholars would build a similar thing using flashcards. It was called a zettelkasten.
  - fredsir 8y ago
    How are you using org-mode for this? I have recently switched all my note-taking and task/todo management to org-mode, but I'm still figuring out how to use it properly. At the moment, I just have a personal.org, refile.org and project specific .org files, all kinda taking the shape of headings with sub-sub-sub-sub-headings inside until there is either none or some content inside, but a personal wiki, it doesn't feel like. It feels more like ordered mess, kinda. It's definitely better than anything I've ever used before. Any good tips you want to share?
    - nextos 8y ago
      That's not an easy question. I think you need to enforce some style guide, like Wikipedia does. org-mode is a bit like C++ or LaTeX. I say this as a good thing. It has tons of features, but you need to choose what to use and what to keep out. For me, something that works great is to keep all org files in the same folder, with a flat structure. That includes my task list and my calendar. I version control everything, except organizational things that change often instead of growing like articles. I also keep out of version control first quick drafts of any article.
      - 8y ago
LrnByTeach 8y ago
Thank you for sharing this wonderful personal notes. I have been thinking to make one for my notes, now I got extra motivation ..
wgx 8y ago
I’ve spent the last year extracting all these kind of learnings (with a UX bias) out of my brain for a book I’ve written. I wish I’d kept notes as I went along like this person. Great stuff.
apo 8y ago
Every game with more than one player becomes a game about the interactions between those players. Bill Kerr once said that point of view is worth 80 IQ points. I think the above statement is a good example. It's simple enough to seem too trivial to write down. Yet years of work and failure could stand behind it. All too easy for beginners to ignore and trace the same frustrating path.
cake_42 8y ago
here's a general rule of thumb: a man whose backlog of books isn't as least 2x as long as the books read is either (logical or here) a) consistently reading intellectually shallow or uninteresting things b) not really learning anything from what is being read.
icc97 8y ago
I'm reading through Douglas Engelbart's 'Augmenting Human Intellect' at the moment. He talks about getting his thoughts down to a similar level, so that each one is a small note or thought which can be linked together. This seems similar to what has been implemented on this site. He talks a lot about 'trails' the people create, so I think the idea is that you'd be able to take this set of notes and links and integrate it with your own set.

412 points by necrodome 8y ago

> Not Rocket Science Rule I've been trying to introduce this into my current company for as long as I've been working there, with no success so far, with varying reasons: - Unit tests for existing projects often fail - Unit tests for existing projects take several minutes to run - Our current build process cannot be automated. Quite frustrating, especially since I've seen a lot of cases where it could've saved us from near-disasters. EDIT: I think on the subject of Emergence, the writer has missed one key point: emergence requires interplay between different levels of the system.

LandR 8y ago
> Unit tests for existing projects often fail - Unit tests for existing projects take several minutes to run - Our current build process cannot be automated. Same here. Except we have no almost no unit tests because 1) Most of the devs don't know how to write unit tests 2) Most of the devs don't know hot to write code that is testable, even if they could write the actual unit tests. About a year or so ago we had a project that got a few unit tests added to it, within days they were broken nad failing. The dev just added a [TestCategory("Blah")] and excluded them from being run...
- AllegedAlec 8y ago
  > Except we have no almost no unit tests because > 1) Most of the devs don't know how to write unit tests > 2) Most of the devs don't know hot to write code that is testable, even if they could write the actual unit tests. Sounds really familiar... I'd like to add the following one: > 3) Cannot make the distinction between code that needs unit testsand code that does not need unit tests
  - fatoons21 8y ago
    I'm new to development, would you recommend any resource out there that covers points 1) 2) and 3)? Thanks
    - AllegedAlec 8y ago
      To be fair: much of it it practice and prior knowledge. I personally found the book Pragmatic Unit Testing helpful, as well as the Clean Code chapter on unit tests. Others may be more able to find you more readily available sources.
    - TeMPOraL 8y ago
      I'm old to development, and would like to ask for the same thing. But something beyond "Pragmatic Unit Testing". You see, I've read that. I've read one other book on unit tests too, and been on 2-day long training in TDD, and spent many hours trying to write unit tests, and yet the skill still eludes me. It's like I have a blind spot there, because I can't for the best of me figure out how to test most of the code I write. In the projects I'm working on, I find roughly 10% of the code to be unit-testable even in principle. That's the core logic, the tricky parts - like the clever pathfinding algorithm I wrote for routing arrows in diagrams, or the clever code that diffs configurations to output an executable changeset (add this, delete that, move this there...). This I usually write functional-style (regardless of language), I expect specific inputs and outputs, so I can test such code effectively. Beyond that, I can also test some trivial utilities (usually also written in functional style). But the remaining 80-90% of any program I work on turns out to be a combination of: - code already tested by someone else - external dependencies - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people I'm having trouble even imagining how to unit-test the three things above, and it's not something covered in unit testing books, tutorials or courses I've seen - they all focus on the basics, like assertions and red-green-refactor, which are the dumb part of writing test. I'm looking for something for the difficult part - how to test the three categories of code I mentioned above.
  - frobozz 8y ago
    I'd like to add: 4) Don't know how to mock effectively I've seen three flavours of this one: - tests that take forever because they don't mock a slow external process that gets called 100s of times in the suite. - tests that randomly break because someone left a file in /tmp/ or some other lack-of-isolation mystery. - tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested.
    - polygotdomain 8y ago
      >tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested. Can you expand on this a bit? I've always worked under the impression that tests should be focused on testing a narrow slice of code. So if my SUT has some dependencies, those will be mocked with the expected result from the dependency, and possibly even with the expected parameters in the arguments. The asserts will check the result from the SUT, but also that the expected method on the mock was called. This way, I'm just testing the code for the SUT, nothing more.
      - merlincorey 8y ago
        I'm not the GP in question, but I have worked on code that I think fits this phrasing. In that project's case, 99% of tests were mocks where the only thing being tested was whether or not the mocked function got called the expected number of times or with expected arguments. So the many thousands of tests ran very quickly, and over 90% of the code was covered by tests; however, nothing was actually being functionally tested in those cases. In other words, the tests ran like shit off a shiny shovel.
        frobozz 8y ago
        Yes. This. What then happens is that the mocked out functions change what they return, or the order of what they do inside (e.g so that for a given set of inputs now throws a different exception). Someone forgets to update the mocks. All the tests continue to pass, even though none of the conditions are actually possible in the program.
- BeetleB 8y ago
  Depending on the language: Unit testing is easy for beginners. Unit testing done well is much less so. This results in many inexperienced people writing poor unit tests. In my last job, I worked on a legacy C++ code base. 500K lines of thorough testing, but none was a unit test. It took 10 hours to run the full test suite. I set about the task of converting portions for unit testability. I was surprised how much of a challenge it was (and I learned a lot). There were few resources on proper unit testing in C++. Mostly learned from Stack Overflow. Lessons learned: 1. If your code did not have unit tests, then likely your code will need a lot of rearchitecting just to enable a single unit test. The good news is that the rearchitecting made the code better. As a corollary: You'll never know how much coupling there is in your code until you write unit tests for it. Our code looked fairly good, but when I wanted to test one part, I found too many dependencies I needed to bring in just to test it. In the end, to test one part, I was involving code from all over the code base. Not good. Most of my effort was writing interface classes to separate the parts so that I could unit test them. 2. For C++, this means your code will look very enterprisey. For once, this was a good thing. 3. Mocking is an art. There's no ideal rule/guideline for it. Overmock and you are just encoding bugs into your tests. Undermock and you are testing too many things at once. 4. For the love of God, don't do a 1:1 mapping between functions/methods and tests. It's OK if your test involves more than one method. Even Robert Martin (Uncle Bob) says so. I know I go against much dogma, but make your unit tests test features, not functions. 5. If your unit tests keep breaking due to trivial refactors, then architect your unit tests to be less sensitive to refactors. 6. For classes, don't test private methods directly. Test them through your public interface. If you cannot reach some code in a private method via the public interface, throw the code away! 7. Perhaps the most important: Assume a hostile management (which is what I had). For every code change you make so that you can write a unit test, can you justify that code change assuming your project never will have unit tests? There are multiple ways to write unit tests - many of them are bad. This guideline will keep you from taking convenient shortcuts. This advice is all about unit tests, and not TDD. With TDD, it is not hard to test yourself into a corner where you then throw everything away and restart. If you insist on TDD, then at least follow Uncle Bob's heuristic. For your function/feature, think of the most complicated result/boundary input, and make that your first unit test. This way you're less likely to develop the function into the wrong corner. When I completed my proof of work, the team rejected it. The feedback was it required too much skill for some of the people in the team (40+ developers across 4 sites), and the likelihood that all of them will get it was miniscule. And too much of the code would need to change to add unit tests. I later read this book: https://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890 https://www.amazon.com/Art-Unit-Testing-examples/dp/16172908... And it contains quite a bit of what I learned from unit testing.
Cthulhu_ 8y ago
Well that they fail and that they take minutes to run isn't a bad thing; what is bad is that broken things end up on master. Think of it this way: Any time the build is broken, everyone working on the project is interrupted. If you have 10 people working on the codebase and the build is broken for an hour, that's a whole workday and then some wasted. You could start a grassroots movement - create a pre-push or pre-commit hook that runs tests before it ends up on the remote. Don't worry about the tests taking minutes to run, if you're waiting on that several times a day you're probably publishing too many small changes over the course of a day.
- AllegedAlec 8y ago
  > Well that they fail and that they take minutes to run isn't a bad thing; what is bad is that broken things end up on master. You don't understand; they are continually broken on master. Furthermore, you assume that we only commit to master after reviews etc have been done. This isn't the case. Commits, even intermittent commits, are pushed to master, and reviewed from there.
  - pc86 8y ago
    > Commits, even intermittent commits, are pushed to master, and reviewed from there. I think most people would agree that's an objectively wrong way to do it.
    - AllegedAlec 8y ago
      Agreed. I've been saying for a long time we should do it differently, but so far I've had no success.
      - sopooneo 8y ago
        You have to make the people love you. Then they will follow your good advice joyfully. In fact they'll follow your bad advice just as much, so be careful you don't get promoted to VP.
pc86 8y ago
It's an important distinction between "our current build process cannot be automated" and "our current build process is needlessly complicated and thus the ROI from automating it is questionable." You can do a lot of things between bash scripts, PowerShell, etc. Even custom executables.
da02 8y ago
What is the environment like? C? Assembly? Windows or Unix?
- AllegedAlec 8y ago
  c#
chacham15 8y ago
I'm a big believer in unit tests, but to be fair, this rule isnt quite accurate. Suppose I write a test as follows: Assert(rand() % 2 == 0); When the test gets run the first time, it can pass and the code can be admitted, but when the next person goes to add code, it can fail. At this point, you've broken your defining principle: that all the code in the test base is correct. The answer of what to do here isnt clear as its a tradeoff in time spent fixing the tests (or potentially the test framework) and developing features. If you have deadlines this becomes more tenuous. Then you figure out that the reason the test is flaky is because it isnt being run in a real environment...etc. All I'm saying is that it isnt as simple as this "Rule" would like to have you believe.

icc97 8y ago

Ma [0] was also referenced by Alan Kay when talking about smalltalk messages [1]: > The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". [0]: http://gordonbrander.com/pattern/ma/ http://gordonbrander.com/pattern/ma/ [1]: http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging

chrisweekly 8y ago

+1 for an awesome personal site. Thanks for sharing! Keep it up! :)

brennebeck 8y ago

This is an awesome archive. Definitely bookmarking and sharing. Thank you.

emmanueloga_ 8y ago
...you missed "and never getting back to it again" :-p I suspect the main value of this particular list was actually producing the list, and mainly for the author's sake. The presentation is actually pretty, and I'm glad people share their favorite learning/knowledge resources. But I guess I'm coming mainly from my frustration of finding so many things interesting but so hard to choose what to focus my attention on.
- brennebeck 8y ago
  Maybe, actually. But I’ll definitely share with others I’m mentoring or training while doing such. And I think I will also finally put the time in collating my version. Thanks (for indirectly inspiring me, heh).
- brennebeck 8y ago
  And yes my queue is long and intended as well. So I can relate to having “too much interesting”.

megamindbrian2 8y ago

https://en.m.wikipedia.org/wiki/Rule_of_thumb https://en.m.wikipedia.org/wiki/Rule_of_thumb

pure-awesome 8y ago

Thanks for this. I've thought of making my own blog (or at least part of it) in a similar style. (I've got the blog and the domain set up, I just need to start adding content).

xaedes 8y ago
Just add one single item now.
- extragood 8y ago
  Excellent general life advice

Rainymood 8y ago

>http://gordonbrander.com/pattern/start-with-a-toy/ http://gordonbrander.com/pattern/start-with-a-toy/ This post reminds me of some PG essay I once read (too lazy to look it up). Did you use the PG essay as reference material? Because if yes it might be nice to put some links that served as inspiration for the article?

VladimirGolovin 8y ago
I remember reading a book about game design (can't remember the title) that viewed game design through the concept of 'lenses'. One of the lenses was "first make a toy, then make a game around it". For example, a ball is a toy, and football, basketball and volleyball are games.
- meheleventyone 8y ago
  Yeah the book is The Art of Game Design: A Book of Lenses by Jesse Schell. It seems likely this principle was inspired by the book, the author recommends it on a different page. It’s a good book which would also be great as a set of prompt cards IDEO style. Edit: On a whim I googled and it does exist as a card deck as well!
  - napsterbr 8y ago
    As long as we are here: that book by Jesse Schell is wonderful, I highly recommend it!
lioeters 8y ago
Possibly related: Why Toys - https://blog.ycombinator.com/why-toys/ https://blog.ycombinator.com/why-toys/ The Next Big Thing Will Start Out Looking Like a Toy - http://cdixon.org/2010/01/03/the-next-big-thing-will-start-out-looking-like-a-toy/ http://cdixon.org/2010/01/03/the-next-big-thing-will-start-o...

conatus 8y ago

This is very cool.

csbartus 8y ago

And this is mine: https://morethemes.baby/archives/ https://morethemes.baby/archives/

spicytunacone 8y ago
Lovely design. The first time in a very long time I was just clicking around just to see what would happen. Captures the playfulness of the old web, but still modern enough. Works especially great on my rotated monitor whereas the sidebar background becomes increasingly straining on wider displays.
- csbartus 8y ago
  Thanks :) That’s the idea ... bring back the joy of blogging and meantime capture and grow knowledge.

mrob 8y ago

Any single page version? As discussed here recently, "Skim reading is the new normal"[0], and this version with lots of tiny pages is impossible to skim. [0] https://news.ycombinator.com/item?id=17841431 https://news.ycombinator.com/item?id=17841431

dang 8y ago
We usually moderate pages that are just lists of things, because they're rarely as interesting as the best single item on the list. But I made an exception because this one seemed unusual.
- mcqueenjordan 8y ago
  Good judgment. I'm really glad I read this today.

epage 8y ago

I'm regretting I didn't collect my thoughts like this earlier in my career. I personally learned and internalized many principles but by the time I was tech leading and mentoring, they had all fallen to the level of intuition and I couldn't clearly explain the "why"s of things.

nextos 8y ago
That's a personal wiki. I think it's invaluable, and since I started building mine with org-mode I feel much more accomplished. That's because some tasks' natural outcome is a knowledge bit, which you can't store otherwise. In the old times, many Germanic scholars would build a similar thing using flashcards. It was called a zettelkasten.
- fredsir 8y ago
  How are you using org-mode for this? I have recently switched all my note-taking and task/todo management to org-mode, but I'm still figuring out how to use it properly. At the moment, I just have a personal.org, refile.org and project specific .org files, all kinda taking the shape of headings with sub-sub-sub-sub-headings inside until there is either none or some content inside, but a personal wiki, it doesn't feel like. It feels more like ordered mess, kinda. It's definitely better than anything I've ever used before. Any good tips you want to share?
  - nextos 8y ago
    That's not an easy question. I think you need to enforce some style guide, like Wikipedia does. org-mode is a bit like C++ or LaTeX. I say this as a good thing. It has tons of features, but you need to choose what to use and what to keep out. For me, something that works great is to keep all org files in the same folder, with a flat structure. That includes my task list and my calendar. I version control everything, except organizational things that change often instead of growing like articles. I also keep out of version control first quick drafts of any article.
    - 8y ago

LrnByTeach 8y ago

Thank you for sharing this wonderful personal notes. I have been thinking to make one for my notes, now I got extra motivation ..

wgx 8y ago

I’ve spent the last year extracting all these kind of learnings (with a UX bias) out of my brain for a book I’ve written. I wish I’d kept notes as I went along like this person. Great stuff.

apo 8y ago

Every game with more than one player becomes a game about the interactions between those players. Bill Kerr once said that point of view is worth 80 IQ points. I think the above statement is a good example. It's simple enough to seem too trivial to write down. Yet years of work and failure could stand behind it. All too easy for beginners to ignore and trace the same frustrating path.

cake_42 8y ago

here's a general rule of thumb: a man whose backlog of books isn't as least 2x as long as the books read is either (logical or here) a) consistently reading intellectually shallow or uninteresting things b) not really learning anything from what is being read.

icc97 8y ago

I'm reading through Douglas Engelbart's 'Augmenting Human Intellect' at the moment. He talks about getting his thoughts down to a similar level, so that each one is a small note or thought which can be linked together. This seems similar to what has been implemented on this site. He talks a lot about 'trails' the people create, so I think the idea is that you'd be able to take this set of notes and links and integrate it with your own set.