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

241–250 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#241

Post by ant6n »

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…

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

How very biblical. “And Torwalds saw everything that he had made, and behold, it was very good. And there was evening, and there was morning—the sixth day.”

Re: Programming Is Mostly Thinking (2014)

#242

Post by CM30 »

nickff wrote: post #28
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.

I’ve often found it alarming to see how much better the re-do is. I wonder whether I should re-write more code.

I think this was the reasoning behind the adage "make it work, make it right, make it fast" (or something along those lines).

You'd do a fairly rough draft of the project first, just trying to make it do what you intend it to. Then you'd rewrite it so it works without glaring bugs or issues, then optimise it to make it better/more performant/more clearly organised after that.

Re: Programming Is Mostly Thinking (2014)

#243

Post by kaba0 »

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?

The real world bank processes themselves are significantly more complicated than for any one person to hold it in their head. Simplification is important but only until the point it still completes 100% of the required functionality.

Code also functions as documentation for the actual process. In many cases “whatever the software do” is the process itself.

Re: Programming Is Mostly Thinking (2014)

#244

Post by demondemidi »

hgomersall wrote: post #40
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…

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. Literally the worst kind of programmers to have on a project.

Re: Programming Is Mostly Thinking (2014)

#245

Post by travisjungroth »

devsda wrote: post #164
hubraumhugo wrote: post #42

> how can you experiment with learning on-the-job to create systems where the thinking is optimized? Best optimization is less interruptions as reasearch shows their devastating effect on programming: - 10-15 min to resume work after an interruption - A programmer is likely to get just one uninterrupted 2-hour session in a day - Worst time to interrupt: during edits, searches & comprehension I've been wondering if th…

If you ask a manager to hold an hour's meeting spread across 6 hours in 10 min slots you will get the funniest looks. Yet developers are expected to complete a few hours of coding task in between an endless barrage of meetings, quick and short pings & syncups over slack/zoom. For the few times I've had to work on the weekends at home, I've observed that the difference in the quality of work done over a (distraction f…

> If you ask a manager to hold an hour's meeting spread across 6 hours in 10 min slots you will get the funniest looks.

This is a great analogy I haven’t heard it before. They think it’s like that quick work where you check your calendar and throw in your two cents on an email chain. It’s not. Much more like holding a meeting.

Re: Programming Is Mostly Thinking (2014)

#246

Post by kaba0 »

anal_reactor wrote: post #73
lordnacho wrote: post #38

This is why domain knowledge is key. I work in finance, I've sat on trading desks looking at various exchanges, writing code to implement this or that strategy. You can't think about what the computer should do if you don't know what the business should do. From this perspective, it might make sense to train coders a bit like how we train translators. For example, I have a friend who is a translator. She speaks a bun…

> This is why domain knowledge is key. Yeah but in my country all companies have a non-compete clause which makes it completely useless for me to learn any domain-specific knowledge because I won't be able to transfer it to my next job if current employer fires me. Therefore I focus on general programming skills because these are transferable across industries.

In some countries (Austria), the company that you have a non-compete clause with should pay you a salary if you can’t reasonably be employed due to it. So it is not enforced most of the time.

Re: Programming Is Mostly Thinking (2014)

#248

Post by graemep »

tibbar wrote: post #214
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;…

You make me feel a lot better about my skill set!

Re: Programming Is Mostly Thinking (2014)

#249

Post by graemep »

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

Post reply on HN