[HN Gopher] Do something different for a week
___________________________________________________________________
Do something different for a week
Author : sidebits
Score : 80 points
Date : 2021-11-13 11:48 UTC (1 days ago)
(HTM) web link (blog.sidebits.tech)
(TXT) w3m dump (blog.sidebits.tech)
| uwagar wrote:
| how about do nothing. u are perfect already!
| Cicero22 wrote:
| > Avoid the debugger.
|
| People who don't use the debugger, do you generally have
| more/better logging? What other advantages would there be to not
| using a debugger. Perhaps simpler code, so that you don't need to
| use a debugger to debug?
| MarkSweep wrote:
| To motivate why learning how to solve problems without a
| debugger is a useful skill, there are times when using a
| debugger is not feasible.
|
| Sometimes you might simply mot have a debugger. I had an old
| WinCE 6 system whose debugger I never got working. An even
| older 80186 system with a custom RTOS. I have no idea how you
| would debug that. (The 286 added some pins for in-circuit
| emulation, so I'm guessing such a system would be easier to
| build a debugger for)
|
| Sometimes having a debugger attached slows down the system so
| much it is no longer functional. Specifically hooking a
| debugger to HHVM seems to slow down execution by quite a bit.
|
| If you are debugging a real time motion control, you get one
| shot per move to capture what is going on. This is because your
| motor control software stops executing while the debugger is
| pause by the physical motor is still moving. So when you resume
| execution your physical motor is not where it should be and
| your controller either tries to compensate or error out.
|
| Sometimes the act of attaching a debugger prevents the problem
| from occurring. For example it can change the interleaving of
| multiple threads of execution and cause your race condition to
| go away. Or on some microcontrollers if your debugger reads a
| hardware register it can cause the value of the register to
| change.
|
| Sometimes your debugger can cause the problem to happen more
| reliably. I had an intermittent corruption in a floating point
| calculation. Stepping through with the debugger made it 100%
| reproducible, as the data-corrupting interior handler had
| plenty of time to run while single-stepping the main thread.
| drran wrote:
| After a while, your code will be easier to reason about, you
| will learn how to use asserts and proper logs, and you will
| write much better error messages. Why I need to launch a
| debugger, when I can detect an error condition with assert and
| put relevant information into the error message?
| mdoms wrote:
| I try to avoid the debugger. I know what my code is doing
| because I have unit tests and yeah I'd like to think simpler
| code. If my code is doing something unexpected I try to
| reproduce the issue with more unit tests. Sometimes the
| debugger is unavoidable, especially if a third party dependency
| is doing something weird.
| _benj wrote:
| > Implement twice; pick the better version.
|
| This! I like most of the ideas and it sounds like a fun exercise
| to try a few for 1-2 weeks, but I think that implementing
| something twice could yield so much value!
|
| In my role I prioritize code maintenance, probably because I hate
| work with painful codebases, probably because I've seen 5
| years+millions of dollar projects fail as the tech debt piles up
| and the codebase grows too fragile to implement new features
| needed to go to market, probably because I'm lazy and don't like
| to read much to know what the code is doing.
|
| But one of the best architectures I've ever built was one that I
| had to implement 3 times. Now, this wasn't because of my vast
| wisdom but because I literally coded myself in a corner the first
| two! (Go rigidity around circular dependencies is a double edged
| sword)
| burke wrote:
| I'll frequently do this when I start large refactors or
| implementations. I'll build a big ugly branch that kind of
| works, then, when I have a better idea of where I'm headed,
| start from master again, building a chain of sometimes a dozen
| or more PRs, mostly from scratch, that build to the same point
| as that big ugly branch. Along the way, the code and
| architecture tend to improve dramatically.
| MontagFTB wrote:
| I've followed a similar pattern before in large features as
| well. During each iteration my mental model improves
| dramatically, and I have no qualms about deleting everything
| and starting over, because I _know_ the next iteration will
| be that much more correct, performant, and/or maintainable.
| leetrout wrote:
| Mythical Man Month: Build one to throw away
|
| https://wiki.c2.com/?PlanToThrowOneAway or for iphone users
| https://archive.md/zdfXh (no idea why they are blocking iphone)
|
| Quotes about Joe Armstrong say he solved the same problem in
| multiple iterations to refine the solution.
|
| Some of his opinions:
| https://joearms.github.io/published/2014-02-07-why-programmi...
| bt1a wrote:
| > Pretend to be streaming. Talk while you program as if you were
| doing recording a screencast for other people.
|
| So, no different than from when I am actually streaming?
| realitysballs wrote:
| I find I take some of these meta-approaches in my own code work
| but it's a nice article to spell them out so explicitly.
| leetrout wrote:
| I almost have to always draw everything before building it.
|
| I sort out thoughts, see relationships and plan naming and params
| ahead of time.
| agumonkey wrote:
| same.. my first reflex is to dig for a pencil and a piece of
| paper.. i tried other ways but my brain is stuck on this.
| shoto_io wrote:
| I think this it's generally a good idea to try these "anti-
| patterns". Doing things very differently for a short amount of
| time might work miraculously. (and of course it might not work at
| all...)
| nuclearnice1 wrote:
| How do you manage consistency with these experiments?
|
| If I do 5 of these micro experiments in a year, do I have 10
| weeks of code that idiomatically doesn't match the rest of the
| codebase?
| pseudoramble wrote:
| They do mention that it probably should not be applied to
| production code bases. I imagine it's intended to avoid that
| situation.
|
| > Some of these should probably not be tried for the first time
| in a professional context where you work with other people in
| the same code repository, while others can. Use your judgment.
|
| I could see the testing example still being of use in a prod
| code base though. If you find a useful technique and make
| useful tests, you can keep them. If they're not, remove them at
| the end of the experiment.
| mslate wrote:
| Reminds me of this great tweet from @AlmightyGod:
|
| > EXPERIMENT: If you prayed to a god last week, try praying to a
| different one this week and see if you notice a difference
|
| https://twitter.com/almightygod/status/1452430762347843586
| psyc wrote:
| It reminds me a little of Brian Eno's Oblique Strategies, just
| a bit more concrete.
| timdaub wrote:
| For a while, I embraced entering extra randomness in my life.
| Actually it has nothing to do with the programming methods
| described in the article but goes along the same category of
| reasoning.
|
| I ended up subscribing to a bunch of random calls on
| https://dialup.com/ and had some pretty amazing conversations.
| 32gbsd wrote:
| Sounds like this guy just needs to finish what he is doing and
| stop. instead of devising new ways to dick around inside the
| sandbox.
___________________________________________________________________
(page generated 2021-11-14 23:01 UTC)