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

251–260 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#251

Post by hgomersall »

demondemidi wrote: post #244
hgomersall wrote: post #40

Earlier quoted context omitted.

And it's a terrible way to make anything, much less software. It's more forgivable when the cost of outer iteration is high because you're making, say, a train, but even then you design around various levels of simulation, iterating in the virtual world. The idea that you can nail down all the requirements and interfaces before you even begin is why so many projects of the type you describe often have huge cost overr…

So you think it is smarter to, say, tell the carpenters “just start building a house” without giving them plans? What you described is not how successful products are built and maintained; what you described is why we have world full of lots of shitty tech from “move fast and break things” ADHD-like management and young programmers that think they know everything and cry about having to do thinky work first. Literall…

I'm talking about engineering, not manufacturing. I'm not suggesting not thinking, I'm saying that you cannot design every aspect of a system without learning more about the design. It's just a restatement of "Gall's law" (in scare quotes because it's obviously not an actual law). Alternatively it's the obvious way of working given the principles espoused in the agile manifesto.

Re: Programming Is Mostly Thinking (2014)

#252

Post by nevertoolate »

graemep wrote: post #249

> typing and tools are not the most important aid to quick code production I think they are in an indirect way. Being able to touch type reasonably fast prevents the action of typing distracting you from your thoughts, or lagging so far behind your thoughts that it makes it harder to keep your thoughts clear in your mind. Maybe something similar with good tools.

I think OP means that problems are just too hard to solve without thinking Before starting to type. So basically the typing in part is decoupled from the real thinking, and just about picking up half ready ideas from the queue and deserialize it, so to say, as code.

Re: Programming Is Mostly Thinking (2014)

#253

Post by avodonosov »

porksoda wrote: post #162
avodonosov wrote: post #149

If so, is it a good idea to base programmer interview on live coding session?

I love this type of interview. I code with the goal of showing how it's done, not how much I can do, and they very soon realize that they won't see finished code on "this" call. It's an opportunity to teach non-coders that hidden intricacies exist in even the smallest ticket. Usually just a few minutes in they're fatigued, and they know who I am.

The interviewers in a coding session are usually coders themselves, I think.

Re: Programming Is Mostly Thinking (2014)

#254

Post by stoperaticless »

alfagre wrote: post #192
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…

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?

Sometimes, as code get’s written, it becomes clearer what kind of component split is better, which things can be cleanly separated and which less so.

Re: Programming Is Mostly Thinking (2014)

#255

Post by tasuki »

FeepingCreature wrote: post #238
tasuki wrote: post #89

Earlier quoted context omitted.

Source?

I use them a lot. They sure seem thinky. The other day I had one write a website for me. Totally novel concept. No issues.

I have a similar experience. Just thought it'd be cute to ask you both for sources. Interesting that asking you for sources got me upvoted, while asking the other guy for sources got me downvoted :)

Re: Programming Is Mostly Thinking (2014)

#256

Post by tasuki »

dclowd9901 wrote: post #218
tasuki wrote: post #87

Earlier quoted context omitted.

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

Very good explanation!

> “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!”

I'm guilty of this. I even fought hard against the people who wanted to keep the code duplicated for the different data types.

> “encapsulate behaviors that you need to synchronize.”

I like that!

Re: Programming Is Mostly Thinking (2014)

#257

Post by stoperaticless »

dave78 wrote: post #240
patmcc wrote: post #231

Earlier quoted context omitted.

I'm going to take a stab here: you've never used cvs or svn. git, for all its warts, is quite literally a 10x improvement on those, which is what it was (mostly) competing with.

I started my career with Clearcase (ick) and added CVS for personal projects shortly after. CVS always kind of sucked, even compared with Clearcase. Subversion was a massive improvement, and I was pretty happy with it for a long time. I resisted moving from Subversion to Git for a while but eventually caved like nearly everyone else. After learning it sufficiently, I now enjoy Git, and I think the model it uses is be…

> I thought it was pretty universally agreed

Depends what you consider “universally agreed”.

At least one person (me) thinks that: git interface is good enough as is (function>form here), regexps are not too terse - that’s the whole point of them.

Related if you squint a lot: https://prog21.dadgum.com/170.html

Re: Programming Is Mostly Thinking (2014)

#258

Post by 0x20cowboy »

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 think it was Feynman who said something to the effect of “writing is thinking”.

Re: Programming Is Mostly Thinking (2014)

#259

Post by thyrsus »

alfagre wrote: post #192
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…

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?

I'm more than half the time figuring out the environment. Just as you learn a new language by doing the exercises, I'm learning a bunch of stuff while I try to port our iptables semantics o firewalld: [a] gitlab CI/CD instead of Jenkins [b] getting firewalld (requires systemd) running in a container [c] the ansible firewalld module doesn't support --direct required for destination filtering [d] inventing a test suite for firewall rules, since the prebuilt I've found would involve weeks of yak shaving to get operating. So I'm simultaneously learning about four environments/languages at once - and this is typical for the kind of project I get assigned. There's a *lot* of exploratory coding happening. I didn't choose this stuff - it's part of the new requirements. I try for simple first, and often the tools don't support simple.

Re: Programming Is Mostly Thinking (2014)

#260

Post by shkkmo »

MichaelZuo wrote: post #210
shkkmo wrote: post #134

Earlier quoted context omitted.

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…

I would say very young children up until they acquire concepts like a theory of mind, cause and effect happening outside of their field of observation, and so on, are pretty rigid in many ways like computers. It's a valuable insight. Or at least they don't make mistakes in exceptionally novel and unusual ways until they're a bit older.

> I would say very young children up until they acquire concepts like a theory of mind, cause and effect happening outside of their field of observation, and so on, are pretty rigid in many ways like computers. It's a valuable insight.

I don't see any overlapp between the two skill sets, since you do I'd be curious for examples of where you do see overlap.

Post reply on HN