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

41–50 of 213 posts

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

#41

Post by onion2k »

In a future post, I will go over how web developers needs to start taking iteration time more seriously as the influx of new tools and frameworks starts to bloat up build times.

The newer tools in web dev have crushed iteration times to a fraction of what they used to be. A combination of things like esbuild, fast refresh, yarn's offline cache, and a few other bits can get your iteration times on a site you're manually testing down to milliseconds to both build and update (literally). Decent devs have been writing tests for years; the test runners could be a bit faster but people are working on that as well.

The React app I'm working on at the moment takes well under a second to build, under 10 seconds to run the test suite (could be a sign I need more coverage..), and milliseconds to update the code in the browser in dev mode. It's nice to work with. It's not even clever or special. A default Next.js app will do that. Create-React-app 5 launched a few days ago with more of the tooling too. In Vue things like Vite are based on the new fast tooling and it works well. Vue dev work is fast. SvelteKit even goes further by using Snowpack to remove the bundling step entirely. Snowpack claims a default refresh time of 50ms.

I really hope the author's article about web dev is simply "Yeah, update your tools and you'll be fine."

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

#42

Post by mellavora »

malux85 wrote: post #23
idiocrat wrote: post #19

Earlier quoted context omitted.

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…

I'd add that the cumulative effects of always knowing that the maintenance backlog is under control and that you always have time for the maintenance makes it much easier to consistently deliver the 4-5 hours of "difficult" programming.

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

#43

Post by jmnicolas »

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…

Your example is valid for beginners but once you're getting experience you don't code like that anymore.

After 13+ years of C#, on simple projects I can code for a couple hours without compiling and get the pleasant surprise that my code work the first time I run it. And I'm certainly not a genius, I'm a 1X programmer.

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

#45

Post by xwolfi »

This guy is young and probably not educated in modern dev. I refuse C++ jobs when I ask how they do unit test and they reply it's too hard in C++, and take Java jobs because there the first question THEY ask is HOW I do unit test, what I think of coverage metrics (hints: they don't matter much) and how I propose to enforce ALWAYS unit testing important code.

In this blog post the guy took 3 job change to DISCOVER unit tests, it's insane :( It's not like they know but don't have time, it's that he's a "champion" just for proposing limited scope testing.

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

#46

Post by zuhayeer »

Another thing here is that often times people are so busy "developing" product that really trivial efficiency gains get overlooked. Things like simply removing unnecessary parts from the build at least when you're testing / in dev mode. Also compartmentalizing the build to the portion of the app you're working on, ensuring it's not building the entire app when you're only testing one feature (you'll be surprised how common this is even especially at large companies). It's a huge value add to the rest of your team to bite the bullet and take an hour or so to shave off some minutes from the time you have to wait for a build. That one hour saves you from many multiples more (hours / days / weeks) of fiddling your thumbs in the breakroom waiting for a build to finish.

(better yet to have someone regularly scanning for these efficiency related things)

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

#47

Post by xwolfi »

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…

No unit test should be mostly to make sure the old assumptions for code you don't know still hold and warn you if you break something.

Ofc if you do the code and the unit test, all you validate is that the code does what you assumed was right. But in 2 years, when someone touches something unrelated, he'll kiss you on the mouth that your test noticed an edge case that started failing.

If it's not your unit test catching unintended changes, it's your client. You may not want that :)

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

#48

Post by cjfd »

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…

Very good points. In his book 'working effectively with legacy code' Michael Feathers actually defines 'legacy code' as code without tests. Largely because of reasons like you state.

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

#49

Post by wojciii »

I do embedded work.

I experienced this while working for a multinational.

- A long build process and linker step that takes ages. 1-2 minutes for a small change.

- Trying the change on a real device took perhaps 5 minutes.

- A review process that can take days or even weeks sometimes.

- There was a process that merged my change set which often failed and needs to be rerun several times - often 1-2 days were spent on trying to commit something where everyone was doing the same.

- There are no unit test because some manger decided that they provide no business value.

- There were no simulation tools for software be because some manger decided that they provide no business value.

- Testing would be done overnight.

With the right tools (unittest and pc simulation) I would be effective and could test my changes prior to testing on a real device. This was for me the bottleneck and not how long it took to build the project. I was testing code that was just C on a complex embedded device that I could have tested/debugged easily on a PC in 1/10 of the time.

This was really a management problem where the management didn't understand what to do to make their employees efficient with the right tools.

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

#50

Post by fy20 »

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…

There is a cut off period though. In my current role there is one project that takes 15 minutes to clean build, and another 15 minutes to run the test suite. Incremental builds are fast, but sometimes/often the compiler decides it needs to rebuild everything.

Additionally for some reason on my machine, maybe 25% of the time it gets stuck while building and I need to kill it and start again. Usually I go and get coffee while it's building, but there's only so much coffee or Reddit you can drink. Many times I've taken a 30 minute break while it builds and tests, then come back to find it got stuck and need to start again. Anytime I have to work on this project I try to put it off as much as possible, as I know it's going to be painful...

Post reply on HN