I am a bad developer

Posted on Fri 23 October 2020 in python

I write terrible code.

Often, the work I do is in isolation. I'm not working with a team, adhering to any coding standard. I would best describe the code I write as thinking out loud. A series of non-cohesive statements testing out reactions. It is undoubtedly "bad" code.

There is little separation of concerns.

Most of the code I write is in a single file. The file is a collection of function definitions. No inheritance, no overloading, only simple functions. When that file gets too long or feels challenging to manage, a set of related functions is moved to a new file, appropriately named, of course. No classes, unless explicitly necessary to use with another library. As the application grows, the main.py file will eventually turn into the application driver. Generally, it will resemble a CLI for testing out various API functionalities.

There are comments everywhere.

I continuously write little notes in the code. Sometimes, I can see far enough ahead in the project to start writing the code right away. More often, I write comments and fill in the code afterward. I have recently iterated on this process and use GIVEN, WHEN, THEN statements in the comments for problem sections. These comments help to clearly define the input data, what the function will do and what the function will return.

I optimize prematurely.

Everyone says not to do this. I've been lectured many times about it even. I catch myself doing it, and I still can't stop myself. Sometimes I see a problem and I feel the need to solve it.

I don't practice TDD.

I usually do not do test-driven development, unless the setup process to test manually is too long. When I attempt TTD, it seems to encourage me to write throw-away tests. Tests that I do write are primarily tracer-bullet tests that allow me to branch in different directions. I don't want to spend time debugging the test suite, mocking services, etc. Quite simply, I want to see progress as fast as possible. Instead of automated tests, the code is tested manually, with print and log statements. You see, all of this is a process of discovery. It's hard to write good tests until you have had some time to dig in and experiment a little.

And then, I start over.

You see, it's okay to write "bad" code. It is often a good idea.
Writing bad code will give you a good idea of how the application is going to work. There is less of a haze surrounding the problem. We can visualize our way through the application. After building the prototype, we have a much better mental model of how to solve the problem.

Don't be afraid to write "bad" code.