51–60 of 91 posts
Earlier quoted context omitted.
Ah, but perfect is the enemy of good.
Perfect is the enemy of ever shipping an actual product.
It just takes a lot of work. No shortcuts.
But that WFM. YMMV.
In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…
Correctness of a program is usually distinct from performance. One obvious exception is code processing secret data. There, performance variance creates observable side-effects (timing side channels) which can be used to determine the secrets' values. Another is any sort of hard real-time system, where performance is critical to correctness. For example, a brake-by-wire system that took 10 seconds to respond to the p…
This is pretty spot-on. A culture of testing everything will ossify code by not understanding what a "unit" is and amplifying developer churn by testing implementation details instead of the actual units. A culture of just getting features out the door will suffer under the weight of every change dragging on all future changes. If you want to really get code that can be adapted whenever requirements change, you need…
Yup. I have seen so many people write stuff that could just be a YAML script, tying together massive dependency trees that they have no clue about.
Then, they lose it, when things go pear-shaped.
However, if the goal is to sell the company before the chickens come home to roost, it's a feature, not a bug.
A one of my CS cohorts happened to be in the same class so we teamed up for the first lab project. It was pretty straightforward, we collected whatever information, and started working on our report. We didn't bother spending much time on it because we already knew we'd lose points for something or another.
When we got it back, there was a big, red "100" on top. We checked around and it did look like we were the only ones that got a perfect score, so we went to the instructor and, mostly jokingly, said, "What's up with this?" to which he stayed on beat and replied, "Do you want me to take another look?"
It's not hard to do good work, but you do have to make a habit of it. Re-read what you write, preferably out loud, to make sure it actually makes sense.
You'll still make errors and mistakes and you won't catch them all, but no one's going to care about a typo or two unless you draw attention to it with more glaring problems. And I think this is where metrics, especially things like code coverage, can actually be detrimental, because they bring attention to the wrong things.
Specifically, in places I've seen code coverage enforced, tests (written by consultants making x5-10 more than I do) tend to look like, `assert read_csv("foo,bar") == [["foo", "bar"]]` that execute enough of the function to satisfy the coverage requirements, but everyone is surprised when things break using a real CSV document.
The corollary of the author's trick is that if you keep making excuses to produce poor work, you may subconsciously decline instead.
His strategy for Russian language was sort of how I approached math in college when it started getting difficult and more abstract - I found that when I wrote in pencil, I would frequently make mistakes because of all the erasing and scratching out and going too quickly. So I started showing up to exams with only a pen - forcing me to sit and think very carefully about whatever I was about to write, and if I couldn't…
His strategy for Russian language was sort of how I approached math in college when it started getting difficult and more abstract - I found that when I wrote in pencil, I would frequently make mistakes because of all the erasing and scratching out and going too quickly. So I started showing up to exams with only a pen - forcing me to sit and think very carefully about whatever I was about to write, and if I couldn't…
You story about the one pen reminds me of something. My old chemistry teacher gave grades to how orderly people's notes looked. "How it's put on your page, it's in your head," he used to say. At the time, we school kids found it "childish". But empirically, there is some truth to that: it seems I can learn better from clean notes than from sloppy notes, so often I re-wrote things. I was wondering whether that is due…
In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…
The best way to write without bugs is to measure bugs, and react to them. Airbrake, Rollbar, Datadog, New Relic mean nothing if you ignore bugs because you don't take the time to replicate them. You also can't fix what you don't know, so you need some telemetry or reporting of not your happy path. You can't have a goal of bug free code if you don't measure bugs (that's not SMART goal because it's not measurable). Uni…
Oh, you've met my CEO and CTO. And all those at previous companies!