As software developers, we all aim to write amazing, beautiful code. It’s part of what motivates us. But remember, the real goal is to ship something that people can use. And writing beautiful code isn’t necessarily what makes that happen (example).
Don’t be a clean code zealot. Clean code is not a goal.
This hit home for me after years working with an incredibly tedious and impractical code review process at a previous company. The reviews went way beyond sussing out bugs and tech debt and into opinions about the “right” approach for days on end. The team was unproductive and unhappy, and we still shipped plenty of bugs.
Sure, aim for great code. But there is a practical point where you need to let go and ship something that works.
Let clean code guide you. Then let it go.
As an engineer, yes, be elegant. But more than that, be practical. Voltaire put it elegantly 😆 way back in the day.
Great overview of building an app that works offline first as a means to a great user experience.
The offline-first approach is not the universal solution to every problem you will experience with unreliable network connectivity – it heavily depends on your app’s requirements. It’s more like a design approach that lets you focus on what really matters to your end user: a robust app with a great user experience.
A technical pet peeve of mine, this post does a nice job articulating why “manager” classes in software design can be a problem. To me, a “manager” class is like saying, “this class does some stuff” and the stuff has no boundary. But what does this class do? What is it’s purpose? It might be a sign of an unfocused and unsustainable design.
Or as the post says:
Managers can be a symptom of poorly-defined responsibilities. When you think about it, the word “Manager” means nothing. In object oriented programming,everyclass is a manager. Cocoa Touch could haveUIApplicationManager,UIViewManager, and even a humbleNSStringManager.