Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

201–210 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#201
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'd like to second that, especially if combined with a process where a lot of code should get discarded before making it into the repository. Undoing and reconsidering initial ideas is crucial to any creative flow I've had.

Re: Programming Is Mostly Thinking (2014)

#202
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 think the quote suggests that a programmer would mentally design a whole system before writing any code. As programmers, we are used to thinking in problems as steps needing resolution and that's exactly the 90% there. When you're quickly prototyping to see what fits better as a solution to the problem you're facing, you must have already thought what are the requirements, what are the constraints, what would be a reasonable API given your use case. Poking around until you find a reasonable path forward means you have already defined which way is forwards.

Re: Programming Is Mostly Thinking (2014)

#203

Earlier quoted context omitted.

I do the same, iterate. When I am happy with the code I imagine I've probably rewritten it roughly three times. Now I could have spent that time "whiteboarding" and it's possible I would have come close to the same solution. But whiteboarding in my mind is still guessing, anticipating - coding is of course real. I think that as you gain experience as a programmer you are able to intuit the right way to begin to code…

Yeah, the same. I rewrite code until I'm happy with it. When starting new program, it might cause lots of time wasted because I might need to spend weeks rewriting and re-tossing everything until I feel I got it good enough. Tried to do it faster, but I just can't. The only way is to write a working code and reflect on it. My only optimization of this process is to use Java and not just throw out everything, but keep…

Nobody gets it right the first time.

Good design evolves from knowing the problem space.

Until you've explored it you don't know it.

I've seen some really good systems that have been built in one shot. They were all ground up rewrites of other very well known but fatally flawed systems.

And even then, within them, much of the architecture had to be reworked or also had some other trade off that had to be made.

Re: Programming Is Mostly Thinking (2014)

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

Right, I always thought this is what TDD is used for, very often I design my code in tests and let it kind of guide my implementation. I kind of imagine what the end result should be in my head (given value A and B, these rows should be X and Y), then write the tests in what I _think_ would be a good api for my system and go from there. The end result is that my code is testable by default and I get to go through mul…

TDD comes up with some really novel designs sometimes.

Like, I expect it should look one way but after I'm done with a few TDD cycles I'm at a state that's either hard to get there or unnecessary.

I think this is why some people don't like TDD much, sometimes you have to let go of your ideas, or if you're stuck to them, you need to go back much earlier and try again.

I kind of like this though, makes it kind of like you're following a choose your own adventure book.

Re: Programming Is Mostly Thinking (2014)

#205

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?

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.

Re: Programming Is Mostly Thinking (2014)

#206
post #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…

Are you replying to me or to the author of the quote? :)

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

Absolutely, explaining something to the child also can be exploratory cognitive tool.

Re: Programming Is Mostly Thinking (2014)

#207
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 don't do it in my head. I do diagrams, then discuss them with other people until everyone is on the same page. It's amazing how convoluted get data from db, do something to it, send it back can get, especially if there is a queue or multiple consumers in play, when it's actually the simplest thing in the world, which is why people get over-confident and write super-confusing code.

Re: Programming Is Mostly Thinking (2014)

#208
IMHO Programming is mostly iterating (which involves thinking).

The title, read alone, with only a brief skim of the article might give PHBs the notion that you can just sit developers in a room and let them “think” for 5.5 hours and the hand them their keyboards for the last 30 minutes and get the product you want.

Re: Programming Is Mostly Thinking (2014)

#209
Too true.

I was introduced to a quote from cartoonist, Guindon: "Writing is nature’s way of letting you know how sloppy your thinking is." From Leslie Lamport.

Although in my experience, thinking is something that is not always highly valued among programmers. There are plenty of Very Senior developers who will recommend, "just write the code and don't think about it too hard, you'll probably be wrong anyway." The whole, "working code over documentation and plans," part of the Agile Manifesto probably had an outsized influence on this line of reasoning. And honestly it's sometimes the best way to go: the task is trivial and too much thought would be wasted effort. By writing the code you will make clear the problem you're trying to solve.

The problem with this is when it becomes dogma. Humans have a tendency to avoid thinking. If there's a catchy maxim or a "rule" from authority that we can use to avoid thinking we'll tend to follow it. It becomes easy for a programmer to sink into this since we have to make so many decisions that we can become fatigued by the overwhelming number of them we have to make. Shortcuts are useful.

Add to this conflict the friction we have with capital owners and the managerial class. They have no idea how to value our work and manage what we do. Salaries are games of negotiation in much of the world. The interview process is... varied and largely ineffective. And unless you produce value you'll be pushed out. But what do they value? Money? Time? Correctness? Maintainability?

And then there's my own bone to pick with the industry. We gather requirements and we write specifications... some times. And what do we get when we ask to see the specifications? A bunch of prose text and some arrows and boxes? Sure, some one spent a lot of time thinking about those arrows and boxes but they've used very little rigor. Imagine applying to build a sky scraper and instead of handing in a blueprint you give someone a sketch you drew in an afternoon. That works for building sheds but we do this and expect to build sky scrapers! The software industry is largely allergic to formalism and rigor.

So... while I agree, I think the amount of thinking that goes into it varies quite a lot based on what you're doing. 11/12? Maybe for some projects. Sometimes it's 1/2. Sometimes less.

Re: Programming Is Mostly Thinking (2014)

#210
post #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…

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.

Post reply on HN