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

211–220 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#211

Post by marcosdumay »

devsda wrote: post #156
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 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 t…

If you know so little that you have to make 3 prototypes to understand your problem, do you think designing it by any other process will make it possible make an accurate estimate?

Re: Programming Is Mostly Thinking (2014)

#212

Post by marcosdumay »

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…

> The best programmers simulate machines in their heads, basically.

Yes, but they still suck at it.

That's why people create procedures like prototyping, test driven design, type driven design, paper-prototypes, API mocking, and etc.

Re: Programming Is Mostly Thinking (2014)

#213

Post by perrygeo »

Writers get a bit dualistic on this topic. It's not "sitting in a hammock and dreaming up the the entire project" vs. "hacking it out in a few sprints with no plan". You can hack on code in the morning, sit in a hammock that afternoon, and deliver production code the next day. It's not either-or. It's a positive feedback loop between thinking and doing that improves both.

Re: Programming Is Mostly Thinking (2014)

#214

Post by tibbar »

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 secret to designing entire applications in your head is to be intimately familiar with the underlying platform and gotcha's of the technology you're using. And the only way to learn those is to spend a lot of time in hands-on coding and active study. It also implies that you're using the same technology stack over and over and over again instead of pushing yourself into new areas. There's nothing wrong with this; I actually prefer sticking to the same tech stack, so I can focus on the problem itself; but I would note that the kind of 'great developer' in view here is probably fairly one-dimensional with respect to the tools they use.

Re: Programming Is Mostly Thinking (2014)

#216

Post by QuercusMax »

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.

What do you mean by API? Linus's original got didn't have an API, just a bunch of low level C commands ('plumbing'). The CLI ('porcelain') was originally just wrappers around the plumbing.

Re: Programming Is Mostly Thinking (2014)

#217

Post by wredue »

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 don’t like that line at all.

Personally, I think good developers get characters on to the screen and update as needed.

One problem with so much upfront work is how missing even a tiny thing can blow it all up, and it is really easy to miss things.

Re: Programming Is Mostly Thinking (2014)

#218

Post by dclowd9901 »

tasuki wrote: post #87
dclowd9901 wrote: post #15

Earlier quoted context omitted.

I don’t really know what “think algorithmically means,” but what I’d like to see as a lead engineer is for my seniors to think in terms of maintenance above all else. Nothing clever, nothing coupled, nothing DRY. It should be as dumb and durable as an AK47.

> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interesting. Would you prefer all the code to be repeated in multiple places?

Depends. I haven’t come up with the rubric yet but it’s something like “don't abstract out functionality across data types”. I see this all the time: “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” Invariably it ends up collapsing, and if the whole program is constructed this way, it becomes monstrous to untangle, like exponentially complicated on the order of abstractions. I think it’s just a breathtaking misunderstanding of what DRY means. It’s not literally “don’t repeat yourself”. It’s “encapsulate behaviors that you need to synchronize.”

Also, limit your abstractions’ external knowledge to zero.

Re: Programming Is Mostly Thinking (2014)

#219

Post by sibeliuss »

teekert wrote: post #75
sibeliuss wrote: post #72

I certainly notice folks who code about 30 minutes a day line-wise, but that's just because they're distracted, or don't care. Also, very very rarely is someone just sitting around and pondering the best solution. It happens, and yes it's necessary, but that's forgetting that for so much work the solution is already there, because one has already solved it a thousand times! This article is straight gibberish except f…

It's also: "Damn I just wrote this whole new set of functions while I could have added some stuff to this existing class and it would have been more elegant... Let me start over..." Writing (code) is thinking.

Exactly. The code is the feedback loop.

Re: Programming Is Mostly Thinking (2014)

#220

Post by xvilka »

BossingAround wrote: post #195
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.

80% of meetings are useless. Especially long ones.
Post reply on HN