Writing django and JavaScript apps with a hot reloader has spoiled me. The dev loop for other cases now feels almost painful.
Software Development at 1 Hz
11–20 of 121 posts
Re: Software Development at 1 Hz
#12For Ruby pry comes close but he's right about the inability to have the same kind of turnaround cycle when you're developing a C extension. I don't think anyone is gonna beat SBCL in that regard any time soon. There is no way to take Ruby and then generate machine code that ends up being callable from the current address space. Although I guess there is some way to do it with cffi and a compiler constantly running in the background.
Re: Software Development at 1 Hz
#13It's really interesting how little time it is before things become disjointed. Recently working with some legacy code I noticed this. Usually I have a continuous unit testing process which normally is Ironic when in the past I have worked with C++ code bases that would take 20 minutes to compile, though incremental builds and parallel builds brought that number down.
Also in embedded systems, I've got 3 minute cycles to try something out. However most of the coding is done on a PC with a fast unit testing cycle which dramatically improves feedback loops.
Re: Software Development at 1 Hz
#14I once had - a super-fast assembler - a super-fast way to get the assembled code over to a target system ... and my turnaround time was on the order of five seconds: Edit, hit a button making the target ready to receive the code, assemble: Running. It almost didn't matter that I was writing 6502 assembly; things just fell together and it was magic . Years later I was in a place where it was common to have half-day bu…
Can you go into more details? Why did something take 30 minutes or longer to build? Was the environment being cleaned every time? Was an artifact server not being used?
Re: Software Development at 1 Hz
#15My dev-loop currently takes ~10sec. But I worked with worse...
Yes I prefer faster loops, but nerver had a job where I could influence the build pipeline...
Re: Software Development at 1 Hz
#16When 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 everybody but isn't).
Re: Software Development at 1 Hz
#17This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly.
I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. Relegated to "whiteboard coding" interview questions, I'm left looking a whole lot worse than I am - not because I don't know it, but because I know enough that thoroughness is painfully slow (without leveraging tools multiplying my skills & speed).
Re: Software Development at 1 Hz
#18I 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…
This is a problem I'm having at the moment, 20s webpack builds with ts-loader, plus other build steps running in VS 2015. Seems I need to drop ts-loader, and build more directly. Are your build files available to look at somewhere?
Re: Software Development at 1 Hz
#19I once had - a super-fast assembler - a super-fast way to get the assembled code over to a target system ... and my turnaround time was on the order of five seconds: Edit, hit a button making the target ready to receive the code, assemble: Running. It almost didn't matter that I was writing 6502 assembly; things just fell together and it was magic . Years later I was in a place where it was common to have half-day bu…
I always laugh thinking that Turbo Pascal was so quick I didn't understand the difference between build and "build then run". And that was statically typed code on Pentium class computer.
Re: Software Development at 1 Hz
#20I 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…
Interesting. I may have to give that setup another shot. I found TypeScript compilation to be really slow. Was recently amazed by Bucklescript's lightning-fast compile times and killer repl, but its integration with the JavaScript ecosystem was nowhere near as smooth.