I agree with you: the playful exploration of an idea space can lead to really creative solutions. However, I think what we need to focus on is hacking at the appropriate level.

For example, trying to iterate on regexen to see how well they validate credit cards on your shopping cart form is at a different level to say, trying out a new database system. The former can be undertaken in a desultory way more easily than the latter--and therein lies the trap. It's easy to generate a false sense of progress, seeing code being output and test cases passing, all the while without really understanding or learning anything about the code or the problem at all.

Precision understanding of the mechanics of coding, on the other hand, free you to concentrate on higher problems. You don't need to play whack-a-mole with locks and semaphores to eliminate race conditions, and can focus on developing that revolutionary game.

Yea, that's about the worst advice to give a programmer/hacker. The "maybe I can try this" and "I wonder if I could do this" is the core of my world. I've been told by actual engineers that things I wanted to do were impossible, but I played, and did the impossible. Play with your code.

I find it hard to really understand certain things: design patterns, data structures, and sometimes algorithms, without trying them.

I knew a very, very bright person who could come up with some great and clean code. He definitely understood the problem and his solution was "optimal." Problem, before he even started coding he did an insane amount of research. Not just learning syntax, common patterns, etc.. but to the point of memorizing the entire standard library and reading several books on the problem domain before even beginning with some hash-it-out code. This wasn't for hard problems, just simple CRUD apps (for the most part.) Made it impossible to work with him as a team member.

I'm not seeing the drawback to him. It may have even worked out to his benefit, as over time his knowledge of the craft would grow out of proportion to the rest of his team, say, who were solely focussed on getting things done.

I must say I'm really curious. What was his career trajectory? Has he been successful since?

Not sure, I don't believe so.

I think it's talking about people who don't know how to read code and discern what's happening and just end up tweaking things, cutting and pasting code, etc. just kind of crossing their fingers that it will work.

I guess this is a problem with proverbs: lack of context. For architectural design or requirements elicitation it's all about improving with iterations. However with detailed design you can be quite precise and shouldn't just wing it.

They also tend to be the ones who have only a superficial understanding of what their code/the language is doing, and to whom edge cases are an almost unknown concept. Those people would be well advised to apply the Feynman Algorithm more.

I think you might have misunderstand the Feynman Algorithm (alternative possibility, I misunderstood it).

My understanding of the Feynman Algorithm was that it was basically a joke by Gell-Mann. Gell-Mann was pointing out that no one else on earth (even himself, a Noble prize winner) could work the way Feynman did, the joke being that he only needed three steps: (1) Write down the problem. (2) Think real hard. (3) Write down the solution. It was about the absurd brilliance of Feynman, not intended as any sort of useful model to follow.

At the end of the day, anybody that cretes anything of importance is hacking most of the time.

That does not mean one shouldn't plan, and know why his hacks work. Just that non-hackish solutions normaly only work in already solved problems.

In my experience, it ends up being much more efficient (in the long term) to "understand with precision" - think and think and think about it, and only after you've thought it through, write the code.

"Try until it works" is a mark of an inexperienced craftsman - simply not knowing enough about the tools, the particular domain and the problem at hand forces one to try and try again until something works.. but that kind of "accidental" approach is inefficient compared to an intentional, measured approach.

It's very humbling to work alongside an older, experienced developer - the proportion of time they spend writing actual code is relatively low; most of the time is spent on working out the assumptions, the constraints, teasing out the larger picture from the details, and constructing a technical design... the actual code-writing is like a few quick yet measured strikes of a samurai sword - quiet, almost invisible, frighteningly effective.

> programming is definitely about trying until it works.

Sounds like you need some more meta. If "trying until it works" is your algorithm, why not have a program execute it for you? ;)

Because human-brain heuristics are very good at deciding what to try next, while too complex to be coded into a program in the first place.

Of course you could formalize those heuristics... trying until they worked ;)

Hacking is trying until it works.

Programming requires more precise understanding.

I work as a mechanical engineer, and that involves only slightly less trying things until they work than programming.

Where else would one getting precise understanding, anyway?

That applies also to engineering in some degree...