Ask HN: Do you experience a crippling fear of “writing low quality software”?

4 points by ancarda ↗ HN
For many years, I have found myself unable/unwilling to write software as a hobby. While I still do it as a profession, I'm barely able to write for leisure or for personal projects these days.

For some time, I just assumed it was something like burnout; I write code at work and don't wish to do it at home. But even when I do have a day off and I feel like writing something... I rarely get anything done.

However, yesterday, in my spare time, I started working on a small program. I had an idea that I wanted to explore, but very quickly I ran into some trouble writing unit tests for it. Eventually, I got overwhelmed with two unacceptable options:

1) Write this thing without tests.

2) Build an -insane- amount of scaffolding to make tests possible.

A whole day of struggling to do TDD and I have nothing to show for it. It has really ruined my mood, and I realize now how often that has happened when writing software. In a way, "ignorance is bliss" -- had I never learnt about software correctness, I'd be producing more. Though I fear it would be 'lower quality' in some way.

Has anyone else felt this? The solution can't be to abandon tests, static analysis, and so on. I did initially think perhaps tests should only be written when a bug is discovered - i.e. reproduce the bug with a failing test, then fix the software. That particular function's rewrite/repair can be guided by static analysis.

I guess so long as the code is written to be reasonably testable, that may work?

Even though I want to write good code, the pressure I put on myself to produce good work seems to drain my soul.

5 comments

[ 2.8 ms ] story [ 32.0 ms ] thread
I think the problem here is tooling. There's a lot of bad tooling in use, it seems to be a universal problem across most if not all domains of software development. I can't really relate to not wanting to write software as a hobby, only doing it as a profession, if anything, for me it is the opposite. And the reason is the same: hating to deal with bad tooling. Fortunately, I get paid to do it when writing software professionally which makes it bearable. In my spare time, I don't, so I don't deal with bad tooling and use only good tools or make my own tools when there's not a good one to grab off the shelf.
I guess I haven't. I also don't write many tests, but I do write a testsuite when I get really stuck with something. For example, I couldn't trust my floating-point implementation in a RISC-V emulator, so I wrote a program that should run inside it that asserts on every operation and C-function that does floating-point calculations. I found so many bugs using that. But, I also don't particularly care, you know.

If you're doing something as a hobby, don't sweat about the tests. Just do it because it's fun - and the second it stops being fun do something else.

I would say (ESPECIALLY for personal projects) that writing bad code that does something is better than writing no code that does nothing.

For personal projects I do really minimal testing if any at all. Again especially for "exploratory" projects.

There is a spot I think for personal projects where lots of tests make all kinds of sense. But just for playing around. Meh. Trust your abilities and embrace the dark side. :)

If you're starting with a blank slate, what insane amount of scaffolding is required to test? If you had a long-running hobby project that hadn't ever been tested, it could be daunting to add tests (Working Effectively with Legacy Code is a great book for this, by the way), but getting started with testing on a greenfield project is trivial in most languages. If you're writing tests on code at work, did someone else do all the work setting it up for you?

I can relate to the general sentiment; I have little ideas all the time, and my desire to "do things right" leads me to go off on tangents configuring CI/CD pipelines and other tools, but I enjoy that too, so I don't feel like it's a waste of time. I just might not end up working on the thing I started out wanting to do.

Specifically, it was building a filesystem abstraction. The language I was working in didn't have a suitable one I could use.

I realized this morning I could have used a mock/test double -- at the time I was thinking I'd need to have some in-memory filesystem so I could later run assertions. I guess I needed to sleep on it.

Anyhow, I'm sure I have run into similar issues where I've felt some pressure to pick between getting some code out and getting some good code out. That is more what this post is about. I was using that as a recent example.