As I’ve evaluated contradicting opinions in different areas of software engineering and development like bootcamps vs college degrees, this framework vs that, or a MacBook Pro butterfly keyboard vs an 1850’s typewriter, I‘ve found an analogy that helps me make decisions. It boils down to one central idea:
Your life is an open source project, and you are its maintainer.
Hear me out through a few parallels:
- Just like open source software benefits from a roadmap, having life goals with specific dates coerces you into improving
- An open source code of conduct is like your individual values and morals that dictate your behavior
- Being frugal in what is added to a project’s API is sort of like saying no to that bowling league your friend wants you to join
When it comes to how the roadmap is outlined, how the code of conduct is established, and what changes are made to the API, the buck stops with the maintainer(s). Along the same vein, what decisions you make in how to develop and grow are ultimately up to you, the maintainer.
You’ll be presented with amazing opportunities and everyone else will chime in with an opinion as to what you should do, but only you have the context necessary to answer them.
Because great open source maintainers tend to also be great people (which I don’t think is coincidental), I want to outline why I think planning, building, and maintaining a great open source project relates to developing a great life.
Just like with open source, you need to start with a plan, and you have a community of individuals that have a vested interest in what you do. They’ll sometimes have great advice and they’ll sometimes have this advice:
What other people suggest you should do might not align with what vision you have for the future at all!
Have a Roadmap
Good open source software will have a roadmap that outlines a timeline of what will be developed next, and by what dates.
From a code standpoint, right off the bat and no matter what you’re working on, you should prioritize your goals. What is most important to do next? Sometimes what is important may not be what is exciting. Maybe being able to edit your spreadsheets in VR can wait while you refactor that code you wrote years back when you thought
float: right !important was a good idea.
With expectations from life, set goals, give yourself deadlines, and then be accountable. Sometimes the most rewarding feelings come from abstracting away the simple chores like paying bills. You’ll start feeling like your own psychotic fitness coach and you’ll save yourself ₹1200/month for the gym membership.
Then with unfailing resolve, the evangelists of all things new-and-improved will come knocking at your door expecting to you to bend to their demands.
“We need support for Rock Band Guitars if this library is going to be used!” they’ll say.
“This is a string parsing library.” you’ll respond.
“Who’s going to use that without Rock Band Guitars?” they’ll retort.
“Sorry AFK” you’ll reply.
Prioritize attention to items on your roadmap, and be ready to filter out noise from the periphery.
Have a Code of Conduct
Open source projects often adopt a code of conduct that contributors must abide by to work on the codebase. Take a code of conduct from a popular project out of the context of software and you’ll often find it’s still relevant. One open source code of conduct gives these points to follow:
- be friendly and patient
- be welcoming
- be considerate
- be respectful
If you squint your eyes and slowly move your head away from your monitor you can almost see the bullet points above forming the text of the Sermon on the Mount from the New Testament.
Consider adding similar characteristics to your personal code of conduct and then commit to live by it.
Nobody enjoys being around a negative Nelly (except other negative Nelly’s). Welcome diversity, make new friendships, spread optimism, and extend the positive reach of open source. Just like people are drawn to projects that are accepting and welcoming of newcomers, people will be drawn to individuals that are friendly and start opening doors for you if you treat them fairly.
Adopting guiding principles like these also mitigate your individual contribution to the dumpster fires of unhelpful Reddit and HackerNews threads (a noble cause indeed).
To actually make an open source project, you probably need to know how to code .
Learn a thing or two and keep iterating!
Learning and Development
The services your project offers should be important to you. Will your app offer a broad variety of functions, or do just a few things particularly well? Will you be Samsung and crank out 45 subpar phones every year, or be Apple, do the iPhone and own it?
Like me, I’m sure you’ll encounter articles with titles like “200 Free Courses you can Start Today” or “Why you should learn X”. There is an overwhelming wave of content, and no one has the time to absorb it all. Technologists and developers are hard-pressed to always be learning and adopting new technologies and trends, but it’s hard to know what to do next. You’re going to have to make decisions about what you ignore and what you choose to specialize in.
Making the colossal mountain of content more approachable is the concept of the anti-library from Nassim Taleb. In his book The Black Swan, he tells the story of Italian writer Umberto Eco:
He is the owner of a large personal library (containing thirty thousand books), and separates visitors into two categories: those who react with “Wow! Signore professore dottore Eco, what a library you have! How many of these books have you read?” and the others — a very small minority — who get the point that a private library is not an ego-boosting appendage but a research tool.
Read books are far less valuable than unread ones.
This concept is related to the vast expanse of tutorials and blog posts that live online. The greater the unread content, the greater potential for learning.
If there is something that a tutorial can be written for, you can probably find it. Dora the Explorer could probably even find it, and she has to have 6 year olds point out where the banana tree is to her.
Decide what you want to learn and go learn it, but don’t feel crippled by not knowing, your anti-library (these days, Google) could be one of your finest assets.
Ralph Waldo Emerson famously said:
"The height of the pinnacle is determined by the breadth of the base."
This can be interpreted to mean how high you are capable of growing is first determined by how well grounded and strongly rooted your core values are.
If you want to become an expert, start by rooting yourself in fundamentals and even developing simple traits like perseverance and diligence. Being really good at something can often be boiled down to simply working hard and managing your time well.
A big part of marketing for an open source project is the organic growth from maintainers helping users resolve issues while using their libraries. Being helpful and supporting others using their project starts to become a part of who they are, and it feeds into loads of people wanting to use their libraries as a result.
I believe if you just start becoming a good person — no matter what you do — people will want to work with you.
As a library grows, it’ll (hopefully) see contributions from the community supporting it more, and the question of how the project moves forward becomes more complex.
Similarly, as you become more and more capable throughout your career, more and more opportunities will surely present themselves and give you even more choices. If you haven’t started establishing a roadmap you’ll find it even harder to turn down that freelance WordPress gig someone on LinkedIn reached out to you about.
Learn to Say No
Because decisions only get more complicated with time, it can be especially important to learn to say no.
David Heinemeier Hansson wrote:
Use the power of no to get your priorities straight. Take the brief discomfort of confrontation up front and avoid the long regret down the line.
You won’t have time to meet everyone else’s edge case, so you have to prioritize. A maintainer will have to disappoint someone, and it’s easier to articulate a message that disappoints if you have a roadmap in writing already.
In the recent movie Christopher Robin, the story follows Christopher who has become over-absorbed in his work such that his family begins to feel distanced from him. Christopher Robin struggles as his work becomes his first priority, but his family is what he values most.
Christopher gets advice from an uncharacteristically wise plush bear
During one scene, innocent Roo has the following pointed exchange with Christopher while he’s away from family, referring to his briefcase he always carries with him:
Roo: What’s a Madeline? Is it more important than your case of important things?
Christopher: Madeline’s my daughter, so, yes, of course. Absolutely. She means the world to me.
Roo: Then why isn’t she with you?
If work is what you value first, then taking on more work will likely be valuable to you. However, if you are like 91.6% of respondents to the World Values Survey (hi! 👋), then you very likely put your family first too.
Work is likely also “Very important” or “Rather important” to you according to the results of the survey, but these results demonstrate the general prioritization of family as one of the most valued categories.
Refactor and Simplify
Time to work on open source doesn’t come free. Perhaps you’ll find the silver bullet of time management one day, but until then resist the urge to rewrite everything on a blockchain.
Dead code is dangerous to keep around, keeping it in repositories means more to maintain and more potential to break things. Similarly, the more responsibilities you are balancing between family, career, religion, and health means more to manage and more that can stress you.
A popular analogy about work life balance being similar to juggling glass and rubber balls demonstrates the necessity of simplification in personal growth. The balls represent different responsibilities in your life. If you drop a rubber ball you can pick it back up no problem, but glass balls can shatter when dropped. You decide which responsibilities represent glass balls and which represent rubber balls — as well as how many of them you are juggling at any given point. If you need to let something drop, dropping a rubber ball can be more easily recovered from. Decide what your glass balls are and focus on keeping them in the air.
According to Bruce Lee:
"It’s not the daily increase but daily decrease. Hack away at the unessential."
Developers worry about cutting bundle sizes so small they could fit through a coffee straw. Have you ever considered the bundle size comprised of all the priorities you’re balancing in your life? If cutting bundle sizes makes the web experience faster and smoother, perhaps removing some fluff from the edges of your life could do the same for it.
Measure your Growth
Everything scales, and so does your influence.
As a library grows and more users adopt it maintainers get stretched thinner and thinner trying to meet the needs of a growing community of users.
Some species of bamboo demonstrate how difficult it can be to measure growth, but also the importance of being strongly rooted. Some of these species of bamboo can grow at astronomical rates of 4cm (1.6in) an hour. It’s easy to watch peers and friends around you growing at those speeds and wondering what you are doing wrong. That kind of growth is possible because bamboo can take a long time to get established where it’s planted, and your current growth might be more focused on your roots, which is okay too.
The visible signs of growth come in time. Your metric of choice to keep track of progress on your goals might be obfuscated by all sorts of other variables, but trust that your impact will still be there.