Ask HN: How can I “reset” the way I approach building software?

15 points by mousebunny 3 years ago | 9 comments

I've been out of school and working full-time at a well-regarded company doing full-stack Web Dev for 5 years now. But despite my career going well, I still feel like my approach to building software, both at work and for my personal projects, is not nearly as solid as I'd expect. In particular, I have a desire to write simple and straightforward software, but for whatever reason feel incapable of doing so, always making things way too complex.

For example, I've been working on a side-project for about a month now, and I feel like half of that time has been spent going back and forth and back and forth between different code design decisions.

First I wanted to implement an event-driven architecture, so I read articles and watched talks and landed on an event-sourcing style system, where I'd persist a log of all events that occurred in the app. I also incorporated DDD concepts like repos and domain objects, and persisted all app state in SQlite.

Then I realized that I was making things way too complicated for the first iteration of my little project, and tried to re-write it in a very plain and straightforward style, e.g. just using an ORM instead of a repo pattern, no event bus, keeping more ephemeral state in-memory; just objects talking to other objects.

But even after I completely re-implemented everything, I _still_ feel like I'm making things way too complicated, and am getting worried that maybe I'm just incapable, for whatever reason, of writing straightforward, simple software. When approaching a problem, I feel like my brain skips about 10 steps of simpler options before making a decision.

I'm looking for any advice or material that would help be get unstuck in my software building process and learn how to write _simple_ software.

EDIT: Specific ask: does anyone have any go-to examples of well-written, simple software? Either an actual open source repo, or a walkthrough-style article.

verdverm 3 years ago |

A better way to think about this is

(1) you are still young and learning

(2) you should broaden your toolset (patterns) and sounds like you are already doing this, good job!

(3) with time, you will become better because you have more options to select as the best option given the context

(4) all software seems to experience the curse of complexity, it's hard to keep it simple once you have to deal with the real world and all the edge cases that it presents

Sounds like you are doing the things you need to be doing and just need to keep at it.

---

edit, one strategy you may consider is to solve the same problem (program the same thing) with different languages, technologies, and patterns. After, try the same thing on something else. This will give you a breadth of contexts

another strategy is to work on the same project for a long time. This will uncover problems you only reach when a project becomes sufficiently mature. Often you will need to rewrite, refactor, and swap out technologies or patterns.

mousebunny 3 years ago | |

Thank you for the reply!

> with time, you will become better because you have more options to select as the best option given the context

This is one of the parts I feel like I'm actually behind on in my career, despite (and probably in part caused by) having read tons and tons of articles about things like Hexagonal Architecture, DDD, layered architectures, Functional Core Imperative Shell, etc. Despite my almost now 10-years of programming experience, I still could pretty much only come up with two designs for my side-project, on two different extremes

1. A fully de-coupled and well layered event-driven solution that is way too complex for a small side project (and probably too complex for me to implement properly at this point)

2. A "simple" design where I have a few large classes that handle just about everything, with no good model on how to break up the different concepts, aside from just...naively breaking up big classes into smaller classes

Maybe I'm just being overly-critical of what I created for #2, but I just wish I had a better feel for where to draw the lines in my app.

verdverm 3 years ago | | |

Yet another strategy is to go work on other people's projects. Go find something close to what you built (or several) and see how their code is organized. Spend some time with it, change things, add a feature you want.

I have lots of todos of various sizes on my project if you are interested, and one of the goals is to explore, capture, and reuse software patterns much more easily

https://github.com/hofstadter-io/hof

ping me in slack if you'd like to give it a shot

stefanos82 3 years ago |

One thing I learned from university during my databases course was the use of Database Normalization, also known as Normal Forms.

It blew my mind because, I was already applying it in my daily life without realizing it, but in a different method: I would write things down to help me clear up my thought process; eventually I would organize my notes as bullet points and whatever could be placed under a specific bullet point, it would end up as sub-category, well sub-bullet that is.

Eventually it helped me keep my mind organized, let alone my projects, and meet the deadlines with approximation 95% success; the rest percentage is for unpredictable circumstances that can happen to anyone of course.

So, my advice would be as follows:

    * Start small, start simple (KISS principle). 
    * Have your project's logic written down; personally I prefer on traditional notepad.
    * Monolith first; most of the times going full microservices in advance is a premature action.
    * Prefer battle - tested libraries than writing your own.
    * Ask for advice or feedback if you get stuck.
    * Invest time reading others' code; that's how you become better at programming.
    * Last but not least, apply the UNIX philosophy (if possible); "Write programs that do one thing and do it well."

I hope my feedback helped somehow ¯\_(ツ)_/¯ ...

kareemsabri 3 years ago |

All I can give is my experience (been coding professionally for maybe 12-15 years) but I never looked at patterns like you are for a LONG time. I had no choice but to code in a "simple, straightforward" style because I didn't know anything fancy. I just did everything the normal, dumb way.

That said, things often become complicated because you don't have the skills to keep them simple (for example, you draw the boundaries between your modules wrong, or you fail to abstract the right things, leading to tight coupling and information leaking). So it's pretty normal for your software to be a mess for the first decade or so.

You should just keep writing your project, and as you find as the developer certain things on it are harder than they should be / frustrating / take too long, that will indicate a problem. Then you can keep trying to refactor until you get it right. Writing bad software is how you learn to write good software.

You asked for an example and I just gave you a bunch of philosophy, so I'll give you at least one. It depends on your language and what you're doing but I use Go a lot, and I think Stripe is pretty good at keeping things straightforward https://github.com/stripe/stripe-go

rockemsockem 3 years ago |

It sounds like you're probably overthinking and overengineering your solutions. Knowing common patterns and useful architectures are good for recognizing when your problem needs them, but most software just doesn't need to scale to ridiculous levels and a lot of abstractions can get in the way even when applications have to be highly scalable.

My advice would be to try to optimize for what makes it possible for you to get things done the fastest. Ultimately that's the point of any abstraction, that and improving readability. Don't try and apply fancy patterns, just focus on solving the problems you're setting out to solve. If you find yourself working on a project long enough then you'll probably naturally find a need to start applying more complex architectures and abstractions, but it's almost never a good idea to start with those, even on a large project at a company that everyone "knows" will have to scale. Maybe especially in that scenario.

meitros 3 years ago |

How about looking at the early git history of a project? One in particular that I’m thinking of is Excalidraw https://github.com/excalidraw/excalidraw - it started out pretty simple and evolved over time

Jensson 3 years ago |

Straightforward code is harder to write than complex code, it comes with experience. Beginners writes straightforward code for small problems, you need a lot of experience to do it for larger problems.

uraura 3 years ago |

Sometimes I don't follow DRY and SOLID. Sometimes I avoid abstraction. I can't give a solution which is suitable for all scenarios.