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

41–50 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#41

Post by Tade0 »

weatherlite wrote: post #35
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.

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 project we worked together on and generics appeared only when it really made sense.

Apparently it boils down to using the right tools, not everything you've got at once.

Re: Programming Is Mostly Thinking (2014)

#42

Post by hubraumhugo »

> 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 there's a way to track interruptions to showcase this.

[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/

Re: Programming Is Mostly Thinking (2014)

#43

Post by otar »

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.

Very true. There’s a huge difference developing in a well known vs. new domain. My mantra is that you have to first be experienced in a domain to be able to craft a good solution.

Right now I am pouring most of my time in a fairly new domain, just to get an experience. I sit next to the domain experts (my decision) to quickly accumulate the needed knowledge.

Re: Programming Is Mostly Thinking (2014)

#44

Post by Kwpolska »

n4r9 wrote: post #6
Almondsetat wrote: post #2

Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

Question in my head is, can LLMs think algorithmically?

LLMs can't think.

Re: Programming Is Mostly Thinking (2014)

#45

Post by fifilura »

silisili wrote: post #32
skilled wrote: post #3

This is laid out pretty early on by Bjourne in his PPP book[0], > We do not assume that you — our reader — want to become a professional programmer and spend the rest of your working life writing code. Even the best programmers — especially the best programmers — spend most of their time not writing code. Understanding problems takes serious time and often requires significant intellectual effort. That intellectual c…

I think this is mostly right, but my biggest problem is that it feels like we spend time arguing the same things over and over. Which DB to use, which language is best, nulls or not in code and in DB, API formatting, log formatting, etc. These aren't particularly interesting, and sure it's good to revisit them time and again, but these are the types of time sinks I find myself in in the last 3 companies I've worked f…

I disagree! These decisions are fundamental in the engineering process.

Should I use steel, concrete or wood to build this bridge?

The mindless coding part starts one year later when you found that your mongoDB does not do joins, and you start implementing this as an extra layer in the client side.

Re: Programming Is Mostly Thinking (2014)

#46

Post by bernardlunn »

AlotOfReading wrote: post #31
scotty79 wrote: post #23

Earlier quoted context omitted.

Was your work better or worse second time around?

Probably a bit of both, but hindsight helped. It doesn't usually end up exactly the same though. Regardless, whatever I wrote worked well enough that it outlived the company. A former client running it reached out to have it modified last year.

With writing the second version is definitely better, sucks having to redo but improvement makes it worth while.

Re: Programming Is Mostly Thinking (2014)

#47

Post by willrftaylor »

Funnily enough this happened to me.

Earlier in my career I had a very intense, productive working day and then blundered a rebase command, deleting all my data.

Rewriting took only about 20 minutes.

However, like an idiot, I deleted it again, in the exact same way!

This time I had the muscle memory for which files to open and where to edit, and the whole diff took about 5 minutes to re-add.

On the way out to the car park it really made me pause to wonder what on earth I had been doing all day.

Re: Programming Is Mostly Thinking (2014)

#48

Post by atoav »

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…

This and a high demand for my time is why I am roughly a magnitude more productive when I am in home office. Nobody bothers me there and if they do I can decide myself when to react.

If you want to tackle particularly hard problems and you get an interruption every 10 to 20 minutes you can just shelve the whole thing, because chances are you will just produce bullshit code that produces headache down the line.

Re: Programming Is Mostly Thinking (2014)

#49

Post by fifilura »

throwaway9021 wrote: post #16
Almondsetat wrote: post #2

Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

Do you have any resources for this? especially for the adhd kind - I end up going down rabbit holes in the planning part. How do you deal with information overload and overwhelm OR the exploration exploitation dilemma?

I wonder if good REPL habits could help the ADHD brain?

It still feels like you are coding so your brain is attached, but with rapid prototyping you are also designing, moving parts around to see where they would fit best.

Re: Programming Is Mostly Thinking (2014)

#50

Post by zrm »

silisili wrote: post #32
skilled wrote: post #3

This is laid out pretty early on by Bjourne in his PPP book[0], > We do not assume that you — our reader — want to become a professional programmer and spend the rest of your working life writing code. Even the best programmers — especially the best programmers — spend most of their time not writing code. Understanding problems takes serious time and often requires significant intellectual effort. That intellectual c…

I think this is mostly right, but my biggest problem is that it feels like we spend time arguing the same things over and over. Which DB to use, which language is best, nulls or not in code and in DB, API formatting, log formatting, etc. These aren't particularly interesting, and sure it's good to revisit them time and again, but these are the types of time sinks I find myself in in the last 3 companies I've worked f…

What you're referring to is politics. Different people have different preferences, often because they're more familiar with one of them, or for other possibly good reasons. Somehow you have to decide who wins.
Post reply on HN