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

201–210 of 213 posts

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

#201

Post by yashap »

commandlinefan wrote: post #197
yashap wrote: post #194

Earlier quoted context omitted.

FWIW, I always write tests for my changes, as long as they have any impact on behaviour (i.e. not writing tests for adding a little logging or metrics, but am for any new or modified business logic). Every single dev having a strong commitment to automated testing is a requirement for an environment where you can sometimes get away without manual testing. For any changes where it's not obvious that it'll work in prac…

> I always write tests for my changes I wasn't saying you were one of those people - just saying I've worked with a lot of them.

Hah fair, I have too :) But generally have found it not hard to convert them to embracing automated testing, as long as there's a strong automated testing culture at the company.

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

#202

Post by munificent »

ChrisMarshallNY wrote: post #124

> 3 lines of code shouldn't take all day Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write). The complaint seems to center on CI/D services that provide inefficient build times. These increase the pain of "round-trip" implement-test-refactor. That's quite valid, as this is how we tend to work, these days (at least, that's how I wor…

> Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write).

You're missing the point of the article. It's not about valuing quantity of code. It's about valuing minimizing the time it takes to determine what you want the code to be.

If it takes you a 30 minute compile loop to add a line of code, it's also going to take a 30 minute compile loop to refactor and eliminate a line of code.

The latter is actually worse. When your iteration time is high, developers will deal with it and push through as necessary to get features implemented because they have to make the software do a certain thing. But they will absolutely not struggle through a shitting iteration cycle if the only result is cleaner refactored code.

If you want nice codebases, you need a nice iteration cycle.

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

#203

Post by ChrisMarshallNY »

munificent wrote: post #202
ChrisMarshallNY wrote: post #124

> 3 lines of code shouldn't take all day Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write). The complaint seems to center on CI/D services that provide inefficient build times. These increase the pain of "round-trip" implement-test-refactor. That's quite valid, as this is how we tend to work, these days (at least, that's how I wor…

> Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write). You're missing the point of the article. It's not about valuing quantity of code. It's about valuing minimizing the time it takes to determine what you want the code to be. If it takes you a 30 minute compile loop to add a line of code, it's also going to take a 30 minute compil…

> You're missing the point of the article.

Actually, I didn't. Just sayin'.

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

#204

Post by tomrod »

bipson wrote: post #71
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…

Came here to say this. I even see the mindset spreading to other activities, like writing an abstract, paper, proposal or preparing slides: I regularly (more often than not) see students using their supervisors as "CI-chain", submitting iterations with lots of stupid errors, half-baked sentences, unclean structure... because they learned to hit CTRL-b and see what comes back. Of course there are reasons to talk about…

What does CTRL-b map to? Paste?

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

#205

Post by greggman3 »

dan353hehe wrote: post #5

Agree with this so much. One of the main things that I try to do is ensure that the turn around time between testing and writing code is as short as possible. As an example I inherited a codebase about 2 years ago that would take 15 minutes to run the test suite. It was painful. It was just long enough that it would waste an entire day just trying to implement a simple feature. The project was behind schedule and no…

A few more things I'd add

The OP mentioned using tests instead of the entire game. You could also consider splitting the tests. The code base I'm on now has 9 test suites. It would be much slower if all 9 were merged into 1. So, if you have a monolithic test suite consider breaking it apart.

Our team also has a CI/CQ so I never run all the tests myself. I run the tests I think my change affects. When it passes I upload to the CQ and let it run all the tests. Then I go work on something else and check later if it all passd.

In games there is often no need to run on the target hardware for 95% of tasks so choose the hardware that's fastest. In other words, if you're making a game that can run on PC, PS5, XBox then develop on PC and only switch to PS5,XBox when you have to (platform specific features, checking perf, etc.). For VR for example I'd test via PC on a link cable or on a Vive/Index/Rift and only test on standalone Quest when I absolutely had to. So much time saved.

The same is true in other places. I work a very large project that run on many platforms (Windows, Mac, Linux, Android). Building and testing on Linux is 10x faster than Windows, 40x faster than Mac. Once I found that out I switched to Linux for my day to day work and only pull out the other devices if the stuff I'm working on is platform specific.

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

#206

Post by munificent »

ChrisMarshallNY wrote: post #203
munificent wrote: post #202

Earlier quoted context omitted.

> Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write). You're missing the point of the article. It's not about valuing quantity of code. It's about valuing minimizing the time it takes to determine what you want the code to be. If it takes you a 30 minute compile loop to add a line of code, it's also going to take a 30 minute compil…

> You're missing the point of the article. Actually, I didn't. Just sayin'.

Sorry to misinterpret you.

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

#207

Post by johnny22 »

patrakov wrote: post #164
GreenWatermelon wrote: post #94

Earlier quoted context omitted.

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

Well, yesterday I made a rather significant change to the code. Essentially, a reimplementation of an existing function in a completely different way, to avoid a memory consumption issue that cannot be solved in the old approach. 68 insertions, 15 deletions. It, unexpectedly, worked correctly and passed all tests from the first attempt, even though there are threads involved, and they are my weak point. But I didn't…

or just feel both.. at the same time.

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

#208

Post by nanoscopic »

Suppose you maintain a highly scaled service. Suppose it has a bug. Finding and fixing 3 lines of code that caused a problem that was costing the company money by the hour/minute could be well worth it and a great accomplishment in one day.

The number of lines of code is irrelevant. The impact is what matters.

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

#209

Post by vbezhenar »

bpicolo wrote: post #130
vbezhenar wrote: post #96

Earlier quoted context omitted.

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.

> 3. Does not allow running multiple test simultaneously. It does with almost every form of transaction isolation mode. Read uncommitted in Postgres still behaves as read committed, so in Postgres you're never missing the mark here. > 1. That wouldn't work if code under test uses multiple transactions. A lot of abstractions interpret nested transactions as save points for this reason. It's not the only valid pattern,…

I still think that tests would be flaky without complete isolation in a different database instances. Transaction isolation is nice, but for serial isolation you would get errors when you can't commit that transaction and you'll need to repeat the test (which might cause further issues) and for lesser isolation levels you would get some phantom reads which might manifest as a rare test failures which is a terrible thing, because you can't reproduce it.

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

#210

Post by bpicolo »

vbezhenar wrote: post #209
bpicolo wrote: post #130

Earlier quoted context omitted.

> 3. Does not allow running multiple test simultaneously. It does with almost every form of transaction isolation mode. Read uncommitted in Postgres still behaves as read committed, so in Postgres you're never missing the mark here. > 1. That wouldn't work if code under test uses multiple transactions. A lot of abstractions interpret nested transactions as save points for this reason. It's not the only valid pattern,…

I still think that tests would be flaky without complete isolation in a different database instances. Transaction isolation is nice, but for serial isolation you would get errors when you can't commit that transaction and you'll need to repeat the test (which might cause further issues) and for lesser isolation levels you would get some phantom reads which might manifest as a rare test failures which is a terrible th…

That's the best part - tests never commit data. Everything that happens is within the transaction, and only visible to that test.

It doesn't let you test interactions of parallelized code doing independent/interacting database workloads, but most web/CRUD apps don't do that.

Post reply on HN