3 ms·

I started early writing games and utilities on an 8-bit home computer. The best thing was that you did everything yourself, there were no libraries. To make it

I started early writing games and utilities on an 8-bit home computer. The best thing was that you did everything yourself, there were no libraries. To make it faster you sprinkled in some machine/assembly language and interfaced it. The closest modern example might be using "View source" and making your own complete web pages/sites. The benefit of this approach is that you don't get value in micro-optimization of a single function and have to balance effort over the whole. What I do nowadays is lots of code reviews. For my own PRs, I review them myself first with the mindset of someone who starts with near zero context. During development, I'll prototype something that just works (git commit and push to branch), then revise some parts that may have bad expected performance or low coding standards. Difficulties in naming or describing the work in a PR description may mean that you don't understand the problem/solution well or decomposed it in arbitrary rather than meaningfully stable ways. One thing that's not often mentioned is working on old/large/legacy codebases--in particular ones you've written. It really gives you humility and a long-term view of what was actually needed and what didn't age well (YAGNI). This will put you above "good enough" into 'should be good enough for anyone' territory.

sibeliuss 4y ago
> For my own PRs, I review them myself first This is another truly great pro-tip from this thread. It makes a world of difference seeing ones code outside of ones editor and in a different interface, broken up by GitHub's UI. I often write comments to myself as I'm reviewing and then resolve my notes via future commits. Towards the end stages of a lengthy PR I'll often rapidly self-review, push, _re_-self-review, push and then so on. All the way until its totally polished. This process has never done me wrong.
- karmakaze 4y ago
  Yes, that's exactly how it goes. Similar to how right after meeting a deadline and the whole team breathes a sigh of relief. I worked one place that made golden masters for shrink-wrap reproduction. The brilliant person in shipping (as in "shipping and receiving" not specifically software) would secretly hold on to them for a week regardless of how behind schedule and late we were with the release. Almost every time a day or two later, someone would remember something and there would be a panic recall and Leslie would say "no problem" let me know when you have it.

sibeliuss 4y ago

> For my own PRs, I review them myself first This is another truly great pro-tip from this thread. It makes a world of difference seeing ones code outside of ones editor and in a different interface, broken up by GitHub's UI. I often write comments to myself as I'm reviewing and then resolve my notes via future commits. Towards the end stages of a lengthy PR I'll often rapidly self-review, push, _re_-self-review, push and then so on. All the way until its totally polished. This process has never done me wrong.

karmakaze 4y ago
Yes, that's exactly how it goes. Similar to how right after meeting a deadline and the whole team breathes a sigh of relief. I worked one place that made golden masters for shrink-wrap reproduction. The brilliant person in shipping (as in "shipping and receiving" not specifically software) would secretly hold on to them for a week regardless of how behind schedule and late we were with the release. Almost every time a day or two later, someone would remember something and there would be a panic recall and Leslie would say "no problem" let me know when you have it.