Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

171–180 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#171
post #156
post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

I agree this is how it often goes. But this also makes it difficult to give accurate estimates because you sometimes need to prototype 2,3 or even more designs to workout the best option. > writing code should be actually seen as part of the "thinking process". Unfortunately most of the times leadership dont' see things this way. For them the tough work of thinking ends with architecture or another layer down. Then t…

In my opinion, you shouldn't need to prototype all of these options .. but you will need to stress test any points where you have uncertainty.

The prototype should provide you with cast iron certainty that the final design can be implemented, to avoid wasting a huge amount of effort.

Re: Programming Is Mostly Thinking (2014)

#172
post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

Pen, paper, diagrams.

Xmind and draw.io

Re: Programming Is Mostly Thinking (2014)

#174

Earlier quoted context omitted.

I tend to iterate. I get a general idea, then start writing code; usually the "sticky" parts, where I anticipate the highest likelihood of trouble. I've learned that I can't anticipate all the problems, and I really need to encounter them in practice. This method often means that I need to throw out a lot of work. I seldom write stuff down[0], until I know that I'm on the right track, which reduces what I call "Concr…

I do the same, iterate. When I am happy with the code I imagine I've probably rewritten it roughly three times. Now I could have spent that time "whiteboarding" and it's possible I would have come close to the same solution. But whiteboarding in my mind is still guessing, anticipating - coding is of course real. I think that as you gain experience as a programmer you are able to intuit the right way to begin to code…

I don’t think this methodology works, unless we are very experienced.

I wanted to work that way, when I was younger, but the results were seldom good.

Good judgment comes from experience. Experience comes from bad judgment.

-Attributed to Nasrudin

Re: Programming Is Mostly Thinking (2014)

#175
post #160
post #144

Earlier quoted context omitted.

unfortunately that is exactly what the humans are doing an alarming fraction of the time

One of the differences is that humans are very good at not doing word associations if we think they don't exist, which makes us able to outperform LLMs even without a hundred billion dollars worth of hardware strapped into our skulls.

that's called epistemic humility, or knowing what you don't know, or at least keeping your mouth shut, and in my experience actually humans suck at it, in all those forms

Re: Programming Is Mostly Thinking (2014)

#177

Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

Does it really take four hours to sharpen an axe? I've never done it.

10/20 minutes to sharpen a pretty dull kitchen knife with some decent whetstones.

Also, as someone famous once said: if I had 4 hours to sharpen an axe, I'd spend 2 hours preparing the whetstones.

Re: Programming Is Mostly Thinking (2014)

#178
Author listed a handful of the thinking aspects that take up the 11/12 non-motion work.. but left out naming things! The amount of time in conversation about naming, or even renaming the things I've already named.. there's even a name for it in the extreme, bikeshedding. Even sometimes I'll be fixated on how to phrase the comments for a function or even reformat things for line lengths to fit.

Programming is mostly communicating.

Re: Programming Is Mostly Thinking (2014)

#179

Earlier quoted context omitted.

I tend to iterate. I get a general idea, then start writing code; usually the "sticky" parts, where I anticipate the highest likelihood of trouble. I've learned that I can't anticipate all the problems, and I really need to encounter them in practice. This method often means that I need to throw out a lot of work. I seldom write stuff down[0], until I know that I'm on the right track, which reduces what I call "Concr…

I do the same, iterate. When I am happy with the code I imagine I've probably rewritten it roughly three times. Now I could have spent that time "whiteboarding" and it's possible I would have come close to the same solution. But whiteboarding in my mind is still guessing, anticipating - coding is of course real. I think that as you gain experience as a programmer you are able to intuit the right way to begin to code…

Yeah, the same. I rewrite code until I'm happy with it. When starting new program, it might cause lots of time wasted because I might need to spend weeks rewriting and re-tossing everything until I feel I got it good enough. Tried to do it faster, but I just can't. The only way is to write a working code and reflect on it.

My only optimization of this process is to use Java and not just throw out everything, but keep refactoring. Idea allows for very quick and safe refactoring cycles, so I can iterate on overall architecture or any selected components.

I really envy on people who can get it right first time. I just can't, despite having 20 years of programming under my seat. And when time is tight and I need to accept obviously bad design, that what makes me burning out.

Re: Programming Is Mostly Thinking (2014)

#180

Author listed a handful of the thinking aspects that take up the 11/12 non-motion work.. but left out naming things! The amount of time in conversation about naming, or even renaming the things I've already named.. there's even a name for it in the extreme, bikeshedding. Even sometimes I'll be fixated on how to phrase the comments for a function or even reformat things for line lengths to fit. Programming is mostly c…

Yep, with seniority programming gradually goes from problem solving to product communication and solution proposition
Post reply on HN