4 ms·

Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory.

Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming in with their own anecdotes, or tools they've discovered that help alleviate the same issue in other ways. If you've never had to UNDO/REDO a block of code to revisit a previous state before moving forward again, kudos. But suggesting those that do are somehow going about programming in the wrong way is not constructive.

JoeyJoJoJr 6y ago
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.
- collyw 6y ago
  That usually depends if you are writing something from scratch, or wrestling with other peoples libraries.
balp 6y ago
I try to rememberf my local history view in the editor, it sometimes give a better overview.
tluyben2 6y ago
> 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.
- pjc50 6y ago
  > productivity of an employee by keystrokes, screen changes and # of commits. Aaargh, that's the most quality destroying metric possible.
  - piva00 6y ago
    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.
    - Tade0 6y ago
      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.
  - deleted 6y ago
    [deleted]
- mosselman 6y ago
  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.
  - tluyben2 6y ago
    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.
jack_riminton 6y ago
"Sounds like trial and error" Isn't that what coding is?
- crowbahr 6y ago
  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.
  - Sharlin 6y ago
    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.
albertgoeswoof 6y ago
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.
- woutr_be 6y ago
  > 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.
Person5478 6y ago
I do it very occasionally, usually when I realize I need some form of code that I've deleted. I'll undo, copy the code, redo up to where I'm at, then paste and edit as necessary. But I don't do this every 5 minutes, that's just mind boggling. And my reason for doing it isn't that I can't remember or couldn't recreate, it's that I use copy/paste a lot to avoid errors from typo's and the like. It just seems weird to have to do this that often.

JoeyJoJoJr 6y ago

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.

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

balp 6y ago

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

tluyben2 6y ago

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

pjc50 6y ago
> productivity of an employee by keystrokes, screen changes and # of commits. Aaargh, that's the most quality destroying metric possible.
- piva00 6y ago
  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.
  - Tade0 6y ago
    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.
- deleted 6y ago
  [deleted]
mosselman 6y ago
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.
- tluyben2 6y ago
  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.

jack_riminton 6y ago

"Sounds like trial and error" Isn't that what coding is?

crowbahr 6y ago
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.
- Sharlin 6y ago
  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.

albertgoeswoof 6y ago

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.

woutr_be 6y ago
> 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.

Person5478 6y ago

I do it very occasionally, usually when I realize I need some form of code that I've deleted. I'll undo, copy the code, redo up to where I'm at, then paste and edit as necessary. But I don't do this every 5 minutes, that's just mind boggling. And my reason for doing it isn't that I can't remember or couldn't recreate, it's that I use copy/paste a lot to avoid errors from typo's and the like. It just seems weird to have to do this that often.