News for hackers. Stuff that matters.
Re:Why is it so hard to see code from 5 minutes ago? by tluyben2 on Friday February 19, 2021 @01:28AM (#26190350)
> 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.

Re:Why is it so hard to see code from 5 minutes ago? by mosselman on Friday February 19, 2021 @03:21AM (#26190813)
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.
Re:Why is it so hard to see code from 5 minutes ago? by tluyben2 on Friday February 19, 2021 @04:00AM (#26191026)
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.
Re:Why is it so hard to see code from 5 minutes ago? by pjc50 on Friday February 19, 2021 @03:10AM (#26190759)
> productivity of an employee by keystrokes, screen changes and # of commits.

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

Re:Why is it so hard to see code from 5 minutes ago? by piva00 on Friday February 19, 2021 @04:40AM (#26191253)
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.

Re:Why is it so hard to see code from 5 minutes ago? by Tade0 on Friday February 19, 2021 @06:16AM (#26191864)
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.

Re:Why is it so hard to see code from 5 minutes ago? by collyw on Friday February 19, 2021 @07:10AM (#26192255)
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.
Re:Why is it so hard to see code from 5 minutes ago? by jacquesm on Friday February 19, 2021 @10:36AM (#26194232)
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.