> the wrong way is not constructive.

Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It both works, but I have several converts who now work like me and actually enjoy it more (not to mention far less chance of RSI).

Whatever works for you I would say.

What is a bad thing though is that it also has to do with the pressure put by WFH in some companies and sites like Upwork => a lot of 'managers' (and sorry, I cannot say anything positive about these people, but their number increased rapidly during Covid in my experience) measure productivity of an employee by keystrokes, screen changes and # of commits. Even though I finish more tasks in a day than most of my colleagues in our projects, according to those metrics, especially keystrokes and screen changes, it looks like I'm doing 'nothing'. Whatever.

It sounds like you are a software engineer. My advise for you being confronted with these metrics is to look around a bit at other workplaces. I am not saying that you should quit, but it doesn't need to be this way.

Well, I don't have that issue, but I know quite a lot of people whose workplace changed to that. I would refuse to work like that, not to mention that keyboard logging etc is not allowed here in the workplace.

> productivity of an employee by keystrokes, screen changes and # of commits.

Aaargh, that's the most quality destroying metric possible.

The most easily gamed as well... I have no idea how these people thinking about introducing a metric to measure others don't realise that whenever that happens it just becomes another game.

It really isn't that hard to know that through experience and a little bit of forethought.

The other day I introduced this idea to a team member.

We have a separate budget for "development" and "hardening" - these two are actually stages - one starts only after the other ends and that moment is already precisely scheduled. No QA team so far.

So we play this little game of delivering something, anything and allow ourselves to leave some details behind.

I know of multiple problems in my code which made it past review, because there's no incentive to block merging on grounds other than code style, and maybe some glaring issues.

My gut feeling is that this approach is more expensive.

My guess is that the code that was thought through first will be better (easier to understand by the next developer) than the code generated by many iterations.

Most of the times you'd be right. But some of the times you'd be devastatingly wrong. You always need to check your assumptions about runtime, expected behavior and so on and there is only so much modeling you can do in your head. At some point - if the scope is too large to fit in your head at once - you will need to resort to divide and conquer, implement the part that you understand, regroup, then do the rest. And before you know it halfway into doing 'the rest' you will realize a better way to approach the problem.

I actually think this is part of the problem- there is excellent tooling for making programming much, much easier, but many programmers are unaware of how to use them.

When I was an undergrad, I wrote code in a text editor without syntax highlighting, I debugged using log statements, and I manually tested every change by running my program manually with different inputs.

Of course those are all fixed by pretty basic things, but you would be surprised how many programmers literally don’t know how to use the tools they have, or are unaware of them. And some tools are downright hard to grok- git is definitely one of those.

> I actually think this is part of the problem- there is excellent tooling for making programming much, much easier, but many programmers are unaware of how to use them.

Isn’t that just called “experience”? It’s understandable that junior engineers don’t know these tools exists, but most will learn them after a few years.

If you’re curious and interested enough, you’ll wonder if there are better ways to do things. Or talk to more experienced people and ask them how they do things.

I don’t think this is a “problem”, it’s just part of the process of becoming an experienced engineer.

Development often times entails a lot of trial and error, and there is nothing wrong with that. If you have fast iteration cycles, you can fail many times before you settle on an optimal solution.

That usually depends if you are writing something from scratch, or wrestling with other peoples libraries.

"Sounds like trial and error"

Isn't that what coding is?

Maybe to some extent, but most of coding in my experience is planning things out, figuring out exactly what you're trying to do and then just writing it.

Bug fixes have a bit more trial and error to them obviously, but it's usually not reading entire code blocks.

If some function becomes too gordian I start working on a refactoring branch to fix it.

I also use 2+ monitors so I experience very little of the code deletion issues referenced here.

People obviously have different preferred ways to think, and this holds for programming just like for math or any other cognitive endeavour. Compilers, type systems, REPLs and so on are specifically designed to be thinking aids, and it seems to me that using them to their full extent to augment one’s cognition is a perfectly valid way to write code.

I try to rememberf my local history view in the editor, it sometimes give a better overview.