You Are Not Wasting Time

On the SFML Discord and forum, I get to mentor and support a lot of new beginners, often with some of their first steps in programming. It’s not uncommon that they feel like wasting their time, because they can’t figure something out and spend hours or days on it.

I think every programmer, myself included, went through a phase of no visible progression on some topic and the feeling that comes with it.

What you often don’t see until after solving the issue or sometimes even years later, that the time spent trying to solve something isn’t wasted time at all. No, on the contrary, you’re learning new things on multiple levels:

• By digging deeper into the existing code base, you’re starting to understand more of how the application works.
• By looking up how some API does in fact work, instead of assuming or accepting that it “somehow” does, you’re expanding your knowledge on the given API, be it the language itself or some library.
• By googling for similar topics, you refine your research and googling skills of how to narrow down the problem. What keywords will produce the best results, what sites are worth checking out, etc.
• By slowly, but steadily understanding the issue at hand, you’re building up experience, which you can base future work on and guide others through similar trenches.

My vast knowledge on technical details, potential fixes and everything in between is largely based on me having spent hours and days chopping away on a single problem, reading, poking at code, asking questions, etc.

That is also why, I believe it’s not enough to just watch some video or read a book on a topic. To gain the experience on a topic, you also have to spend time doing the work and probably even more important fail doing so. That way you don’t just theoretically know how things should be, but you also practically know the potential pitfalls and get a sort of muscle memory for the given topic.

Recent Anecdote

The other week, I spent two days debugging some odd issue with IObservable and C# events. After these two days, I realized my test setup was flawed, as the test wasn’t waiting for the background thread, but ended up crashing in the XMLSerializer constructor, which lead me down the wrong path.

Spending some more time on it, reading more articles and writing a minimal example, it looks like the production code is written in a way, that makes it impossible to test in a fully determined way.

On one hand I may have “wasted” two to three days on this topic, on the other hand, I learned a lot about Reactive programming in C# with IObservable, how such code can be tested, how our application is actually operating and found some potential improvements, that could help with making the code predictably testable.