Imagine deploying your bug fix and having to wait two days to find out if it worked!

An old timer once told me about how he would read his printouts, make new punch cards, send them over to the main office, someone would put the new cards into the system the next morning, and then read the printouts on the day after that to see if his code worked or not.

▲

wpollock 2 days ago | parent [-]

This. Except worse, during busy days you had to stand on line for an hour or more for a turn on the machines. I believe the skill of debugging by mentally stepping through a program's execution came from such long run times, a useful skill many younger programmers lack.

▲

whartung 2 days ago | parent | next [-]

> a useful skill many younger programmers lack.

Because it’s unnecessary.

It’s not a difficult skill.

When folks are in that situation, they tend to adapt quickly to their reality. But that’s not the reality for the vast majority of developers today.

Thankfully.

	▲	XorNot 2 days ago \| parent [-]
		Yep I really hate the characterisation that tried to imply people are weaker or worse because they lack a contextually relevant skill. I spent about 6 months teaching myself how to tie a set of useful knots, and the reality is by now I can't do most of them anymore because day to day it turns out I just never need to tie a Midshipmen's knot (it's super useful when the siruation arises..which is rarely for an IT worker).

▲

estimator7292 2 days ago | parent | prev | next [-]

The computer can single-step through the program far more accurately than you can. You can inspect the full state of the CPU and memory at any moment of execution. The debugger can tell you the real, exact value of a variable at runtime.

There is simply no reason to try doing this in your head. You're worse at it than the debugger is. And I say this as someone who does have the skill. It's just not necessary.

▲

keybored 2 days ago | parent | prev [-]

I want to learn that.

It’s just silicone. Who hard could it be?

	▲	cindyllm 2 days ago \| parent [-]
		[dead]

▲

musicale 2 days ago | parent | prev | next [-]

HPC systems often still use batch scheduling systems where (even for a fast job) you may very well get your results the next day (or whenever your job actually runs and completes.)

It is annoying to find out that your job failed to run or exited immediately due to a typo or other minor mistake.

Of course ML training (and scientific computing) jobs can take weeks or months to complete. Checkpoint and restart features are important because node or other failures are almost inevitable.

▲

bpye 2 days ago | parent | prev | next [-]

There are definitely projects where getting a full test pass can take a day or two. I worked on one where we only got a full run each weekend, and if someone broke the tests? Nobody gets their results...

▲

saagarjha 2 days ago | parent | prev | next [-]

I once left a company after deploying a fix to solve a rare crash due to a data race and only figured out if it worked after I had started the new job by poking my old coworkers about it.

▲

kulahan 2 days ago | parent | prev | next [-]

Aprocryphal, but I've heard that at Oracle, when pushing an update to their database software, it'll be maybe a week before the tests complete on it (after it reaches the front of the queue of course). I couldn't even.

▲

SoKamil 2 days ago | parent | prev | next [-]

I’m doing mobile app development, it is about how much it takes to get submission approved and get significant amount of users.

▲

ryukoposting 2 days ago | parent | prev | next [-]

Sounds like just another Monday for a firmware dev, honestly. Can't repro your bug because your board is subtly different than mine, but I think I see what's wrong?

▲

partloyaldemon 2 days ago | parent | prev [-]

I've had those times in swift in a terrestrial setting!