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

181–190 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#181

Post by swat535 »

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…

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 multiple cycles on Red -> Green -> Refactor until I end up being happy with.

Does anyone else work like this?

Re: Programming Is Mostly Thinking (2014)

#182

Post by devsda »

paulryanrogers wrote: post #168
devsda wrote: post #143

Earlier quoted context omitted.

The bigger problem here is the manager getting involved with code. Even when done with good intentions, managers being involved in code/reviews almost always ends up being net negative for the team.

Why?

There are many reasons. First a manager is not a peer but brings in a sense of authority into the mix so the discussions will not be honest. Manager's inputs have a sense of finality and people will hesitate to comment or override them even when they are questionable.

There are human elements too. Even if someone has honest inputs, any (monetary or otherwise) rewards or lack of them will be attributed to those inputs (or lack of them). Overall, it just encourages bad behaviours among the team and invites trouble.

These should not happen in an ideal world but as we are dealing with people things will be far from ideal.

Re: Programming Is Mostly Thinking (2014)

#183

Post by interpol_p »

In my experience quite a lot of programming is thinking, though quite a lot is also communication, if you work in a team

Typing out comments on PRs, reproducing issues, modifying existing code to test hypotheses, discussing engineering options with colleagues, finding edge cases, helping QA other tickets, and so on. I guess this is all "thinking," too, but it often involves a keyboard, typing, and other people

A lower but still significant portion is "overhead." Switching branches, syncing branches, rebasing changes, fixing merge conflicts, setting up feature flags, fixing CI workflows, and so on

Depending on the size of the team, my gut feel for time consumption is:

Communication > Thinking > Writing Code > Overhead

Re: Programming Is Mostly Thinking (2014)

#184

Post by noisy_boy »

JKCalhoun wrote: post #169
ChrisMarshallNY wrote: post #111

Earlier quoted context omitted.

I tend to iterate. I get a general idea, then start writing code; usually the "sticky" parts, where I anticipate the highest likelihood of trouble. I've learned that I can't anticipate all the problems, and I really need to encounter them in practice. This method often means that I need to throw out a lot of work. I seldom write stuff down[0], until I know that I'm on the right track, which reduces what I call "Concr…

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…

I think once you are an experienced programmer, beyond being able to break down the target state into chunks of task, you are able to intuit pitfalls/blockers within those chunks better than less experienced programmers.

An experienced programmer is also more cognizant of the importance of architectural decisions, hitting the balance between keeping things simple vs abstractions and the balance between making things flexible vs YAGNI.

Once those important bits are taken care of, rest of it is more or less personal style.

Re: Programming Is Mostly Thinking (2014)

#186

Post by bakuninsbart »

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…

Same, and since we are on the topic of measuring developer productivity; usually my bad-but-kinda-working prototype is not only much faster to develop, it also has more lines of code, maximizing my measurable productivity!

Re: Programming Is Mostly Thinking (2014)

#188

Post by nick__m »

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 completely agree with you. This article is on the right track but it completely ignore the importance of exploratory programming to guide that thinking process.

Re: Programming Is Mostly Thinking (2014)

#189

Post by sotix »

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. > Lawyers and accountants are another profession where you have a language gap.

I fully agree with you. However, my experience as a software engineer with a CPA is that, generally speaking, companies do not care too greatly about that domain knowledge. They’d rather have a software engineer with 15 years working in accounting-related software than someone with my background or similar and then stick them into a room to chat with an accountant for 30 minutes.

Re: Programming Is Mostly Thinking (2014)

#190

Post by mejutoco »

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.

On the other side the hooks system of git is very good api design imo.
Post reply on HN