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

301–310 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#301

Post by iraqmtpizza »

makerdiety wrote: post #191
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 informati…

String theory was invented by the human mind to minimize productivity and maximize nerd sniping. Pure math.

Re: Programming Is Mostly Thinking (2014)

#302

Post by iraqmtpizza »

xondono wrote: post #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 thinkin…

It's not nearly as unproductive as my old PhD college professor who went on and on about the amount of time you lose per day moving your hand off your keyboard when you could be memorizing shortcuts and macros instead of working

Re: Programming Is Mostly Thinking (2014)

#304

Post by iraqmtpizza »

MartijnBraam wrote: post #26

Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.

This is literally impossible with GitHub Desktop and a functioning Recycle Bin

Re: Programming Is Mostly Thinking (2014)

#305

Post by ABoredBirb »

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…

My pet theory is that developers exist on a spectrum between "planner" and "prototyper" - one extreme spends a lot of time thinking about a solution before putting it into code - hopefully hitting the goal on first attempt. The other iterates towards it. Both are good to have on the team.

Re: Programming Is Mostly Thinking (2014)

#306

Post by lelanthran »

demondemidi wrote: post #30

Programming is mostly planning. When you work for companies that take programming seriously (e.g., banks, governments, automotive, medical equipment, etc.), a huge development cycle occurs before a single line of code is written. Here are some key development phases (not all companies use all of them): 1. high level definition, use cases, dependencies; traceability to customer needs; previous correction (aka failures…

Somewhere in that list you need to add some time for certification, plus rework after certification failure!

Not only does it take a week, but each attempt costs a few tens of thousands of dollars.

Re: Programming Is Mostly Thinking (2014)

#307

Post by mannykannot »

alfagre wrote: post #285
mannykannot wrote: post #205

Earlier quoted context omitted.

This is the only practical way (IMHO) to do a good job, but there can be an irreducibly complex kernel to a problem which manifests itself in the interactions between components even when each atomic component is simple.

Then the component APIs need improvement.

Without an argument for this always being possible, this just looks like unjustified dogma from the Clean Code era.

Re: Programming Is Mostly Thinking (2014)

#308

Post by eschneider »

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'm not sure why folks think they need to hold all this in their head. For me, at least, the "think about the problem stage" involves a lot of:

* Scribbling out some basic design notes. * Figuring out the bits I'm not completely sure about * Maybe coding up some 'prototype' code to prove out the bits I'm less sure about * Repeat until I think I know what I'm doing/validated my assumptions * Put together a 'more formal' design to share with the team. Sometimes my coworkers think of things that I hadn't, so it's not quite a formality. :) * Code the thing up.

By the time I get to the "code it up" stage, I've probably put in most of the work. I've written things down as design, but nothing hyperdetailed. Just what I need to remind myself (and my team) of the decisions I've made, what the approach is, the rejected ideas, and what needs doing. Some projects need a fair bit on paper, some don't.

Re: Programming Is Mostly Thinking (2014)

#309

Post by kragen »

Akronymus wrote: post #265
BossingAround wrote: post #196

Earlier quoted context omitted.

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.

I see "code that looks the same" being treated as "code that means the same" resulting in problems much more often than "code that means the same" being duplicated.

can you clarify your comment with some examples, because i'm not sure what you mean, even whether you intend to disagree with the parent comment or agree with it

Re: Programming Is Mostly Thinking (2014)

#310

Post by swiftcoder »

xiwenc wrote: post #283
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…

Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git. This is special because most real world systems has a lot more dependencies. That’s when experimentation is required. Because one cannot know all relevant API’s beforehand and their behaviors. Therefore the only w…

> Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git.

This type of developer tends to prefer building software like this. There is a whole crowd of hardcore C/C++/Rust devs who eschew taking dependencies in favour of writing everything themselves (and they mostly nerd-snipe themselves with the excessive NIH syndrome, like Jonathon Blow off writing Powerpoint[1]...)

Torvalds seems to be mostly a special case in that he found a sufficiently low-level niche where extreme NIH is not a handicap.

[1]: https://www.youtube.com/watch?v=t2nkimbPphY&list=PLmV5I2fxai...

Post reply on HN