Coming across this article and reading it while waiting for a long build was very ironic
3 lines of code shouldn't take all day
141–150 of 213 posts
Re: 3 lines of code shouldn't take all day
#142This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…
Wow, I never quite formalised this in my head, but I think it's true!
At least for small delays, say 30s-3m, I'm not tempted to go for that (other) dopamine shot of checking messages or whatever at all. I keep thinking about the problem I'm solving, what to try if the thing I'm currently trying doesn't work, and so on. I don't remember ever feeling limited with such cycles - literally only when fiddling around with CSS, which I quite often just do in the browser's dev tools for the fastest possible feedback cycles.
Re: 3 lines of code shouldn't take all day
#143This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…
I would not conflate slow feedback loops with intentional breaks
For me slow feedback loops push me into dopamine seeking activities, intentional breaks push me into relaxation and deep thought
Recently I got a treadmill desk and the physical exertion reminds me to take breaks where I can get off and relax and potentially think about a problem
Slow tests running causes me to not write tests and look at YouTube
Re: 3 lines of code shouldn't take all day
#144If I had to order the things that make me productive, starting with the most important: 1. It’s easy to have a fair amount of confidence in changes without even needing to run them. Strong static typing, good/clean abstractions, local reasoning - little to no mutability, code is mostly pure functions with side effects pushed to the edges. Being able to just write a bunch of code without needing to run it at all (and…
I agree with your list but really need 4 myself to be a happy camper. Often it's neglected once 2 is in place as most don't seem to find any value by it, or don't care to maintain it. I find that having the possibility to run the real thing (in some capacity) in a cozy development environment with debugger is very useful to quickly learn how parts in the system interact with each other. I have a hard time doing that…
Oh yeah, I definitely use 4 frequently too - for basically any bug ticket, or for any more complex change/new feature, I want to run the full app. Having this be fast/easy/reliable is huge. If it’s a service oriented app, and I’m modifying a single service, I especially love tools like https://www.telepresence.io/ - run my service locally, with an “auto recompile/reload on save” setup (and sometimes a debugger), while all the other services are running in the cloud, but communicate with my local service.
However, a lot of changes are just small, trivial tweaks, and if 1 and 2 are strong, I don’t even have to bother with 3 or 4.
Re: 3 lines of code shouldn't take all day
#145I worked in lots of projects like this. The most amazing part is most devs didn´t care. Never understood why.
In one of those projects the code got so big and bloated that it took around 1 minute (sometimes more) to move from one line to the next while debugging. For me it was a torture, it was ok for most.
Re: 3 lines of code shouldn't take all day
#146This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…
Your example is valid for beginners but once you're getting experience you don't code like that anymore. After 13+ years of C#, on simple projects I can code for a couple hours without compiling and get the pleasant surprise that my code work the first time I run it. And I'm certainly not a genius, I'm a 1X programmer.
I see you follow the Tao -- beyond all techniques!
Re: 3 lines of code shouldn't take all day
#147This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…
The drawback with long time to iterate is you have to be in flow to do things. That's non-negotiable in environments with a lot of meetings.
There's also a "sketching" element with faster iteration. On slower iterations, you're engineering. The engineering skill is often underdeveloped but sketching is more valuable without a dedicated designer.
Also some things are poorly documented, often things like UI and browser code or legacy support for say, older Android OS. So even if you have your calculations right it ends up wrong.
Re: 3 lines of code shouldn't take all day
#148Earlier quoted context omitted.
I see it like driving stick vs. automatic. Sure, with stick you become aware of how the car works, the engine, torque and clutch, and you get more control. This might be good for learning. But automatic lets you pay more attention to the road ahead, whether you are a new or experienced driver.
Interesting. I was thinking that you pay more attention with manual. The point of manual shifting is not in how the car works. The point is in knowing what will happen before it will happen.
Here is a chart I found in a quick search:
https://www.researchgate.net/figure/A-comparison-of-accident...
From the paper:
> whether looked at by human factors leading to accidents, by driver age or by accident type and age, the results all support the conclusion that, among all accidents, the accident rate for AT vehicles is twice as high as for MT vehicles except for head-on collisions
Re: 3 lines of code shouldn't take all day
#149This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…
Many early programers, Knuth etc, have described how writing programs on punch cards, submitting the job, picking up the results much later had a big influence on how they thought about programing. The lack of immediate feedback, counterintuitively, made them better programers it seems.
Re: 3 lines of code shouldn't take all day
#150Earlier quoted context omitted.
Isn't that just what it's like to be a beginner? I think it's difficult to grasp when you've been coding for a few decades that new developers don't immediately see what effects a piece of code has, they can't just look at a loop for 2 seconds and say "oh, there's an off-by-one there". Sure, I can worry about the big picture while I'm typing out the code because I don't need to pay much attention when I'm typing out…
> Experienced developers typically don't sit like Hari Seldon predicting branches 50k instructions into the future with some extremely elaborate grand master plan This made my day, thank you.