4 ms·

I really don't agree with the idea that expert time would just be spent typing, and I'd be really surprised if that's the common sentiment around here. An expe

I really don't agree with the idea that expert time would just be spent typing, and I'd be really surprised if that's the common sentiment around here. An expert reasons, plans ahead, thinks and reasons a little bit more before even thinking about writing code. If you are measuring productivity by lines of code per hour then you don't understand what being a dev is.

brailsafe 1y ago
> I really don't agree with the idea that expert time would just be spent typing, and I'd be really surprised if that's the common sentiment around here. They didn't suggest that at all, they merely suggested that the component of the expert's work that would otherwise be spent typing can be saved, while the rest of their utility comes from intense scrutiny, problem solving, decision making about what to build and why, and everything else that comes from experience and domain understanding.
- fc417fc802 1y ago
  It's not just time spent typing. Figuring out what needs to be typed can be both draining and time consuming. It's often (but not always) much easier to review someone else's solution to the problem than it is to solve it from scratch on your own. Oddly enough security critical flows are likely to be one of the few exceptions because catching subtle reasoning errors that won't trip any unit tests when reviewing code that you didn't write is extremely difficult.
  - oblio 1y ago
    The problem is, building something IS the destination. At least the first 5-10 times. Building and fixing along the way is what builds lasting knowledge for most people.
  - nipah 1y ago
    > It's not just time spent typing. Figuring out what needs to be typed can be both draining and time consuming. It's often (but not always) much easier to review someone else's solution to the problem than it is to solve it from scratch on your own. This is EXTREMELY false. When you write the code you [remember] it, it's fresh in your head, you [know] what it is doing and exactly what it's supposed to do. This is why debugging a codebase you didn't wrote is harder than one you wrote, if a bug happens you know exactly the spots it could be happening at and you can easily go and check them.
- kiitos 1y ago
  Time spent typing is statistically 0% of overall time spent in developing/implementing/shipping a feature or product or whatever. There's literally no reason to try to optimize that irrelevant detail.
  - chipsrafferty 1y ago
    No it's not. It's close to 50%.
    - kiitos 1y ago
      If that's the case for you, then let me tell you, you're doing something wrong. It might not be you, it might be your team, or organization, but this is definitely not a normal experience.
victorbjorklund 1y ago
Yea, and you still do that now. Lets say you spend 30% of your time coding and the rest planning. Well, now you got even more time for planning.

brailsafe 1y ago

> I really don't agree with the idea that expert time would just be spent typing, and I'd be really surprised if that's the common sentiment around here. They didn't suggest that at all, they merely suggested that the component of the expert's work that would otherwise be spent typing can be saved, while the rest of their utility comes from intense scrutiny, problem solving, decision making about what to build and why, and everything else that comes from experience and domain understanding.

fc417fc802 1y ago
It's not just time spent typing. Figuring out what needs to be typed can be both draining and time consuming. It's often (but not always) much easier to review someone else's solution to the problem than it is to solve it from scratch on your own. Oddly enough security critical flows are likely to be one of the few exceptions because catching subtle reasoning errors that won't trip any unit tests when reviewing code that you didn't write is extremely difficult.
- oblio 1y ago
  The problem is, building something IS the destination. At least the first 5-10 times. Building and fixing along the way is what builds lasting knowledge for most people.
- nipah 1y ago
  > It's not just time spent typing. Figuring out what needs to be typed can be both draining and time consuming. It's often (but not always) much easier to review someone else's solution to the problem than it is to solve it from scratch on your own. This is EXTREMELY false. When you write the code you [remember] it, it's fresh in your head, you [know] what it is doing and exactly what it's supposed to do. This is why debugging a codebase you didn't wrote is harder than one you wrote, if a bug happens you know exactly the spots it could be happening at and you can easily go and check them.
kiitos 1y ago
Time spent typing is statistically 0% of overall time spent in developing/implementing/shipping a feature or product or whatever. There's literally no reason to try to optimize that irrelevant detail.
- chipsrafferty 1y ago
  No it's not. It's close to 50%.
  - kiitos 1y ago
    If that's the case for you, then let me tell you, you're doing something wrong. It might not be you, it might be your team, or organization, but this is definitely not a normal experience.

victorbjorklund 1y ago

Yea, and you still do that now. Lets say you spend 30% of your time coding and the rest planning. Well, now you got even more time for planning.