Notes on How to get worse at programming (Andreas Kling)

I just found a video by Andreas Kling from 6 years ago (2019.07.23): “Commute talk: How to get worse at programming”

Funnily enough, the tips given are somehow what everyone is encouraged to do on a daily basis.

1. “Always start with googling and finding existing solutions to your project / problem.”

As if every project has to be created once only. That sounds stupid when you think about other fields. “Shit someone already made a bottle of water, I guess I should find another idea now.”

If you want to be the first or only, doing that instantly kills your motivation. Work on the project because you personally enjoy it and want to be the person who can do it. Rule of thumb: A problem you really care about is one where someone else solving it still brings you joy. Mastery is not about competition.

The problem is that only “novelty” is rewarded (especially in research), pushing people to more hyped up topics without revisiting existing ones.

2. “Always check sites like StackOverflow to find good/best-practice algorithms to use for your problem.”

Of course someone thought about the best data structure to tackle your problem, right? Why waste time thinking about how to combine what you know to get a grasp on using your knowledge to solve problems.

Remember, best practices (aka average practices) are a way for you to never practice.

3. “Look for libraries that already solve what you need to solve yourself.”

Never re-invent the wheel, we have a deadline, why write so many lines and not build on other frameworks?

But if we use this library we benefit from free new features and fixes!

Valid points, but assess them every time and don’t blindly go in that direction. Don’t be the person who only puts libraries together. You can be the one creating your own, but that requires depending on yourself only.

4. “Never put your code on the internet.”

Now that your baby is alive, never show it to anyone. What if someone says it’s ugly?

Build this resilience step by step. I am guilty of not doing that myself, but this is healthy to have within the team. Healthy roasting sessions help in the right culture.

5. “When something just works, leave it and consider the project done.”

That’s the “what else can be done anyways? it works”.

If you depend on external libraries and other people’s best practices, you will feel that you have limited amount of control over your creation. This pushes you to avoid diving into nice rabbit holes because it’s too much friction to change anything now. If you respect all the above, this becomes easier to avoid.

Just watch the talk, it’s fun. I have so much respect for this man.