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

61–70 of 213 posts

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

#61

Post by withinboredom »

dinvlad wrote: post #39

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…

I agree. The issue is when you don’t have the test harness or the code just isn’t testable. Then it really will “use up” your dev time for not much gain. Or at least it’s a harder sell. My “dark pattern” to sell this is to offer to refactor a small portion at a time, then read through as much code as I can on nights/weekends looking for unhandled edge cases. When I find one, that’s the part I make tests for. Wo and behold, it found bugs! Bonus points if the edge case actually causes issues in prod or loss of revenue. The manager is now convinced we need this thing, or at least thinking about giving us time to work on it.

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

#62

Post by J-Kuhn »

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…

Those short cycles are great when learning a new language. Experiment with it, try new things, understand how the language works.

But at some point you are better thinking about what to write, how to write it, which structure you will use. And this skill has to be acquired as well.

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

#63

Post by clktmr »

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 worked on projects with long compile times and nowadays I will often write code all day without executing anything and then spend the last hour running and fixing it. Maybe that's a skill I developed because of long compile times, but whenever I work on a project with short ones I feel much more motivated and productive. Your experience is probably biased from watching beginners learning to code.

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

#64

Post by HPsquared »

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

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!

Probably something to do with that XKCD about waiting for compiling, "The #1 programmer excuse for legitimately slacking off": https://xkcd.com/303/

Running tests is the same type of thing!

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

#65

Post by roeles »

KronisLV wrote: post #38

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

I have somewhat the same experience with my first real TDD-based project. Progress was slow, but the amount of debugging afterwards as almost zero. It feels slower, but more predictable.

> Recently decided on using TDD for some library code and aiming for >90% test coverage at my dayjob.

I thought the point of TDD was that you don't write code unless a test requires it? In my mind (and the little experience I have) that translates to 100% coverage, with exceptions of really annoying side-effects that are near-impossible to test reliably.

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

#66

Post by darkwater »

DarylZero wrote: post #36
yupper32 wrote: post #25

Earlier quoted context omitted.

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.

It can be fun, it just depends on who you are. Sadly most developers prefer to follow PM and churn in features instead of this precious work.

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

#68

Post by KronisLV »

roeles wrote: post #65
KronisLV wrote: post #38

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

I have somewhat the same experience with my first real TDD-based project. Progress was slow, but the amount of debugging afterwards as almost zero. It feels slower, but more predictable. > Recently decided on using TDD for some library code and aiming for >90% test coverage at my dayjob. I thought the point of TDD was that you don't write code unless a test requires it? In my mind (and the little experience I have) t…

> In my mind (and the little experience I have) that translates to 100% coverage, with exceptions of really annoying side-effects that are near-impossible to test reliably.

Yep, like Java supposedly being cross platform, but having different file system implementations, because using one implementation across multiple file systems just isn't entirely feasible, for example, due to how paths are validated.

Thus, no matter what i did, i couldn't get the coverage to 100% due to semantics of how i'm supposed to validate that the low level call works and because i have branches in the test, one that checks whether the correct exception is thrown in Windows and a different exception for Linux. Even if technically the code paths are covered, telling that to a subpar code coverage plugin is hard.

So, i just settled on writing code for everything myself, but having 90% coverage be enforced on a class line level to account for the weirdness.

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

#69

Post by vbezhenar »

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

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. Docker is a miracle technology sometimes.

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

#70

Post by roeles »

> This is the sweet spot amount of time where you become tempted to “do something else” while you wait.

I think this is an important observation. The time where you "wait", you can allow your mind to drift off right after being immersed in the problem. In my experience, this time has the potential to give you great insights.

I think fast feedback is great, but only if you know what you're trying to accomplish. Or trying to learn. Don't use it as a tool to throw stuff against the wall and see what sticks. Once you start to do that, spend some time away from the computer. Draw a picture, formulate some hypothesis based on your mental model. Make a map before you enter the jungle of trial-and-error.

Post reply on HN