Is it Better to Code with a Results-Oriented or Process-Oriented Approach?

help
1

While thinking today, I realized that some of the things I've been doing have been result-oriented what mattered was just the output. I noticed that when I focus purely on the output, I end up not caring at all about infrastructure and design decisions. Whereas if I had taken a process-oriented approach, I would have reflected on what I was writing as I went, and I would have learned much more.

I'm not sure if this counts as something philosophical, but I wanted to ask anyway. I don't use social media, so this was the only place I could think to ask.

2

Is this a trap? LOL Are you trying to see how many super OOP guys pop their heads up and complain?

Ultimately, this sounds in part like some of the complaints against OOP.

Have I just revealed myself as a heretic to the OOP faithful? LOL

3

Honestly, I hadn't thought about it from an OOP angle at all I just realized through Rust that I need to be more process-oriented and make decisions upfront, whereas in OOP languages I always felt like the result mattered more, so I'd write code chasing the outcome without caring about anything along the way.

But to be fair, I think this era we live in is very results-driven in general even though the process is always more important, in my opinion. When I first started learning programming, it was C while my older brother wanted me to just learn PHP and quickly build a website instead. People around me made fun of me too ("what, you gonna build a computer or something?"). Looking back, that's basically the same results-vs-process tension: everyone around me wanted to see a quick, usable output, while I was drawn to understanding things from the ground up, even if it took much longer to show anything for it.

4

I hear ya concerning decisions up front! Well said.
But I do also believe that a goal is for these things (decisions) to become second nature with whatever tool (languate) we are using.

Perhaps what you are noticing is how Rust has forced you think?

5

Good point, I agree with that. Ideally this shouldn't be a 'Rust thing' it should just be how I approach programming in general, and Rust was maybe just what exposed the gap for me.

6

Define "better"? If all you want is for your code to do X, then all things considered, getting it to do the X for you as soon as humanly possible is a perfectly sensible goal to have.

On the other hand, if after getting it to do X you came to realize that what you actually want is X + Y, but changing anything in the spaghetti mess you've coded up up to this point is an excruciatingly painful experience; which made you realize in turn that what you actually actually wanted was to retain the ability to change, swap, replace, modify, update, alter, test, delete, and remove any one piece of it with the minimum amount of friction and/or cognitive load; in other, more traditional terms, to be able to maintain your code, going forward; then I reckon you already know the answer.

Neither approach is "inherently" superior to the other. Hell, with the way a solid chunk of the entire industry today already only caring about the number of LoC you can pump out with the help of the latest/greatest token predictor out there, one could argue that the only thing that matters is the result. I'd humbly disagree, but then I'm not a CEO and/or an investor in any of the trillion-dollar valuation behemoths ushering us into the new "age of AI", so what would I know? [1]

For learning, understanding, maintaining, and retaining the "ownership" of your project, however - I'd definitely recommend spending some time up front thinking, planning, and accounting for the likeliest vector of change your codebase will be subject to for all the foreseeable future. It might make things much easier, and simpler, and a whole lot more bearable to boot.

In the beginning, all you want is results. In the end, all you want is control. /src

  1. It is not as if any of those charming folk are in any way incentivized to promote that very line of thought, to begin with. That's how you know you can trust them with your entire career, after all. ↩︎

7

Just wanted you to know not being a CEO or investor doesn't make your reasoning any less valid. If anything, you're the one who actually has to live with the code you write, so your perspective on maintainability is grounded in real experience, not boardroom incentives. A good argument doesn't need a title behind it to hold up, and yours clearly does.

8

I'm going vote for Results oriented.

Why? Because results are the things we actually want or need. Process is only the way we choose to obtain those results. If there are no useful results the process is pointless. The process should be selected when the desired results are known.

To my mind a lot of "process" that is recommended or demanded is not actually needed for the desired results. People get pressured into employing this process or that because. management demands it or "that's the way we have always done things", or just for not thinking about it much.

Hopefully withe experienc one gets a feel what processes are required or best suited to the required results.

Which of course means I'm suggesting that one thinks about what they are going do (in terms of actually writing code) before actually doing it. Which is itself a process. So look at that, I'm talking myself around in circles....