Stoic Driven Development
If Marcus Aurelius and his philosophical peers were modern-day software engineers, what wisdom might they impart? Let's delve into the stoic-driven developer mindset:
1. What stands in the way becomes the way
Approach new technologies and frameworks with humility. Technical lead Marcus Aurelius advises us to resist the temptation to judge based solely on prior experience or hearsay. Rather than seeing new libraries or methodologies you will be using in your new job as obstacles, view them as opportunities to expand and diversify your skillset. Embrace new approaches and paradigms, transforming challenges into learning experiences.
It is impossible for a man to learn what he thinks he already knows.
2. Be tolerant with others and strict with yourself
Scrutinize your own work diligently, however, be open to different perspectives during code reviews. While maintaining high standards, recognize the value of diverse approaches and avoid unnecessary clashes over personal coding styles.
3. Don't expect that all feature requests are good, but that your code goes well with all feature requests
Echoing Junior developer Epictetus, keep your code open for extension but closed for modifications. Nothing ever happens without change, and as all things in this world, so do requirements change. Embrace the inevitable change in your solutions and leave in some wiggle room to accommodate future enhancements.
4. You don't have to have an opinion about this
Not everything requires a strong opinion or emotional investment. Maintain a level-headed approach, avoiding unnecessary conflicts over preferences in code reviews, post mortems, and tech choices.
5. Everything that happens, happens as it should, and if you observe carefully, you will find this to be so
In the predictable realm of software engineering, view problems as solvable puzzles. Internalize the understanding that software, unlike human emotions, or evolution, follows a logical flow. Debugging becomes a methodical process when approached as a series of traceable and reproducible data flows.
Data gets taken from one place (user input, database, API, fs, ...), it gets manipulated, and moved somewhere else (database, email, API, etc.). That's all that happens, so when investigating a problem you know the outcome already and can work back from there.
The same is also applicable to development. Start by thinking "how do I move this data from here to there" rather than fixating on a preconceived solution.
6. If someone can prove me wrong and show me my mistake in any thought or action, I shall gladly change.
This is the stoic idea of "Strong opinions held weakly." Be open to constructive criticism, and willingly adapt your approach when presented with evidence or insights that challenge your preferences.
7. Focus on What You Can Control
Epictetus believed in concentrating on the aspects of your project that you can influence and improve. Complaining about a company policy to your peer won't fix said policy, and it will drain the finite energy you have for the day that you could have used for something more productive instead.
The same should be considered in planning out new features. Rather than delegating them to external teams, strive to own your software journey to allow for independent changes in the future.
8. Memento Mori: Remember You Will Debug
Accept that bugs and issues are inevitable. By acknowledging the impermanence of perfect code, you become better equipped to handle setbacks. Approach bugs with the mindset that they are a natural part of the development lifecycle.
9. We suffer more often in imagination than in reality.
Remember that it's not things that upset us, it's our judgement of it. Recognize that your judgment, more than the problem itself, can contribute to unnecessary stress.
Senior React.js Engineer Senecar advises against overreacting and planning to migrate the entire project upon stumbling on tech debt. Senecar practiced this daily the time he took over a redux-based GraphQL project. You can approach it step by step, line by line, ticket by ticket, and leave the code a little better than you found it. This is also the idea behind my e-book Intent Driven Development, simplifying the day-to-day code we write, rather than rewriting the entire code base.
^ Generated with DALL-E.
And there you have it, hopefully you found some enjoyment and truth from this light-hearted article! If you want to get serious with this philosophy look no further than Marcus Aurelius' book "Mediations", or Epictetus' "The Manual", they are quite fascinating to read!