Programming Is Mostly Thinking (2014)

Post by lwhi » Tue, Apr 23, 2024, 7:26 AM UTC

eternityforest wrote: post #295

lwhi wrote: post #113

Earlier quoted context omitted.

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.

I think this is probably a lot of the value of YAGNI. The more crap you add the harder it is to fix bad architecture. And the crap is often stuff that would be trivial to add if the bad architecture weren't there, so if you fix that you can add the feature when you need it in a week.

Post by Zobat » Tue, Apr 23, 2024, 8:27 AM UTC

Post by dzonga » Tue, Apr 23, 2024, 12:38 PM UTC

swiftcoder wrote: post #310

xiwenc wrote: post #283

Earlier quoted context omitted.

Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git. This is special because most real world systems has a lot more dependencies. That’s when experimentation is required. Because one cannot know all relevant API’s beforehand and their behaviors. Therefore the only w…

> Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git. This type of developer tends to prefer building software like this. There is a whole crowd of hardcore C/C++/Rust devs who eschew taking dependencies in favour of writing everything themselves (and they mostly n…

Post by jjayj » Wed, Apr 24, 2024, 4:17 AM UTC

citizen_friend wrote: post #270

Barrin92 wrote: post #39

Earlier quoted context omitted.

it's an odd analogy because programs are complex systems and involve interaction between countless of people. With large software projects you don't even know where you want to go or what's going to happen until you work. A large project doesn't fit into some pre-planned algorithm in anyone's head, it's a living thing. diagrams and this kind of planning is mostly a waste of time to be honest. You just need to start t…

> You just need to start to work, and rework if necessary And making changes on paper is cheaper than in code.

Post by dclowd9901 » Thu, Apr 25, 2024, 4:11 AM UTC

manicennui wrote: post #325

tasuki wrote: post #87

Earlier quoted context omitted.

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

The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.