3 ms·
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 tha
by maaaats 10y ago
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 when things didn't work, I had a hard time figuring out why my model of the world didn't work. I basically started from scratch each iteration.
Possibly very obvious, but it was interesting to learn how I attack a problem. And scary to see that I didn't just lose the 8 minutes between each run of the program, but much, much more.
- hobo_mark 10y agoIf 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).
- StavrosK 10y ago> 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.
- plaguuuuuu 10y agoBeing unable to run through code in your head and fully conceptualise a codebase is a great way to introduce subtle integration-level bugs that escape unit testing.
- enraged_camel 10y agoThat's why we have things called "integration tests". https://en.wikipedia.org/wiki/Integration_testing https://en.wikipedia.org/wiki/Integration_testing
- plaguuuuuu 10y agoAnd of course, there are never any bugs in software, ever, because we have integration testing!
- taeric 10y agoThis is as silly as asking why people advocate exercise. I mean, you clearly don't need to be able to lift heavy things. Even if it is sometimes helpful. Similarly, thinking about things before you do them will almost always be something you could just skip out on. But... It can be very helpful. And exercise is a great way to get better at work. "Practise makes perfect" and all.
- plaguuuuuu 10y agoThe really interesting thing is that while I'm completely happy to spend 30 mins writing line after line of code to implement some algorithm, winding up with >100 lines and only compiling at the end, if it takes more than around 30 seconds to compile I'll lose my train of thought entirely. So I understand the concept from the point of view of task-switching. But a lot of people in the comments allude to needing a feedback loop for each and every line of code, which sounds absolutely horrifying to me - is that really what development is like in some environments? you can't really be sure of what a single line of code is going to do?