Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fix your tools

ochagavia.nl

Post reply on HN
Print view View original

31–40 of 100 posts

Re: Fix your tools

#31

Post by IshKebab »

highfrequency wrote: post #11

Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe). My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”

Most of my colleagues are content to spend 50 hours chopping up the tree with a pipe. We don't have time to spend making things work properly! This tree has to be finished by tomorrow! Maybe after we've cut up this forest, then we'll have a bit of spare time to sharpen things.

Re: Fix your tools

#32

Post by ShellfishMeme »

highfrequency wrote: post #11

Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe). My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”

This approach is also what I'm still missing in agentic coding. It's even worse there because the AI can churn out code and never think "I've typed the same thing 5x now. This can't be right.".

So they never make the change easy because every change is easy to them... until the lack of structure and re-use makes any further changes almost impossible.

Re: Fix your tools

#33

Post by maccard »

I aim for the Boy Scout rule - always leave things better than you found it. It’s always a balance and you have to not lose the forest for the trees. Always ask what is the end goal, and am I still moving forward on that.

Re: Fix your tools

#34

Post by qup »

highfrequency wrote: post #11

Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe). My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”

I don't think you spend all 4 hours up front, friend.

In my experience you're going to want a sharp axe later in the process, once you've dulled it.

Not sure if that ruins the analogy or not.

Re: Fix your tools

#35

Post by teddyh »

sltkr wrote: post #30
Sophira wrote: post #10

Earlier quoted context omitted.

Relevant XKCD: https://xkcd.com/349

And perhaps less well known to the Hacker News crowd, relevant Malcom in the Middle: https://www.youtube.com/watch?v=5W4NFcamRhM

That’s the same video (but in a higher quality) as in the grandparent comment.

Re: Fix your tools

#37

Post by unkulunkulu »

bluGill wrote: post #21
unkulunkulu wrote: post #12

Using the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.

I'm not convinced. At times it can be valueable, but at times you can go around in circles, changing checking variables/break points all the time, but never finding the problem. Often thinking about the problem and what is important is what you need. Playing in the debugger is fun and feels like progress, but it can just be a distraction from understanding the real problem. I'm not completely against debuggers, but i…

I’m talking about using debuggers not even to debug, but to familiarize yourself with the codebase and gain general understanding.

Measure of progress for me is formulating and answering questions. Sometimes trying to answer a question leads to formulating sub questions.

Re: Fix your tools

#39

Post by semiinfinitely »

> The very desire to fix the bug prevented me from seeing I had to fix the tool first, and made me less effective in my bug hunt

Kenneth Stanley's book "Why Greatness Cannot Be Planned: The Myth of the Objective" is dedicated to this phenomenon

Re: Fix your tools

#40

Post by deepsun »

didgetmaster wrote: post #36

It's not just the tools, it is your tests. Most times you encounter and fix a bug, your first question should be 'Why didn't my tests catch this?'

Yes, but the answer depends on the bug. 100% test coverage leads to brittle tests, when any change leads to many broken tests, and fixing them is like repeating the change multiple times.
Post reply on HN