Programming Is Mostly Thinking (2014) • Hacker News Board

Re: Programming Is Mostly Thinking (2014)

#111

Post by ChrisMarshallNY » Sun, Apr 21, 2024, 10:55 AM UTC

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 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 "Concrete Galoshes."[1]

[0] https://littlegreenviper.com/miscellany/evolutionary-design-...

[1] https://littlegreenviper.com/miscellany/concrete-galoshes/

Re: Programming Is Mostly Thinking (2014)

#112

Post by prerok » Sun, Apr 21, 2024, 11:01 AM UTC

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 could not agree more, it's rare to write a program where you know all the dependencies, libraries you will use and the overall effect to other parts of the program by heart. So, gradual design process is best.

I would point out, though, that that part also touched understanding requirements, which is many times a very difficult process. We might have a technical requirement conjured, by someone less knowledgeable about the inner workings, from a customer requirement and the resolution of the technical requirement may not even closely address the end-users' use-case. So, a lot of time also goes into understanding what it is that the end-users actually need.

Re: Programming Is Mostly Thinking (2014)

#113

Post by lwhi » Sun, Apr 21, 2024, 11:02 AM UTC

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 first on a macro level, and use mind maps and diagrams to keep things linked and organised.

As I've grown older, the importance of architecture over micro decision has become blindingly apparent.

The micro can be optimised. Macro level decisions are often permanent.

Re: Programming Is Mostly Thinking (2014)

#114

Post by marginalia_nu » Sun, Apr 21, 2024, 11:02 AM UTC

cranium wrote: post #56

Now with Github Copilot it's even worse/better – whether you like to type or not. Now it's 1) think about the problem, 2) sketch types and functions (leave the body empty), 3) supervise Copilot as it's generating the rest, 4) profit.

I think this is true for certain categories of coding more so than others.

Copilot is above all fantastic for outputting routine tasks and boilerplate. If you can, through the power of thinking, transform your problem into a sequence of such well-formed already-solved tasks, it can basically be convinced to do all the key-pressing for you.

Re: Programming Is Mostly Thinking (2014)

#115

Post by f1shy » Sun, Apr 21, 2024, 11:04 AM UTC

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?

Bit OP but probably means “no fancy silver bullet acronyms”.

Re: Programming Is Mostly Thinking (2014)

#116

Post by nycnutterjob » Sun, Apr 21, 2024, 11:05 AM UTC

[dead]

Re: Programming Is Mostly Thinking (2014)

#117

Post by f1shy » Sun, Apr 21, 2024, 11:06 AM UTC

datascienced wrote: post #66

n4r9 wrote: post #6

Earlier quoted context omitted.

Question in my head is, can LLMs think algorithmically?

Like a bad coder with a great memory, yes

The problem is the word “producing” of the parent comment, where it should be “reproducing”.

Re: Programming Is Mostly Thinking (2014)

#118

Post by macpete42 » Sun, Apr 21, 2024, 11:10 AM UTC

Code is more flexible than text for drafting the idea. Later on it will expand into a fully working solution. Defining non functional interface definitions and data objects for "scribbling" the use case works best for me.

Re: Programming Is Mostly Thinking (2014)

#119

Post by f1shy » Sun, Apr 21, 2024, 11:11 AM UTC

uraura wrote: post #94

That's also why it is difficult for me to tell what I've done in the standup meeting on another day. If I tell people I just spend time on "thinking", they will say it is too vague.

If you say "I was analysing the problem, and evaluating different solutions, and weighting the pros and cons, for example, I thought about [insert option A] but I see [insert contra here]. So I also thought about [option B]... I'm still researching in [insert source]". I do not think that should be a problem. Is what I say constantly in our daily's. And of course, eventually I deliver something.

Re: Programming Is Mostly Thinking (2014)

#120

Post by namaria » Sun, Apr 21, 2024, 11:11 AM UTC

Tade0 wrote: post #41

weatherlite wrote: post #35

Earlier quoted context omitted.

We need this to be more prevalent. But the sad fact is most architects try to justify their position and high salaries by creating "robust" software. You know what I mean - factories over factories, micro services and what not. If we kept it simple I don't think we would need many architects. We would just need experienced devs that know the codebase well and help with PRs and design processes, no need to call such a…

I was shown what it means to write robust software by a guy with a PhD in... philosophy out of all things(so a literal philosophiae doctor ). Ironically enough it was nothing like what some architecture astronauts wring - just a set of simple to follow rules, like organizing files by domain, using immutable data structures and pure functions where reasonable etc. Also I hadn't seen him use dependent types in the one…

I love how so much of distributed systems/robust software wisdom is basically: stop OOP. Go back to lambda.

OOP was a great concept initially. Somehow it got equated with the corporate driven insanity of attaching functions to data structures in arbitrary ways, and all the folly that follows. Because "objects" are easy to imagine and pure functions aren't? I don't know but I'd like to understand why corporations keep peddling programming paradigms that fundamentally detract from what computer science knows about managing complex distributed systems.