Hacker News Reader

Comment by cletus | Hacker News Reader

IMHO the #1 thing you can do for developer productivity is to reduce the development feedback loop to under 30 seconds and preferably under 10. Why? Longer than that and you have two choices:

1. Work on simultaneous tasks at once. This incurs a context-switching penalty; or

2. Get distracted by HN, social media, reddit or whatever. This has the same context-switching penalty and you can end up spending way more time on that distraction than the development loop actually needed.

I've worked on a code base where it took 3 minutes minimum to run a unit test. Some adjust to this mindset by doing more in a single test but even in the most optimal fashion it's not as good as quick turnaround.

View on HN

I work on two major projects - one is written in vuejs (with a .NET Core backend) and the other is on top of a .NET CMS Solution (not going to name names).

In the .NET CMS Solution, when I make a code change (view changes are easier), if the change restarts the application pool, it can take up to 2 minutes to see my change - worse in some solutions. (I work to support some existing solutions that weren't written by us but only have a certain amount of hours to accomplish, so doing the "best" thing isn't always an option). So click reload and then I'm off to another project and/or distraction and may not be back to check the change in quite a while.

The vuejs project on the other hand. I make a change to the backend, reload the app - in under 2 seconds and then re-run the API method. Or even better, if I make a change to the frontend, I hit save on the file and the screen is updated by the time my eyes have a chance to move to the other monitor! It's so refreshing.

This is why I love static checking tools such as type systems. I often get the feedback as I type.

I agree 100%.

Compiler errors are strictly superior to runtime errors. It's as simple as that.

thanks for resolving this discussion on behalf of the developer community

Yeah he didn’t give any evidence but he is right ;)

Funny -- this is why I love working in Lisp. I can edit the code and retry it, often by just restarting the stack frame. Compiling takes milliseconds.

An untyped lisp does not check the entire code base for usages of the thing you are editing though. I agree that for exploring local behaviour a REPL is fantastic.

I once worked on a project in 6502 assembler where my turnaround time was about three seconds from build-to-run. It was absolutely magical.

Compare that to an environment I was in a few years back where I was lucky to get two builds a day. Sometimes went weeks without working code because people kept checking in busted stuff. I wound up quitting (for that, and other reasons).

It is amazing how companies will pay high salaries for engineers, and then refuse to buy them top of the line equipment, too. I remember fighting for SSDs, when the time savings alone would have paid for itself in a couple of days. Crazy.

Google is famous for having amazing dev tools. If any (large) project is going to have this most-important thing, it is likely to be best able to get it at Google. And yet Google also has a reputation for low developer productivity. So, what gives? Are some of my premises wrong, is the most important thing not close to sufficient, is Google actually productive?

Google had amazingly below-average dev tools when I was there. It was standard in my org to have multi-minute builds, with input/output streamed to/from a remote server. Yes, every keystroke had a small but perceptible delay. I was working on an outlier project that took over 30 minutes to build for a single-character change. I never learned as slowly as I did during my time there. Startups generally have faster tech, bigcos generally have more customized tech with more options and that can operate ‘at scale.’

If productivity could be broken down to an equation, it would certainly have more than one explanatory variable.

If the relative value of things tends to follow a power law (this seems to be true in many cases) then one would expect the best few things to be much more important than the rest. So even though many things contribute to the result, the most important things may still be very important.

Funny story. Sourcegraph itself (the company the author belongs to and cofounded) started to bring the awesome code search internal tool at Google to the world as a product.

Yes. In one particular platform on my current project there is a 900 second best case development loop (15 minutes).

This is so true

Reply on news.ycombinator.com