Live data from Hacker News

3 lines of code shouldn't take all day

devtails.xyz

1–10 of 213 posts

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

#4
Heh. I remember a time back when I worked at Google, and we're using a proprietary internal language to construct some monitoring stuff. It took three of us a day to implement some simple thing that was a line or two of code, so opaque and intractable the language was. When we got it to do what we expected, we still weren't quite sure it was really correct. It was really kind of an existential moment where we collectively wondered, "wtf are we doing?"

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

#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 one wanted to work on it because it just took too long to do anything.

So I spent a few weeks running benchmarks on the tests and figuring out where the slow down was. I did a bunch of different things, reusing SQL tables, only truncating tables ones that were used, refactored how the tests worked, removed some code so that docker was not needed to do the testing, etc.

I got those tests running in 3 seconds down from 15 minutes. And that changed the whole velocity of the project.

Always sharpen your ax.

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

#6
I love this. I made an ask HN post about testing practices for games[0]. The answers I got are interesting and an opportunity to reflect. There are clearly some differences in programming cultural practices.

I’m of the opinion that applying great testing practices to unity programming is very important. It’s been fun synthesizing ideas I’ve encountered into my hobby game dev career.

I’m glad there are others out there doing the good work of generating content to popularize the benefits of good testing practice :)

[0] https://news.ycombinator.com/item?id=29459292

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

#7

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…

Absolutely. What I find astonishing is how undervalued test feedback time is.

I don't know what drives that, but in most jobs I've had to fight to do the right thing.

Just recently I've made some optimizations to get a functional test suite from 65 minutes down to 3.6. Parallelism is my favorite lever, as it scales so well, and core count is still going up!

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

#9
I see this is about game development, but in the web/server world idk how anyone ever thinks its acceptable to make development impossible on your local laptop/computer. Everyone time I do a code review I need to ensure they didn't break local development. It blows my mind that I need to do it, like they think its ok to build and deploy for every little test. When I first joined I spent so much time just getting it to work on my laptop. I really just don't understand the mindset. This is has been the case in multiple places. Who was this first person to break local development and decide it was ok. Please fire that person, black list them from getting jobs ever again.

We have so many tools to make this easy now like docker and yet it still gets messed up.

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

#10
AWS CloudFormation had one of the worst user stories related to iteration time a few years ago.

The lack of feedback between the writing of the yaml file and validation of the structure/type/format was frustratingly slow. I would pay good money for better tooling in the Infrastructure as Code(IaC) space.

Waiting for the resources to update, fail with cryptic error messages, then slowly rollback only to then fail the rollback. Now in an invalid state, manual resource creation was required before the rollback would succeed.

The AWS cdk has improved this significantly. As a result the sun shines just a little bit brighter.

Post reply on HN