1. The burnout

Does anyone else here ever get -into- it thinking they can hammer that one last thing out for the night, end up spending 4-5 more grueling hours of totally grind and realized they got so drained out that you pretty much messed everything up? I do that a lot. Don't do that.

So many times where I bang my head into a wall for 4 hours trying to fix a bug, then give up and go to sleep then come back the next day and fix it in 30 minutes.

2. Tutorial Hell

Watching a few videos and reading a few articles about a topic is helpful when you are starting. However, there is a false sense of progression that comes from consuming loads of tutorials and never really starting your own project.

Your own projects can be really small by the way! Being able to start something from beginning to end that wasn't from a tutorial is where the magic happens. When you run into roadblocks that you figure out on your own from googling, that learning seems to stick the best.

The more projects you build, the larger your library of code to reference becomes. I find myself all the time going back and grabbing snippets of code from previous projects. Enough of these projects over time and you will be amazed at your progress.

3. Posture check

Gotta sit properly to not put so much pressure on your back muscles to keep posture.

Basically sit like on a very thin horse, legs under you, this way gravity center is underneath and you can move freely which is crucial for spinal and joint health.

There are chairs for this, they are even swaying!

4. The x and y

Don't get into the habit of giving your variables short names that mean nothing. Don't name variables x or y. Give them descriptive names like numberOfTriesLeft and priceOfItem. To add: for boolean typed variables, ask a question on the state of things. E.g. IsActive, IsPaid, IsFloating, IsDeletable, etc.

Bonus: (some people like it and some not) add an identifier of the type of variable as a prefix. E.g. iLives (for integers), fTokens (for floats), bIsAlive (for booleans), etc. To check the type faster than hovering on it in your IDE.

5. Perfectionism

Research is incredible important when programming, but overthinking to much leads to not getting something to paper. Decide what to do, implement even a shitty first draft that somehow works and then go over it for refactoring. Only once or twice. If you‘re still unhappy with it, make a note for later and start with the next thing otherwise you‘ll sit on one feature until there‘s a new framework/lib or whatever which can do what you‘re about to write in less lines and you start over again.

An example: I recently sat 5 days to decide over the API standard (openAPI, GraphQL, oData) to use for a simple privat project. Well, setting it up in my project took me less than a day… and that for a project which probably no one will take advantage of except me (just a personal website/blog). Don‘t overengineer.

1. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler