Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3 lines of code shouldn't take all day

devtails.xyz

Post reply on HN
Print view View original

91–100 of 213 posts

Re: 3 lines of code shouldn't take all day

#91

Post by petters »

vbezhenar wrote: post #69
faraaz98 wrote: post #12

Earlier quoted context omitted.

How much time did removing docker shave off?

Docker helped me to significantly increase unit test speed on one project. Each test was recreating database, run dozens of DDL scripts over and over (to ensure clean environment). I reimplemented in in a way that DDL scripts were run once, then container with database was commited to an image and that image was re-used for every test. Also multiple containers were run at once, so tests could be run simultaneously. D…

Normally you'd open a transaction, run the unit test, then roll back the transaction.

That makes each test start at the same, clean state.

Re: 3 lines of code shouldn't take all day

#92

Post by mikewarot »

userbinator wrote: post #37

This 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…

This is the same argument in favor of manual photography with film, instead of a digital SLR, or a camera phone.

While you might learn more if forced by the constraint, the opportunity cost is quite high, and these days you'll never replicate the experience of going off with your glass plates and camera packed on a mule to photograph the Sierras.

Not only all of that... but Ansel Adams spent a TON of time in the darkroom, and pretty much invented most of the techniques that Photoshop emulated in their early versions. Even faced with limited chances at exposing a negative, he iterated the heck out of the development process when making prints.

I share your view that there is value in the focus, but I don't think that anyone can afford the opportunity costs.

Re: 3 lines of code shouldn't take all day

#93

Post by globular-toast »

This is something I've worked to get right my entire career. Whenever I start a new project, I make sure the feedback loop is small. If it's a new technology for me, this can take a while to get to a process I'm happy with, but it's worth it.

Way back when I was at uni I remember watching over people's shoulders at the painfully slow iteration process. I couldn't believe not a single one thought of doing anything about it. They looked more like factory workers, endlessly turning the same handle and waiting. If you spend your time doing this, you will have no time left for creativity.

Re: 3 lines of code shouldn't take all day

#94

Post by GreenWatermelon »

DarylZero wrote: post #56
userbinator wrote: post #37

This 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…

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

Re: 3 lines of code shouldn't take all day

#95

Post by solididiot »

Was working in a similar product and it was by far the worst dev experience I've ever had. It was actually worse than what the post describes. It was like having to go through a lot of stages to get to the area I'm working and half of them not working at all - so instead I was doing bug reports on other people's areas which was only slightly familiar with. (Yeah, our CI QA gateway was a joke. Our CI in general was a joke).

It was hell. That much so that I jumped to the first half-decent role that came my way.

Something is wrong with the way we build systems that integrate too many other systems. Perhaps if we designed them with a TDD approach all the way up things would be better...or worse. Dunno. Sometimes what we're trying to do is just way into the entropy zone.

Re: 3 lines of code shouldn't take all day

#96

Post by vbezhenar »

petters wrote: post #91
vbezhenar wrote: post #69

Earlier quoted context omitted.

Docker helped me to significantly increase unit test speed on one project. Each test was recreating database, run dozens of DDL scripts over and over (to ensure clean environment). I reimplemented in in a way that DDL scripts were run once, then container with database was commited to an image and that image was re-used for every test. Also multiple containers were run at once, so tests could be run simultaneously. D…

Normally you'd open a transaction, run the unit test, then roll back the transaction. That makes each test start at the same, clean state.

1. That wouldn't work if code under test uses multiple transactions.

2. Rolling back a transaction is not exactly free.

3. Does not allow running multiple test simultaneously.

Re: 3 lines of code shouldn't take all day

#98

Post by timeon »

danuker wrote: post #84
userbinator wrote: post #37

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

Re: 3 lines of code shouldn't take all day

#99

Post by cardanome »

jmnicolas wrote: post #43
userbinator wrote: post #37

This 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 still do. Of course dabbling into REPL-based solutions in my youth might have influenced that.

For me it is crucial to always have have the code in some compile-able and testable state. I iteratively work towards the simplest, most naive solution that gets the job done. After that it is refactoring time and I form it into a proper solution.

The reason I do so is because only after having coded the naive solution, I have an concrete and proven correct understanding of the task and can pick the appropriate abstractions. I always see colleagues with an less iterative style use premature-abstractions and over engineering on the basis of "we might need it" instead of knowing.

I do invest some time into thinking about the right data structure though. (Not much about algorithms, as they mostly follow from the data structures anyway.) Also if I code a well understood problem, I might use a more top down approach.

(Not a critique of your workflow, just wanted to share mine.)

Re: 3 lines of code shouldn't take all day

#100

Post by meheleventyone »

xwolfi wrote: post #47
meheleventyone wrote: post #22

Whilst I very much agree with the premise I do think this exposes a fallacy many programmers fall for. That passing unit tests means your code actually does what you think it does. Using unit tests this way is a crutch to avoid improving startup times, implementing hot reloading and other schemes to skip gameplay. You lose an awful lot by not testing your code for the job it’s actually expected to do in situ. In game…

No unit test should be mostly to make sure the old assumptions for code you don't know still hold and warn you if you break something. Ofc if you do the code and the unit test, all you validate is that the code does what you assumed was right. But in 2 years, when someone touches something unrelated, he'll kiss you on the mouth that your test noticed an edge case that started failing. If it's not your unit test catch…

I'm not arguing against unit tests. Just that using them to speed up iteration is not a good way to approach that problem. They can of course be useful for other things. And obviously the things they don't test will still be found by the client in particular all the things you miss by not actually increasing iteration speed.
Post reply on HN