Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

Post reply on HN
Print view View original

191–200 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#191

Post by makerdiety »

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…

Mathematics was invented by the human mind to minimize waste and maximize work productivity. By allowing reality mapping abstractions to take precedence over empirical falsifications of propositions.

And what most people can't do, such as keeping in their heads absolutely all the concepts of a theoretical computer software application, is an indication that real programmers exist on a higher elevation where information technology is literally second nature to them. To put it bluntly and succinctly.

For computer software development to be part of thinking, a more intimate fusion between man and machine needs to happen. Instead of the position that a programmer is a separate and autonomous entity from his fungible software.

The best programmers simulate machines in their heads, basically.

Re: Programming Is Mostly Thinking (2014)

#192

Post by alfagre »

indigoabstract wrote: post #131
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 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…

I tend to see this as a sign that a design is still too complicated. Keep simplifying, which may include splitting into components that are separately easy to keep in your head.

This is really important for maintenance later on. If it's too complicated now to keep in your head, how will you ever have a chance to maintain it 3 years down the line? Or explain it to somebody else?

Re: Programming Is Mostly Thinking (2014)

#193

Post by [deleted] »

indigoabstract wrote: post #165
tsss wrote: post #142

Earlier quoted context omitted.

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.

[deleted]

Re: Programming Is Mostly Thinking (2014)

#194

Post by BossingAround »

thunfischtoast wrote: post #59
willrftaylor wrote: post #47

Funnily enough this happened to me. Earlier in my career I had a very intense, productive working day and then blundered a rebase command, deleting all my data. Rewriting took only about 20 minutes. However, like an idiot, I deleted it again, in the exact same way! This time I had the muscle memory for which files to open and where to edit, and the whole diff took about 5 minutes to re-add. On the way out to the car…

Sometimes you really wonder where your time went. You can spend 1 hour writing a perfect function and then the rest of the day figuring out why your import does work in dev and not in prod. I also once butchered the result of 40 hours of work through a loose git history rewrite. I spent a good hour trying different recovery options (to no avail) and then 2 hours typing everything back in from memory. Maybe it turned…

Sometimes, I spend an hour writing a perfect function, and then spend another hour re-reading the beauty of it, just to be pointed out how imperfect the function is in the PR review :))

Re: Programming Is Mostly Thinking (2014)

#195

Post by BossingAround »

spc476 wrote: post #77

At my previous job, I calculated that over the last year I worked there, I wrote 80 lines of non-test, production code. 80. About one line per 3-4 days of work. I think I could have retyped all the code I wrote that year in less than an hour. The rest of the time? Spent in two daily stand up meetings [1], each at least 40 minutes long (and just shy of half of them lasted longer than three hours). I should also say th…

Were the intense daily meetings any help? I can imagine that if there's a ticket to be solved, and I can talk about the problem for 40 minutes to more experienced coworkers, that actually speeds up the necessary dev time by quite a lot.

Of course, it will probably just devolve into a disengaged group of people that read emails or Slack in another window, so there's that.

Re: Programming Is Mostly Thinking (2014)

#196

Post by BossingAround »

kragen wrote: post #147
f1shy wrote: post #121

Earlier quoted context omitted.

Absolutely. Parallel to thinking LOC is a good metric, comes with "we have to reuse code" Because lots of people think, writing the code is very expensive. It is not!

writing it is not expensive. however, fixing the same bug in all the redundant reimplementations, adding the same feature to all of them, and keeping straight the minor differences between them, is expensive

Not only fixing the same bug twice, but also fixing bugs that happen because of using the same functionality in different places. For example, possible inconsistency that results from maintaining state in multiple different locations can be a nightmare, esp. in hard-to-debug systems like highly parallelized or distributed architecture.

Re: Programming Is Mostly Thinking (2014)

#198

Post by BossingAround »

lofaszvanitt wrote: post #91

Everyone knows this who is a programmer. So this article is for other people, like managers?, who don't know how to measure their effectiveness...

Also junior developers, who might not realize that they are paid to think, not write LOCs.

Re: Programming Is Mostly Thinking (2014)

#199

Post by ben_w »

thaumasiotes wrote: post #167
kragen wrote: post #141

Earlier quoted context omitted.

are you talking about the modal text editor for emacs

I would bet he meant this: https://www.techtarget.com/whatis/definition/VIPER

Correct, that.

The most I've done with emacs (and vim) is following a google search result for "how do I exit …"

Re: Programming Is Mostly Thinking (2014)

#200

Post by matthewsinclair »

hnthrow289570 wrote: post #152
matthewsinclair wrote: post #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,…

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

Well, exactly. That’s kinda my point. Programming is so much more than just writing code. And sadly, some of that other stuff involves dealing with humans and their manifest idiosyncrasies.
Post reply on HN