3 ms·

This is normal to some extent for first few times when you try something new. You can reduce the devtime with the following: If it worked, generalize it a litt

by wruza 4y ago

This is normal to some extent for first few times when you try something new. You can reduce the devtime with the following: If it worked, generalize it a little (in a sense of factoring out constants and special cases) and add to easily-accessible snippets. You created a login form or middleware? A build config? A function that does some generic-y X? A set of useful imports? Great, save it for the next time right into your editor, right now. 99% of code is just that - modified snippets. Let this set grow unbounded and brush it up timely. Think of it as your own battle-tested SO. Making sure what I wrote works, one baby step at a time When you’re developing with logging and restart-on-save, it is a matter of ctrl-s. Sometimes it’s hard to get to the point of failure, e.g. you have to make a couple of requests (or clicks if there is ui) only to get to the point. This has to be reduced. Put a temporary “cut to the chase” code which does that. If it is a server, send these requests to yourself at the start. If it is UI, wait for some selectors to appear and click them programmatically. If it is a function, move it to tmp.<langext> and restart-on-save it there. Disable all tedious signing/cookie/role/etc checks until production. Your goal is a very hot (ctrl-s -> look -> refine) loop. It takes forever to complete and breaks cadence if it contains “blocking calls”. I seriously advise you to not use a debugger unless you’re debugging a complex algorithm or feeling a need to use it. There is no value in stepping over a mostly laminar flow, just print it. They just write pages and pages of code without ever running it Maybe they test later, or rely on a type system, or accumulate edge cases and hard to find bugs, or they mastered these parts and write from memory. Perhaps some combination of it.

systemvoltage 4y ago
Thanks for your take. What do you think of John Carmack's[1] suggestion that using a debugger is the best way to program? I am by no means comparing myself to Carmack :-) I find debugger a good way to "see" what the program is doing. But that leads to a lot of time wasted. [1] https://youtu.be/tzr7hRXcwkw?t=138 https://youtu.be/tzr7hRXcwkw?t=138
- wruza 4y ago
  I think that Carmack is biased towards game development, which is different from request-response or click-action. Extensive game logs would scroll faster than framerate, rendering themselves useless (pun not intended), so stop the world and explore it is. If I had to develop a system with hundreds of parameters changing with time, depending on random() or seconds of continuous input events, then of course I’d use conditional breakpoints and live watches instead of grepping gigabytes of unstable state reports. But also, games have huds, special rendering modes (wireframe, coords, paths prediction, visibility areas to name a few), consoles, so in a sense they have some debug output that either runs at the frame rate or is just text. That said, many developers find debuggers superior to logs in any situation, and if you do so, then use it. My advice is not universal. The key point is to explore development “modes” and choose what’s suits best the “write code faster” goal in your own domain.

by wruza 4y ago

systemvoltage 4y ago

Thanks for your take. What do you think of John Carmack's[1] suggestion that using a debugger is the best way to program? I am by no means comparing myself to Carmack :-) I find debugger a good way to "see" what the program is doing. But that leads to a lot of time wasted. [1] https://youtu.be/tzr7hRXcwkw?t=138 https://youtu.be/tzr7hRXcwkw?t=138

wruza 4y ago
I think that Carmack is biased towards game development, which is different from request-response or click-action. Extensive game logs would scroll faster than framerate, rendering themselves useless (pun not intended), so stop the world and explore it is. If I had to develop a system with hundreds of parameters changing with time, depending on random() or seconds of continuous input events, then of course I’d use conditional breakpoints and live watches instead of grepping gigabytes of unstable state reports. But also, games have huds, special rendering modes (wireframe, coords, paths prediction, visibility areas to name a few), consoles, so in a sense they have some debug output that either runs at the frame rate or is just text. That said, many developers find debuggers superior to logs in any situation, and if you do so, then use it. My advice is not universal. The key point is to explore development “modes” and choose what’s suits best the “write code faster” goal in your own domain.