> 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?
Do something different for a week
11–20 of 21 posts
Re: Do something different for a week
#12> 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 grow…
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.
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.
Re: Do something different for a week
#13I 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...)
Re: Do something different for a week
#14Reminds 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
Re: Do something different for a week
#15Reminds 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
It reminds me a little of Brian Eno’s Oblique Strategies, just a bit more concrete.
Re: Do something different for a week
#16> 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?
Re: Do something different for a week
#17> 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?
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.
Re: Do something different for a week
#18For 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.
Re: Do something different for a week
#19> 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?
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?
Re: Do something different for a week
#20> 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?
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.