Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

151–160 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#151
post #3

This is laid out pretty early on by Bjourne in his PPP book[0], > We do not assume that you — our reader — want to become a professional programmer and spend the rest of your working life writing code. Even the best programmers — especially the best programmers — spend most of their time not writing code. Understanding problems takes serious time and often requires significant intellectual effort. That intellectual c…

*Bjarne

Re: Programming Is Mostly Thinking (2014)

#152

This is also relevant in the context of using LLMs to help you code. The way I see it, programming is about “20% syntax and 80% wisdom”. At least as it stands today. LLMs are good (perhaps even great) for the 20% that is syntax related but much less useful for the 80% that is wisdom related. I can certainly see how those ratios might change over time as LLMs (or their progeny) get more and more capable. But for now,…

Sadly like half of that wisdom has to do with avoiding personal stress caused by business processes.

Re: Programming Is Mostly Thinking (2014)

#153
I tend to spend a lot of time in REPL or throwaway unit tests, tinkering out solutions. It helps me think to try things out in practice, sometimes visualising with a diagramming language or canvas. Elixir is especially nice in this regard, the language is well designed for quick prototypes but also has industrial grade inspection and monitoring readily available.

Walks, hikes and strolls are also a good techniques for figuring things out, famously preferred by philosophers like Kierkegaard and Nietzsche.

Sometimes I've brought it up with non-technical bosses how development is actually done, didn't work, they just dug in about monitoring and control and whatnot. Working remote is the way to go, if one can't find good management to sell to.

Re: Programming Is Mostly Thinking (2014)

#154
post #136

Earlier quoted context omitted.

yeah, i just sketched out some code ideas on paper over a few days, checked and rechecked them to make sure they were right, and then after i wrote the code on the computer tonight, it was full of bugs that i took hours and hours to figure out anyway. debugging output, stepping through in the debugger, randomly banging on shit to see what would happen because i was out of ideas. i would have asked coworkers but i'm f…

I've no coworkers either, and over time both I and my code suffer for it. Some say thinking is at it's essence a social endeavor.

I should say rather, Thinking.

Re: Programming Is Mostly Thinking (2014)

#155

This is why domain knowledge is key. I work in finance, I've sat on trading desks looking at various exchanges, writing code to implement this or that strategy. You can't think about what the computer should do if you don't know what the business should do. From this perspective, it might make sense to train coders a bit like how we train translators. For example, I have a friend who is a translator. She speaks a bun…

> This is why domain knowledge is key

In the comment thread, I keep seeing prescriptions over and over for the one way that programming should work.

Computer programming is an incredibly broad discipline that covers such a broad range of types of work. I think it is incredibly hard to make generalizations that actually apply to the whole breadth of what computer programming encompases.

Rather than trying learn or teach one perfect one single methodology that applies accross every sub field of programming, I think that one should aim to build a toolbag of approaches and methodologies along with an understanding where they tend to work well.

Re: Programming Is Mostly Thinking (2014)

#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 the engineers are responsible only for translating those designs into software just by typing away with a keyboard.

This leads to mismatch in delivery expectations between leadership and developers.

Re: Programming Is Mostly Thinking (2014)

#157
“Programming is mostly thinking” is one of these things we tell ourselves like it is some deep truth but it’s the most unproductive of observations.

Programming is thinking in the same exact way all knowledge work is thinking:

- Design in all it’s forms is mostly thinking

- Accounting is mostly thinking

- Management in general is mostly thinking

The meaningful difference is not the thinking, it’s what are you thinking about.

Your manager needs to “debug” people-problems, so they need lots of time with people (i.e. meetings).

You are debugging computer problems, so you need lots of time with your computer.

There’s an obvious tension there and none of the extremes work, you (and your manager) need to find a way to balance both of your workloads to minimize stepping on each others toes, just like with any other coworker.

Re: Programming Is Mostly Thinking (2014)

#158
Most software developer jobs are not really programming jobs. By that I mean the amount of code written is fairly insignificant to the amount of "other" work which is mainly integration/assembly/glue work, or testing/verification work.

There definitely are some jobs and some occasions where writing code is the dominant task, but in general the trend I've seen over the past 20 years I've been working has been more and more to "make these two things fit together properly" and "why aren't these two things fitting together properly?"

So in part I think we do a disservice to people entering this industry when we emphasize the "coding" or "programming" aspects in education and training. Programming language skills are great, but very important is systems design and integration skills.

Re: Programming Is Mostly Thinking (2014)

#159
post #83

This is why I just don't care about my keyboard, mouse, monitor etc beyond a baseline of minimum comfort. Typing at an extra 15 wpm won't make a lick of difference in how quickly I produce a product, nor will how often my fingers leave the keyboard or how often I look at the screen. Once I've ingested the problem space and parameters, it all happens in my head.

I often feel that having a "comfortable" keyboard/mouse/monitor is more important than a fast CPU or a fancy graphics card - just because of that slight extra feeling of pleasure/ease that lasts all day long :-). The advantage of them is that my monitors and keyboards usually last a long time so putting money into them is not as wasteful as putting it into some other components. One thing that surprised me though is…

May I ask which brand of KVM you selected? I have a Dell laptop and want a "docking" configuration for my desk, the simpler the better.

Re: Programming Is Mostly Thinking (2014)

#160
post #144

Earlier quoted context omitted.

LLMs string together words using probability and randomness. This makes their output sound extremely confident and believable, but it may often be bullshit. This is not comparable to thought as seen in humans and other animals.

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.
Post reply on HN