4 ms·

The author is very clever. This was a fascinating read. On the inner loop, and progress being a vector sum: one thing I find crucial is knowing where I have t

The author is very clever. This was a fascinating read. On the inner loop, and progress being a vector sum: one thing I find crucial is knowing where I have to go. That translates to two mantra: rush to the finish line, then rebuild it if needed. When embarking on a project I know roughly what stages are needed. Maybe three dependencies, one more to bring them together, one more to deliver a subsequent result, and one outer one to present the whole code. Example: a web scraper to get weather data, a thermometer polling daemon, a database to store the two, a scheduler to run the first two and store it in the database, and a module to perform high level queries on past data and forecast trends for the future. It’s really easy to deep dive on any one of those components. It’s not until I get to the final one that I realize how little I really know about problem. I’ll explore it a little, then work on something else for a week, then come back and know exactly how to retackle the problem from start to finish. It’s the revisiting that gives me insight into what to do, and it was the rush to build the prototype that gave me the raw materials needed to have that insight. All of this requires at least one whole day of concentration, then three half days of tinkering, then a final week of rewriting and polishing and responding to code review. So much of this process is subject to external forces that impact my productivity. I am grateful to this article for solidifying them in writing.

marcosdumay 4y ago
Oh, that's for sure. If you don't know what direction to go, you'll get into a random walk, for what the most common outcome is to spend all your days moving without getting anywhere. If instead you rush, you get a longer average free-path and may gather enough information from the results to decide a direction. The situation is different if you already know where you are going before you start.
beyang 4y ago
Author of the post here. This really resonates with me. One of the best pieces of advice I've received in my life as a programmer, from my first manager actually, was "focus on getting an end-to-end system up and running first, no matter how janky, and then refine from there".
- kjsthree 4y ago
  I call this the “thin thread” and agree that it’s best to get that in place fast and hacky. Then refine and bolster from there.
- gjadi 4y ago
  It has different names. In Pragmatic Engineer (the book) it's called tracer bullet, others talk about walking skeleton and I remember a post not too long ago that gave it a different name but I can't find it. And I agree, it's a very good advice and not always so easy to follow. You often need to cut corners and ignore stuff for later to connect the system ASAP. It's mostly through experience that you learn what can be ignored and what should not be ignored.
monch1962 4y ago
Exactly this. When I focus on building a really flaky version of a thing as quickly as possible, then I quickly land on all the edge cases and more-complex-than-I-thought areas I need to deal with. Sometimes I can refactor my flaky code to deal with those, but more often than not it's easier and faster to just throw it away and start again with my new-and-improved knowledge of what needs to be done. The challenge is then (a) working out how far to go down the quick-but-flaky path before starting over, (b) working out whether to keep sections of that flaky code or rewrite it, and (c) trying to not get scrum masters over-excited that I built a barely-working thing in 1 day when the working-well thing is still a week away
- anoopelias 4y ago
  > trying to not get scrum masters over-excited that I built a barely-working thing in 1 day One way to do address this is - to be explicit about the flakiness of the work by marking it as a spike story[1] While this is less than ideal, it is a formal way to get the message across. [1] https://www.agile-academy.com/en/agile-dictionary/spike/ https://www.agile-academy.com/en/agile-dictionary/spike/

marcosdumay 4y ago

Oh, that's for sure. If you don't know what direction to go, you'll get into a random walk, for what the most common outcome is to spend all your days moving without getting anywhere. If instead you rush, you get a longer average free-path and may gather enough information from the results to decide a direction. The situation is different if you already know where you are going before you start.

beyang 4y ago

Author of the post here. This really resonates with me. One of the best pieces of advice I've received in my life as a programmer, from my first manager actually, was "focus on getting an end-to-end system up and running first, no matter how janky, and then refine from there".

kjsthree 4y ago
I call this the “thin thread” and agree that it’s best to get that in place fast and hacky. Then refine and bolster from there.
gjadi 4y ago
It has different names. In Pragmatic Engineer (the book) it's called tracer bullet, others talk about walking skeleton and I remember a post not too long ago that gave it a different name but I can't find it. And I agree, it's a very good advice and not always so easy to follow. You often need to cut corners and ignore stuff for later to connect the system ASAP. It's mostly through experience that you learn what can be ignored and what should not be ignored.

monch1962 4y ago

Exactly this. When I focus on building a really flaky version of a thing as quickly as possible, then I quickly land on all the edge cases and more-complex-than-I-thought areas I need to deal with. Sometimes I can refactor my flaky code to deal with those, but more often than not it's easier and faster to just throw it away and start again with my new-and-improved knowledge of what needs to be done. The challenge is then (a) working out how far to go down the quick-but-flaky path before starting over, (b) working out whether to keep sections of that flaky code or rewrite it, and (c) trying to not get scrum masters over-excited that I built a barely-working thing in 1 day when the working-well thing is still a week away

anoopelias 4y ago
> trying to not get scrum masters over-excited that I built a barely-working thing in 1 day One way to do address this is - to be explicit about the flakiness of the work by marking it as a spike story[1] While this is less than ideal, it is a formal way to get the message across. [1] https://www.agile-academy.com/en/agile-dictionary/spike/ https://www.agile-academy.com/en/agile-dictionary/spike/