I love building test harnesses. I think the trick is making sure that your system is built in such a way that 1. You can actually pull the core of it out to run in a different situation and 2. You keep enough of the real system such that you’re not getting lots of green passes which are going to completely fail in the real world.
3 lines of code shouldn't take all day
131–140 of 213 posts
Re: 3 lines of code shouldn't take all day
#132This 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…
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…
I think that final sentence is unduly pessimistic - after all, if practice did not play a big part in expert programmers becoming that way, what did? What hope is there for the novice who is frequently making off-by-one errors and the like?
Maybe you are saying that there is no deliberate method of practice, but I think there is: whenever you correct one of your mistakes, try to figure out how you might have written the correct code the first time. Often, it might be a boneheaded mistake, but a significant number of cases have something to learn from. Can you make an argument for the current version being correct, and the previous one not? If an API did not work the way you expected, did you overlook something in the documentation? (Maybe just that the documentation was ambiguous, and you might have realized that earlier.)
I think OP's point is that slow turnaround encourages that sort of thinking, and it does, though it is quite a cost to pay.
Re: 3 lines of code shouldn't take all day
#133This 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…
That's what you'd like to think. But the quantity vs quality pottery grading story is a tested and retold one. Also this might just go to show that you've settled for a slower pace of progress. And this term 'correctness' that indicates perfection and the enemy of perfection - bad for getting things off the ground.
Re: 3 lines of code shouldn't take all day
#134That really depends on how critical the code is. The amount of attention that has gone into optimizing ObjC message send is astounding with many man hours of top programmer time in each and every single line.
Re: 3 lines of code shouldn't take all day
#135This 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 say that practicing in a long-compile-time environment is part of improving your skills, but that once you have a certain level of skill with a language and tech stack, then it is beneficial to go back to having compile times of a few seconds or less. Generally speaking, it is far better to have a rapid iteration time to quickly test that the ground you are working on is solid as you progress.
But definitely having a phase where you are dealing with long build times helps you enhance one aspect of software development!
Re: 3 lines of code shouldn't take all day
#136Earlier quoted context omitted.
> They end up getting into a "dopamine feedback loop" that causes them to continually make tiny changes and rebuild/run, Yeah that's what I'm doing all the time. Just constantly testing the thing after every little change. If the test is fast, I like it. Probably there is some dopamine thing. I have thought of it in the past as like a slot machine. > and the code written as a result of this looks exactly like what yo…
Getting a particular piece if code running from the first time is so unexpected that I'm like "Huh... that's pretty cool" everytime it happens. no need to spend 3 more minutes looking at the code when a 2 seconds build will tell me there's a Segmentation fault right there, or when Valgrind will tell me I missed a free ().
Only a small fraction of segmentation-fault-causing errors will be revealed in 2 seconds of testing. Thinking about all the ways your code could fail, and being able to keep a mental track of the constraints you need to observe, is a useful skill to acquire.
Re: 3 lines of code shouldn't take all day
#137This 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…
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.
Re: 3 lines of code shouldn't take all day
#138This 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…
[deleted]
Re: 3 lines of code shouldn't take all day
#139The "sub-second response loop flow state" he mentions here is "the doherty threshold"[1] just applied to programing as a particular user experience.
After working at a CDN that delivered a couple hundred kb objects in milliseconds around the world I thought "code is data, so why cant code be updated in milliseconds?" I tried starting a startup that could do this, treat code as data, and therefore achieve sub-second round-trip trial-and-error loops.
Did not pan out, but to be honest we never really got to testing that thesis. I still think it could be amazing, just not sure how much of the lang/ide/build/test/deploy/validate cycle you could integrate and how much you'd have to build.
IMHO this is the main thing that made PHP successful. The "edit a file -> alt-tab -> click refresh" test loop being faster than you could click.
Re: 3 lines of code shouldn't take all day
#140This 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…
Welcome to hell my colleagues barely can grok git so youre in unicorn country suck up that fresh valley air.