3 ms·
You don't need to do it artificially. If you look long enough in most code bases, you will eventually find a spectacular problem. Case in point, I was working
by BiteCode_dev 3y ago
You don't need to do it artificially.
If you look long enough in most code bases, you will eventually find a spectacular problem.
Case in point, I was working for several months for a client, and I had a slow afternoon, so I decided to convert some calculation to numpy, see if we gained any free perf.
We got a x100 local speed up, which was very fishy. Gaining speed is common with vectorization, but two orders of magnitude is a lot.
So I looked at the original algo. There was a glaring mistake in it, that I fixed by my numpy code without noticing, and just changing that in the pure Python algo, without using numpy at all, made it X50 faster.
I could then call my client, and celebrate the good news. Not "there was a mistake", no. But "we found margin for progress".
- itsoktocry 3y ago>I could then call my client, and celebrate the good news. Not "there was a mistake", no. But "we found margin for progress". This is great framing. Bugs in code are not really "mistakes"; they will occur. Finding and fixing them is a positive.
- dataflow 3y ago> Not "there was a mistake", no. But "we found margin for progress". Were your clients nontechnical? Or did they just not care to know how you got a 50x speedup?
- BiteCode_dev 3y agoThe boss only cared about the end result and got a quick message. He won't read more anyway. The technical team an in depth explanation with code snippets. Know your audience.