Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Development at 1 Hz

medium.com

Post reply on HN
Print view View original

31–40 of 121 posts

Re: Software Development at 1 Hz

#31

Post by brandall10 »

pags wrote: post #30
nojvek wrote: post #9

I am a huge believer of In my new team I got it from 30s to 5s and the effects have been amazing. I have to thank VScode and Gulp to make this possible. With typescript vscode does fast parsing of your code on every keystroke and gives squigglys instantly. On every save, gulp does its magic and vscode runs the problem matcher and shows more squiggly on my editor. The browser knows when a file has changed and refreshe…

Web engineers are waiting for stuff to compile these days? I thought things were supposed to be moving forward, not backward.

deleted

Re: Software Development at 1 Hz

#33

Post by MereInterest »

eeks wrote: post #4

A 20s turnover is not even that slow. Debugging undecidable timing issues in an FPGA may have turnover counted in hours given how slow HW synthesizers are. If the need of better tooling is clear, the OP does not mention one important point: faster machines have created some sort of fast food approach to programming, where programs are built on the go with the help of the appropriate tools (some sort of computer-aided…

I would say that it is a balance of consequences. When the consequence of a mistyped variable is two days, you better believe I'm going to triple check everything. When it is the ten seconds for the compiler to run, I tend not to worry as much.

Reducing the turnaround is a good thing, because that time that would have gone into triple-checking variable names can now go into triple-checking the algorithm on a whiteboard.

Re: Software Development at 1 Hz

#34

Post by castratikron »

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked.

I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the same time. When one run finished, I would verify its behavior, look at the binary's hash, and then know that my code change was safe. It was a very slow process, but effective. After doing this kind of development for a while I'm weary of claims like this that imply that feedback with a latency <10s is actually a good thing. High latency feedback forces you to be more methodical in your development and think about the changes you're making.

Re: Software Development at 1 Hz

#35

Post by makmanalp »

eeks wrote: post #4

A 20s turnover is not even that slow. Debugging undecidable timing issues in an FPGA may have turnover counted in hours given how slow HW synthesizers are. If the need of better tooling is clear, the OP does not mention one important point: faster machines have created some sort of fast food approach to programming, where programs are built on the go with the help of the appropriate tools (some sort of computer-aided…

I don't think it's hard to give credence to the thought that there perhaps is a natural boundary for responsiveness that, when crossed, results in vastly increased productivity. That's the idea here. This works for people with short or long attention span. The paucity of short term memory is perhaps made worse by attention span issues, but that's not the core issue.

Re: Software Development at 1 Hz

#36

Post by StavrosK »

castratikron wrote: post #34

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

> High latency feedback forces you to be more methodical in your development and think about the changes you're making.

So does not having tests.

Re: Software Development at 1 Hz

#37

Post by castratikron »

StavrosK wrote: post #36
castratikron wrote: post #34

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. So does not having tests.

Right. If I would have worked on this again, the first thing I'd do is come up with some way of automatically testing the code.

Re: Software Development at 1 Hz

#38

Post by djur »

I would really like to see someone write enough code to do anything (or even compile), compile it, and interpret the results in a useful manner in less than a second. Continually, over a significant period of time. The tooling is certainly available, but the biological part of that process would seem to be superhuman.

Re: Software Development at 1 Hz

#39

Post by StavrosK »

hobo_mark wrote: post #16
maaaats wrote: post #7

When I write code, I have this mental model of how the world (application) works. I write some lines of code based on it, and then test the code. More often than not, something happened that I hadn't thought about, and my mental model is updated. This summer I worked on an application where it took 8 minutes to see the effect of changed code. Between each iteration, I had forgot most of the assumptions I had made. So…

If 8 minutes sounds like a lot... turnaround times when you work with FPGA code can be hours (and months if you're taping out an ASIC). After having to cope with that for a while, I've found that even with software I think a lot more before writing any code, and now I find myself stepping into the debugger much less often. (My point is: debugging first in your head is yet another skill that should really be taught to…

> debugging first in your head is yet another skill that should really be taught to everybody but isn't

Along with smelting iron. I don't know why people advocate skills one doesn't need, saying "but they make you better".

Skills you don't need will atrophy, because you don't need them. Conversely, skills you need with strengthen. Why would I debug first in my inaccurate head when I have a perfectly accurate debugger right here, and I can run my test suite in ten seconds?

Debugging first in your head is a good skill if actual debugging will take hours. If feedback is instant, you're probably faster writing the first thing that comes to you and iterating on it.

Re: Software Development at 1 Hz

#40

Post by StavrosK »

castratikron wrote: post #37
StavrosK wrote: post #36

Earlier quoted context omitted.

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. So does not having tests.

Right. If I would have worked on this again, the first thing I'd do is come up with some way of automatically testing the code.

Sure, but my point is that being forced to be more methodical isn't a good thing. Not needing to be methodical is better (because your tools will catch your mistakes for you).
Post reply on HN