Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

131–140 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#131
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 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 it, testing it, thinking some more, changing some minor or major parts of what we wrote, and so on, until it feels good enough.

In the end, it's a bit of an art, coming up with the final working version.

Re: Programming Is Mostly Thinking (2014)

#132

> 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…

I once led a project to develop a tool that tracks how people use their time in a large corporation. We designed it to be privacy-respecting, so it would log that you are using the Web browser, but not the specific URL, which is of course relevant (e.g. Intranet versus fb.com). Every now and then, a pop up would ask the user to self-rate how productive they feel, with a free-text field to comment. Again, not assigned to user IDs in order to respect privacy, or people would start lying to pretend to be super-human.

We wrote a Windows front end and a Scala back end for data gathering and roled it out to a group of volunteers (including devs, lawyers and finace people even). Sadly the project ran out of time and budget just as things were getting interesting (after a first round of data analysis), so we never published a paper about it.

We also looked at existing tools such as Rescue Time ( https://www.rescuetime.com/ ) but decided an external cloud was not acceptable to store our internal productivity data.

Re: Programming Is Mostly Thinking (2014)

#133
post #65

In the 2020s, we still have software engineering managers that think of LOC as a success metric. “How long would it take you to type the 6 hours work of diff?” is a great question to force the cognitively lazy software manager to figure out how naive that is. Nowadays I feel great when my PRs have more lines removed than added. And I really question if the added code was worth the added value if it’s the opposite.

Conversely, how long would it take the average manager to re-utter any directions they gave the previous day?

Re: Programming Is Mostly Thinking (2014)

#134
post #106

Great article! I've posted it in other comments before, but it's worth repeating: The best explanation I've seen is in the book "The Secret Life of Programs" by Jonathan E. Steinhart. I'll quote that paragraph verbatim: --- Computer programming is a two-step process: 1. Understand the universe. 2. Explain it to a three-year-old. What does this mean? Well, you can't write computer programs to do things that you yourse…

Edit: Aften writing this long nitpicky comment, I have though of a much shorter and simpler point I want to make: Programming is mostly thinking and there are many ways to do the work of thinking. Different people and problems call for different ways of thinking and learning to think/program in different ways will give more tools to choose from. Thus I don't like arguments that there is one right way that programming happens or should happen.

I'm sorry, but yout entire comment reads like a list of platitudes about programming that don't actually match reality.

> Well, you can't write computer programs to do things that you yourself don't understand.

Not true. There are many times where writing software to do a thing is how I come to understand how that thing actually works.

Additionally, while an understanding of physics helps with modeling physics, much of that physics modeling is done to implement video games and absolute fidelity to reality is not the goal. There is often an exploration of the model space to find the right balance of fidelity, user experience and challenge.

Software writing is absolutely mostly thinking, but that doesn't mean all or even most of the thinking should al always come first. Computer programming can be an exploratory cognitive tool.

> So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant.

I'm all about generalist and autodidacts, but becomming one isn't a necessary first step to being a good programmer.

> The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do.

Umm... children have "rigid" world views? Do you know any children?

> Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question.

Oh, you don't mean rigid, you mean they can't always infer social subtexts.

> Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up.

Computes make inferrences all the time. Deriving logical conclusions from known facts is absolutely something computers can be programmed to do and is arguably one of their main uses cases.

I have spent time explaining to things to children of various ages, including 3 year olds, and find the experience absolutely nothing like programming a computer.

Re: Programming Is Mostly Thinking (2014)

#135
> If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work?

The diff will help, but it'll be an order of magnitude faster to do it the second time, diff provided or not.

For the same reason.

Re: Programming Is Mostly Thinking (2014)

#136
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…

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 fresh out of those at the moment

i am not smart enough this week to debug a raytracer on paper before typing it in, if i ever was

things like hypothesis can make a computer very powerful for checking out ideas

Re: Programming Is Mostly Thinking (2014)

#138
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, that ratio feels about right.

Re: Programming Is Mostly Thinking (2014)

#140

So the waterfall model is the best after all?

Wouldn't say so.

An iterative model which has been up-front loaded with a firm architecture, feature elaboration, a rough development and testing plan, resources allocated and some basic milestones to hit so that upper mgmt. can get an idea when useful stuff might land.

The development _process_ can be as agile-y as you like, so long as the development of features moves incrementally with each iteration towards the desired end-goal.

But you have to be strict about scope.

Post reply on HN