Be sceptical of your own work (2009)

I've had this happen enough I don't use git blame.

Only once have I looked at something and thought, "cool solution, I would never have thought of that", but apparently I did.

Sometimes I encounter those snippets and I still have a discrete memory of writing something that "I knew my future self will understand".

That is especially frustrating.

That's me all day.

Shirley, you're joking!

That was funny but weird, because as far as I know Feynman didn't take up drumming until his sabbatical in Brazil in 1951.

I’ve learned never do the “three designs, pick one” trick unless all three are things you like. Inevitably the boss or customer will pick the worst most horrible one.

I love these. Thanks.

What I do:

1. Add TODO items when I'm in flow

2. When I'm not in flow, I search TODO items in code/notes I own

3. Add a basic task in a project management tool with no estimations for each TODO item

At least then it's in a system to be triaged at some point.

I use a combination of things, depending on the nature of the temporary measure.

I use TODO comments to document that this part of the code needs to be revisited.

I write a warning to the log file whenever the temporary code executes.

If there are things left unimplemented, but there's an interface to them, then I put code in that's guaranteed to fail at runtime. If the language is C or C++, I'll use something like assert(false).

You make your life substantially easier if all the functions/methods/procedures/blocks/... in your code are "total" -- if they transform every possible input into the output one would expect from the name and type signature. With that as a guiding principle, I tend toward the following strategies, the particular choice of which depends on other details. Most often I'll combine 2/5, throwing a compile-time error for the broken branches, later realizing that the abstraction I chose was stupid, and then writing code that actually does what I want.

1. Inline the work being done. If you've only implemented a single case it doesn't deserve a named function that does something different from what the name indicates. Refactor it later if you ever need when you have more cases.

2. Ensure the error happens at compilation. C# has diagnostic directives. Zig has the @compileError builtin. C/C++ can fail using the preprocessor. It's a relatively common feature, and if you ensure that when your buggy/unfinished function compiles it's correct then that mitigates the harm you might cause (and serves as documentation: @compileError("TODO: ...")).

3. Ensure the type signature captures the problem. If some inputs result in crashes, return an error-code/error-condition/failure-union/optional/nullable/... so that the caller knows shit might happen and can deal with it at runtime if it does.

4. Make it abundantly clear that there's an issue. Name it `unsafe_unfinished_only_works_for_this_subtype_foo_bar` or something similarly onerous.

5. Use a different abstraction. Rather than `def handles_everything(something_that_might_not_be_handled):` -- a great abstraction that you don't actually use yet because you don't actually handle everything, instead write a `def handles_something(something):` function. Refactoring is cheap. If you don't need the full abstraction then don't use it, and definitely don't write an unfinished, buggy version of the abstraction you're not using.

5a. It might be hard to write the type signature of that restricted "something". E.g., let's say your function only works on sorted lists. A wrapper type pointing to the thing you actually want can be a good tool for this. E.g., you might have a SortedList type, and it might expose two methods for instantiating it -- validate_sorted (which might return an error but which checks that the list is actually in order), and unsafe_assert_sorted (where you as a programmer pinky promise that you know what you're doing and create the wrapper object regardless). Any function doing a binary search can now rely on the SortedList behaving appropriately, and all bugs associated with that function call can be tied to the very greppable name "unsafe_assert_sorted". Every possible input to the function yields an appropriate output. I'm not the first person to notice this idea. [0]

6. Limit the visibility. Use inner methods, inner classes, private, protected, underscore prefixes, or whatever else your language has to indicate to the outside world that they're technically allowed to use this method but that they probably want to think twice about it (similarly to the "unsafe_unfinished_..." from above, but also tends to play nicely with tooling).

7. Just finish the thing. Shaky foundations are more expensive than they appear, and when you've written one case it's actually usually pretty fast to implement the rest, especially while you have all the surrounding context in your mind.

8. Ignore all of the above. Sometimes something like performance overrides other concerns. Code is a balancing act.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Even in day to day programming, it's too easy to throw something together and see it work and call it a day. A dose of scepticism toward a "solution" is healthy. It's not like software doesn't come with bugs grossly often. Probably grounds for extra self confidence even.

Critique the work of others as well. A lot of impostor syndrome goes away when you realize that 80% of the people who you thing are better than you are cutting corners you won’t, and that takes up time. Someone else is cleaning up after them.

I think that would depend on whether you view your work as producing "argument proof results" or just "results." In other words, producing high volume low-quality "trash" may easily undermine self confidence more than producing low-volume high-quality "diamonds."

In either case, the way you frame it matters much more than the process. But I can agree that expecting either "high quality high volume" or aiming for "low quality low volume" are both likely paths to a depressive episode.

Personally, I'd rather small flawed diamonds. The fact that they are diamonds nonetheless gives me pride. The fact that I can produce greater quantities of them than flawless gems keeps me employed (which also gives me self-confidence).

Ultimately very subjective, regardless

> If you are constantly undermining your own self confidence in routine tasks be prepared for a depressive episode.

I disagree that self-skepticism implies undermining your own self confidence. With regular practice, it should bolster your confidence in your ability to find mistakes (a valuable skill), and in your ability to produce final outputs with fewer errors.

I guess it's in how you phrase the skepticism: are you skeptical of your ability to do the work, or are you skeptical that your work is free of mistakes? There is a difference.

If you want a structured and rigerous version of this it's called mutation testing. It can be quite slow, but also very informative when evaluation how well tested a piece of code is.

With TDD you write tests first, then ensure your tests fail, then write code, ... for the reasons you mention.

The discussion notes are awesome too. Lots of examples raised.

Both spellings are correct.

from the same people who brought you maths plural