|
|
|
|
|
by trommlp
897 days ago
|
|
I don't know all the reasons individual developers would want a more complicated piece of software. Might be to show off, yes, or to learn about a new technology to the detriment of those developers that come after and the Ops people who will have to maintain it. Or they genuinely believe complicated is better. But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse. This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects! |
|
As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.
Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.
I even started to finish and deploy my personal projects. It's that effective for me.
Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.