Programming Is Mostly Thinking (2014) • Hacker News Board

Re: Programming Is Mostly Thinking (2014)

#161

Post by mkl » Sun, Apr 21, 2024, 12:35 PM UTC

Barrin92 wrote: post #39

Almondsetat wrote: post #2

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."

it's an odd analogy because programs are complex systems and involve interaction between countless of people. With large software projects you don't even know where you want to go or what's going to happen until you work. A large project doesn't fit into some pre-planned algorithm in anyone's head, it's a living thing. diagrams and this kind of planning is mostly a waste of time to be honest. You just need to start t…

> Novelists for example know this very well. Beginners are always obsessed with intellectually planning out their book. The experienced writer will always tell you, stop yapping and start typing.

This is not true in general. Brandon Sanderson for example outlines extensively before writing: https://faq.brandonsanderson.com/knowledge-base/can-you-go-i...

Re: Programming Is Mostly Thinking (2014)

#162

Post by porksoda » Sun, Apr 21, 2024, 12:36 PM UTC

avodonosov wrote: post #149

If so, is it a good idea to base programmer interview on live coding session?

I love this type of interview. I code with the goal of showing how it's done, not how much I can do, and they very soon realize that they won't see finished code on "this" call. It's an opportunity to teach non-coders that hidden intricacies exist in even the smallest ticket. Usually just a few minutes in they're fatigued, and they know who I am.

Re: Programming Is Mostly Thinking (2014)

#163

Post by msephton » Sun, Apr 21, 2024, 12:41 PM UTC

I agree that programming is mostly thinking. But I don't agree with the how the post justifies it.

Re: Programming Is Mostly Thinking (2014)

#164

Post by devsda » Sun, Apr 21, 2024, 12:44 PM UTC

hubraumhugo wrote: post #42

> how can you experiment with learning on-the-job to create systems where the thinking is optimized? Best optimization is less interruptions as reasearch shows their devastating effect on programming: - 10-15 min to resume work after an interruption - A programmer is likely to get just one uninterrupted 2-hour session in a day - Worst time to interrupt: during edits, searches & comprehension I've been wondering if th…

If you ask a manager to hold an hour's meeting spread across 6 hours in 10 min slots you will get the funniest looks.

Yet developers are expected to complete a few hours of coding task in between an endless barrage of meetings, quick and short pings & syncups over slack/zoom.

For the few times I've had to work on the weekends at home, I've observed that the difference in the quality of work done over a (distraction free) weekend is much better than that of a hectic weekday.

Re: Programming Is Mostly Thinking (2014)

#165

Post by indigoabstract » Sun, Apr 21, 2024, 12:49 PM UTC

tsss wrote: post #142

indigoabstract wrote: post #131

Earlier quoted context omitted.

I had the same thought as I read that line. I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested. But for the rest of us (especially myself), it seems to be more like an interplay between thinking of what to write, writing…

Well that explains why Git has such a god awful API. Maybe he should've done some prototyping too.

Yeah, could be.. IIRC, he said he doesn't find version control and databases interesting. So he just did what had to be done, did it quickly and then delegated, so he could get back to more satisfying work.

I can relate to that.

Re: Programming Is Mostly Thinking (2014)

#166

Post by Aerroon » Sun, Apr 21, 2024, 12:50 PM UTC

brabel wrote: 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…

The way I read that is that only 10% of the work is writing out the actual implementation that you're sticking with. How you get there isn't as important. Ie someone might want to take notes on paper and draw graphs while others might want to type things out. That's all still planning.

Re: Programming Is Mostly Thinking (2014)

#167

Post by thaumasiotes » Sun, Apr 21, 2024, 12:52 PM UTC

kragen wrote: post #141

ben_w wrote: post #122

Earlier quoted context omitted.

> 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. Indeed, and this limitation specifically is why I dislike VIPER: the design pattern itself was taking up too many of my attention slots, leaving less available for the actual code. (I think I completely failed to convince anyone that this was important).

are you talking about the modal text editor for emacs

I would bet he meant this:

https://www.techtarget.com/whatis/definition/VIPER

Re: Programming Is Mostly Thinking (2014)

#168

Post by paulryanrogers » Sun, Apr 21, 2024, 12:52 PM UTC

devsda wrote: post #143

AlotOfReading wrote: post #8

I'm confident enough to tout this number as effectively true, though I should mention that no company I work with has so far been willing to delete a whole day's work to prove or disprove this experiment yet. Long ago when I was much more tolerant, I had a boss that would review all code changes every night and delete anything he didn't like. This same boss also believed that version control was overcomplicated and d…

The bigger problem here is the manager getting involved with code. Even when done with good intentions, managers being involved in code/reviews almost always ends up being net negative for the team.

Why?

Re: Programming Is Mostly Thinking (2014)

#169

Post by JKCalhoun » Sun, Apr 21, 2024, 12:54 PM UTC

ChrisMarshallNY wrote: post #111

brabel wrote: 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 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 a problem, the iterating is still there but more incremental.

Re: Programming Is Mostly Thinking (2014)

#170

Post by JKCalhoun » Sun, Apr 21, 2024, 1:02 PM UTC

Somehow the post seemed to miss the amount of time I seem to spend on "busy work" in coding. Not meetings and that sort of thing, but just boring, repetitive, non-thinking coding.

Stubbing in a routine is fast, but then adding param checking, propagating errors, clean up, adding comments, refactoring sections of code into their own files as the code balloons, etc.

There's no thinking involved in most of the time I am coding. And thank god. If 11/12 of my time was spent twisting my brain into knots to understand the nuances of concurrency or thread-locking I would have lost my hair decades earlier.