39 ms·

>>> I think it goes something like this: you start from the assumption that when you see something, you wonder why it is the way it is. Then maybe you observe i

>>> I think it goes something like this: you start from the assumption that when you see something, you wonder why it is the way it is. Then maybe you observe it and maybe do a little research to figure out how it came to be the thing you see in front of you. This could go for just about anything: a telephone, a scale, a crusty old road surface, a forgotten grove of fruit trees, you name it. By research, I mean maybe you go poking around: try to open that scale with a screwdriver, get out of the car and walk down the old road, or turn over some of the dirt in the field to see if you can find any identifying marks. ... a scientist. My first job title at my current workplace was "systems engineer." My degree is in physics. I evolved into the role of being the person on the project who understands and can explain how the whole thing works. It doesn't mean just dictating a theory of operation, but also testing that theory. My job is in an area where products involve both hardware and software. I certainly don't claim to know every design detail. Part of the trick is figuring out what things I actually do need to know, and how to nail those things down.

josephg 3y ago
Yep. I found a bug the other week which was slowing some important code down by 20x. I found the problem because it was tweaking my intuition. It just didn’t make sense that this code was so slow. After a few nights lying in bed thinking about it, I did some back of the napkin math which agreed with my intuition. Eventually I took some time to track it down. It turned out a rogue debug assertion hidden in a big function was making it into production. The assertion did a deep scan of the system to check invariants, and that turned an O(n) into an O(n^2) in some cases. This sort of thing comes up a lot while programming. Something weird happens and you start to wonder - why does it behave like this? Answering these questions has led me all sorts of places - to reading specs, debugging into databases, compiling my own Firefox, all sorts of things. The chance this knowledge pays off sooner or later is wildly high. Computers are deterministic and debugable. You usually have the source code and everything it does was designed and written by people like you. A curious, scientific attitude is a beautiful thing to nurture in software.
- alex-moon 3y ago
  I actually had a case like this earlyish in my career. I had a job where my main responsibility was maintaining and developing large ETL scripts for an online book store (so hundreds of millions of rows). We had one script which did the meat of the work which was running many hours each night. My job was to speed it up. Watching it run for a bit, it occurred to me to wonder how long it took to send each line of progress info (couple of lines each for every single row) to the log. I remember my boss at the time didn't believe me. "I think it's logging," I said, and turned logging off just for funsies. Boom, 100x faster.
- rramadass 3y ago
  > It turned out a rogue debug assertion hidden in a big function was making it into production Be careful to make sure that it was actually a "debug mode only" assertion (Chesterton's Fence and all that). I have seen too many programmers assume that when it is not necessarily true. Assertions are for establishing "Program Correctness" and hence many are left in Production Code. Of course how you handle it i.e. log/die/catch clause/signal trap is up to the system design.

josephg 3y ago

Yep. I found a bug the other week which was slowing some important code down by 20x. I found the problem because it was tweaking my intuition. It just didn’t make sense that this code was so slow. After a few nights lying in bed thinking about it, I did some back of the napkin math which agreed with my intuition. Eventually I took some time to track it down. It turned out a rogue debug assertion hidden in a big function was making it into production. The assertion did a deep scan of the system to check invariants, and that turned an O(n) into an O(n^2) in some cases. This sort of thing comes up a lot while programming. Something weird happens and you start to wonder - why does it behave like this? Answering these questions has led me all sorts of places - to reading specs, debugging into databases, compiling my own Firefox, all sorts of things. The chance this knowledge pays off sooner or later is wildly high. Computers are deterministic and debugable. You usually have the source code and everything it does was designed and written by people like you. A curious, scientific attitude is a beautiful thing to nurture in software.

alex-moon 3y ago
I actually had a case like this earlyish in my career. I had a job where my main responsibility was maintaining and developing large ETL scripts for an online book store (so hundreds of millions of rows). We had one script which did the meat of the work which was running many hours each night. My job was to speed it up. Watching it run for a bit, it occurred to me to wonder how long it took to send each line of progress info (couple of lines each for every single row) to the log. I remember my boss at the time didn't believe me. "I think it's logging," I said, and turned logging off just for funsies. Boom, 100x faster.
rramadass 3y ago
> It turned out a rogue debug assertion hidden in a big function was making it into production Be careful to make sure that it was actually a "debug mode only" assertion (Chesterton's Fence and all that). I have seen too many programmers assume that when it is not necessarily true. Assertions are for establishing "Program Correctness" and hence many are left in Production Code. Of course how you handle it i.e. log/die/catch clause/signal trap is up to the system design.