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

31–40 of 213 posts

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

#31

Post by zerocount »

gfodor wrote: post #26
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

This is being down-voted, but there is merit to this. Tests should be audited for continued need.

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

#33

Post by meheleventyone »

Ma8ee wrote: post #29
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.

Unit tests are useful for some things. I can’t unit test my way to a game feeling good. For that I need a fast feedback loop to the real program. There’s more of that in most applications than most people suspect. And routes to get there. As programmers we make a lot of little decisions along the way and those don’t get proper consideration unless you can see that as the feature evolves.

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

#34

Post by xcambar »

gfodor wrote: post #26
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

I understand the underlying message but I prefer the equivalent following phrasing: "check test suite coherence".

It moves the deletion as a means towards the coherence rather than as an end in and of itself, and also includes refactoring as an option.

I hope it helps the less experienced developers grab the intention more explicitly.

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

#35

Post by reincarnate0x14 »

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.

Maintenance type work tends to be chasing issues you don't personally care about in increasingly arcane edge cases or trying to intuit why someone else, who has moved on to something that sounds way more exciting than this, came up with a specific solution.

Even more so in a lot of orgs maintenance work gets hit by the "cost center" mentality and management only rewards not hearing about it.

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

#36

Post by DarylZero »

yupper32 wrote: post #25
idiocrat wrote: post #19

Earlier quoted context omitted.

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?

That's not the reason. The work itself is not fun.

Even if the whole project has no career purpose, it's more fun to write new code.

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

#37

Post by userbinator »

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 the code they're writing, makes the time-to-iterate very short (press a key and you instantly see your changes). They end up getting into a "dopamine feedback loop" that causes them to continually make tiny changes and rebuild/run, and the code written as a result of this looks exactly like what you'd expect: it barely works, and is full of redundancies, "dead ends", and other evidence that its author was probably not thinking of anything more than the next line or two when writing it.

In other words, reducing the iteration time reduces the motivation to get it right the first time, and the associated deep reasoning/"mental execution" skills which are required to do so. In order to develop those skills, one should strive to write as much code as possible before running it, and a high iteration time assists with that.

Also, I'm tempted to continue the title with "...unless it's APL".

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

#38

Post by KronisLV »

Recently decided on using TDD for some library code and aiming for >90% test coverage at my dayjob. Frankly, things do take longer to develop this way and i needed to put in more thought into how the interfaces should be structured, vs just doing what people sometimes do in other projects - just relying on concrete implementations or using frameworks that use reflection to do what they want.

However, the experience itself feels like a positive one - even if the code takes longer to craft, it's much easier to work with, since now i don't need to worry about sloppily written if/else chains that depend on enums or runtime type checks, but can utilize different implementations as needed. Also, writing the actual tests allowed me to be sure about how everything would actually work, all the way up to discovering that Paths.get (Java) on Linux accepts almost anything as a valid path string, whereas Windows has actual validation rules, leading to many headaches in regards to the code coverage quality gates that i set up, since the coverage differs based on which platform you run on.

But i guess that my point still stands: in certain circumstances slowing down might actually be a good thing, when you really want to know how your code will work under most circumstances and make it maintainable.

Of course, on the other hand, compilation speeds and other factors in regards to the speed of iteration definitely shouldn't be overlooked either, and having everything else apart from writing tests and actually thinking about how everything will fit together be faster is a good thing! I'm not sure what i'd do if my test suite took 10 minutes to run instead of 10 seconds as it currently does. Probably drink lots of coffee.

I guess it depends on slowing down for good reasons, vs just wasting time because of tooling or other sub optimal circumstances (e.g. what was described in the article, personally i've also seen a local API service be pretty chatty with a remote DB which was slow over a VPN, yet no one had a local DB with all of the migrations in place, and a bunch of other things like that).

Offtopic: Anyone remember how fast Pascal compiled? Now that was a really nice stack to do some stuff in, it's a shame that it never got as popular as Java, or didn't have tooling like JetBrains has, it felt like a more ancient Go (which is also pretty good as far as ergonomics go).

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

#39

Post by dinvlad »

Going from "manual testing" to automated testing is the biggest jump. Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking they will "use up" their development time on automated tests, and not really thinking how much time they're already wasting just to do (incomprehensive and hand-wavy) manual tests each time.

And while this strategy might work for the folks who actually wrote the code (and thus have tacit knowledge about it), the moment they leave and/or someone new joins the team, all that "speed advantage" is lost and it turns from minutes to hours to days instantly.

Automated tests really are the only way to capture the business logic of any code for it to not to become "legacy code" before its time.

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

#40

Post by phone-account-1 »

senectus1 wrote: post #14

For all the issues I have with Elon Musk, I really like his design philosophy. Step 1 Make it less dumb Step 2 Delete a part of the process If you're not adding step in 10% of the time, you're not deleting enough Step 3 Simplify or Optimize Step 4 Go Faster Step 5 Automate

Nitpick: he actually said "Make the requirements less dumb", which is quite different actually.
Post reply on HN