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

21–30 of 213 posts

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

#21

Post by yashap »

If 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 having it “just work” the first time, most of the time) is HUGE for productivity

2. Excellent automated test suite, with a nice pyramid (small number of E2E tests, solid number of integration tests, exhaustive unit tests). Also excellent monitoring and alerts, with automated canary releases and automated rollback. Basically make it so that it’s hard for mistakes to fully reach production. Being able to be a bit of a cowboy, safely, is huge for productivity too. I’ve worked on plenty of systems without this, and then I’m MUCH more careful, but when you really do have this, it makes everyone so much faster, especially once you learn to stop worrying and trust the guardrails (for simpler changes)

3. Test suite runs quickly locally, and is not flakey

4. Running the app locally is quick. Also ideally I can run just the one component I’m working on (like a front end, or service, or whatever), but have it fit into a full system running elsewhere

5. Full build/test/deploy process on CI is quick and reliable

This article emphasizes 3 and 4, and they’re certainly very important, but I think 1 and 2 are even more important. With them in place, often I don’t even need to do 3 and 4 for more trivial changes - just “I’m pretty certain this works,” and then the tests all pass in CI, and I’m very certain.

Compared to systems without 1 and 2, where I have to basically change a line, then run tests and/or the app because I’m not sure it’ll work, then do extensive manual testing to be sure because the automated test suite sucks. Muuuuuuch slower.

3 and 4 are great, and necessary for more complex changes, but 1 and 2 let you ship simple changes super quick, without even needing to run anything locally. That’s fastest of all, and can still be quite safe in the right environment.

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

#22

Post by meheleventyone »

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 games this results in increasing the total iteration time as it’s usually now a different person who actually runs the code, find issues and submits them back.

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

#23

Post by malux85 »

idiocrat wrote: post #19
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…

For some reason not many people like the "maintenance" type of work.

Not full time, but documenting interfaces, speeding up tests, generating stubs and harnesses, profiling pain points - all these I find to be meditative tasks, and I do them when I'm not 100%.

I can do about 4-5 hours a day of "difficult" programming, but then I can easily do another 4-5 hours of this maintenance type work, and the cumulative effects of repeated maintenance time keeps everything running super smoothly.

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

#25

Post by yupper32 »

idiocrat wrote: post #19
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…

For some reason not many people like the "maintenance" type of work.

The reason is simple. Maintenance work doesn't progress your career.

Why bother?

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

#26

Post by gfodor »

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…

Another much under-utilized way to speed up test suites: delete tests

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

#27

Post by ewuhic »

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

What exactly you'd want to see from such tooling that it improves your experience with AWS?

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

#28

Post by rlayton2 »

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…

Isn't the normal process, roughly, to:

1) Use unit tests to move quickly through to implementing The Feature 2) When The Feature is complete, run in a local environment to confirm it works 3) When that works, move The Feature to a development environment that more closely mimics Prod 4) Deploy to Prod

Each one of those steps takes an order of magnitude longer than the previous one, so should be done an order of magnitude less often. However if you are finding inconsistencies between steps, then alter local/dev to ensure more consistent testing. (i.e. if it works on Dev, it should just work on Prod, however there are always little issues).

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

#29

Post by Ma8ee »

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…

You need both. If you don't have unit tests your feed back loop becomes way too slow, but then you of course have to test the "real" running of the program properly before shipping. And you need at least one person who didn't write the code to test it.

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

#30

Post by meheleventyone »

rlayton2 wrote: post #28
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…

Isn't the normal process, roughly, to: 1) Use unit tests to move quickly through to implementing The Feature 2) When The Feature is complete, run in a local environment to confirm it works 3) When that works, move The Feature to a development environment that more closely mimics Prod 4) Deploy to Prod Each one of those steps takes an order of magnitude longer than the previous one, so should be done an order of magni…

Right but 2 often ends up being perfunctory whereas if you can test routinely against the local environment you’ll see a lot more and for example course correct earlier. It depends on what you’d consider an iteration as well. I don’t think the loop is closed until you’ve seen your code running in situ. Unit tests might let you have more confidence that things will work at that point.

Running in situ could also be integration testing FWIW. Depends on what it is you’re making.

Post reply on HN