Why would a happily married man read a book about dating and finding love ? I’ve found my partner and have my family after all. But there is something very interesting about human relationships : all the different kinds of relationships we are function in similar ways. What makes good friends also makes good romantic partners, and what can make you a good sibling is also often what makes you a nice person to work with.
The book, “How to Not Die Alone”, is written by Logan Ury, a dating coach with a background in behavioral research. It’s a guide on how to change your approach to dating and do things differently to get better results, assuming you read it because you’re single.
A lot of the advice in this book, I found, actually make a lot of sense when working in teams, and working on cross-disciplinary projects that involve other people, teams, and politics in some kind of way. So let’s dive into how the world of dating is exactly like the world of design systems!
What makes dating difficult
According to the author, dating was easier before… I’m not sure I’d say the same regarding creating and maintaining large digital applications, but still, some of the reasons why things feels hard when it comes to designing systems are not so unique.
Personal identities
Modern societies encourages us to be unique, to look for who we truly are and in a way forces us to make decisions that define who we are or want to be. Much unlike the olden days where people’s job were defined by what their parents were doing and their dating pool consisted of people their age in their area.
This is true for us working with technology today : with all the choice and information and tooling available, we often let who we want to be define our choices, and vice versa. There are countless of debates constantly going on, and it sometimes feel like you can’t not have an opinion, and that there are never any grey areas.
The truth is often different, what makes a good choice in a given context might be a bad choice in a different context. In the last decade the CSS community has fought over component versus utility architecture, when in reality it is possible and often a good idea to use them together… But nuance doesn’t make for good blog posts and twitter wars.
Too many options
Just like the dating pool of someone using dating apps has vastly expanded, so have choices when it comes to building things. There is a very good reason why jQuery got so popular when it came out : it was the only library back then, and it worked really well for the needs of that time. Nowadays there are so many frameworks, libraries, methodologies, making choices is difficult.
Not only does it make choosing difficult, it also makes it more difficult to be happy with your choice when you’ve made it. As a frontend developer the framework I enjoy using the most is Vue. The one I use at work is Angular. Everything I know how to easily do in Vue but struggle to do with Angular, I blame on Angular, but if it was the only framework to ever have existed it would be so much better than old fashion vanilla javascript…
I think this is important in two ways : first for juniors, the tools you decide to use are not as important as you may feel initially, unless you’re going for something very obscure, you’ll find work with any mainstream tool you decide to go with.
It’s also important for those of us working on existing systems that have flaws, that carry the burden of old decisions that didn’t age so well, or the work of previous people you just don’t agree with. Sure, if you took all the awesome features of all the alternatives you’d end up with something much better than what you have now, but that’s just fantasy and what matters is how you can make what is there just a little better every time you contribute to it.
Social media
People posting their perfect life on social media making you feel like you never do anything nice. Sounds familiar? How about people giving talks about the incredible solution they used to make this awesome design system for their company with unfathomable complexity, making you miserable about your tiny design system?
The world of social media live off of the extraordinary and subjects us to it daily. But it is not the norm and it is often not what you should strive for. Many design systems out there are fairly small, incomplete, not public and maintained by a bunch of people who got enough of buy-in to craft things as they could on work time… And if this is you, it’s perfectly fine.
It’s very easy to feel inadequate because you don’t move forward as fast as other people do, if your documentation is really lacking or if your design assets are a mess. The design systems that you do see out there are not representative of what working on design systems is.
It’s a big decision
Finding a romantic partner for life is a big decision and that person is going to impact the rest of your life quite a bit… The same is definitely true for how we approach design systems. If you’ve working on one for a while or have contributed to a few, you’ll probably have examples of bad decisions that you then had to deal with forever… You might not have realized it but you probably also enjoyed the benefits of good decisions that were made.
Many decisions when contributing to design systems are important ones, because design systems are such central parts to how teams and projects contribute and work together… Even just how you decide to decide is incredibly important.
And that’s what makes it hard : there are many opportunities to do wrong things and making decisions when stakes are high is always difficult.
I would love to have some kind of advice to give here, but I don’t. Just treat those important decisions are they are : important decisions. Involve people who need to be, research your options, plan and then stick to your plan and if needed, you can always re-evaluate.
Solutions and tips
Thankfully the book doesn’t just list hurdles, but also points toward solutions.
Know your blindspots
According to the author there are 3 tendencies that we all experience to some degree when it comes to dating : Romanticiser (looking for love at first sight), Hesitator (never really ready to commit), and Maximiser (always looking for a more optimized alternative).
This reminded me of an exercise that I did with a Scrum Master I worked with a while ago about motivation. The exercise was simple, we were given a list of things (such as Status, User Impact, Peer Respect, etc) and were asked to order them based on importance for us. The results were really different from a person to another, obviously, but also helped understand where some people came from when we were having arguments about how to do things or where to take our project.
When working on design systems and with different teams and people, I think it’s important to understand that what seems most important to you might not seem as important to other people. First of this will help not thinking others are stupid just because they think differently, but it also help find ways to talk to them, to better understand their point of view and makes yours come across.
Don’t let perfect be the enemy of great
I feel this in many way, such as analysis paralysis, but also constant post-poning of important subjects, waiting for the right circumstances.
It’s sometimes difficult to reconcile, for example, the desire for the system to be consistent, while also changing things when you do have the time to fix everything that already exists. Naming conventions would be a good example. You don’t have one yet, so everything is named according to the mood of whoever made said design/doc/code at the time… Some day the issue is raised but before you even get to discuss what would be better the idea is shut down because there is absolutely no time to fix existing material. This is unfortunate.
The same is true for decisions : it sometimes feels like you need to have everyone on board, research all possible options, anticipate each possible difficulties and hope the perfect solution exists. When we are indeed talking about very important decisions, this makes sense. It might be a lost cause and it’s probably a good idea to give yourself a deadline, but it makes sense. But for smaller decisions, things that can be reverted and so on, you really don’t need it. Even if you did find the perfect solution, circumstances could change in the future and make that decision a bad one anyway. It makes more sense to try and move faster and adapt to changing circumstances, than to try and make perfect decisions in a changing world.
Stop looking for prom dates
The book opposes two kinds of dates : prom dates which provide for a good night of fun and great pictures, and lasting relationships which are meant to grow over time and be a positive impact in both parties lives.
To me this really resonates in a similar way than some tenets did in the article I wrote in 5 Stoic Tenets for Design Systems Contributors. Sometimes the best thing you can do right now is not the most fun, not the flashiest, and might not even be worth mentioning in the list of tasks you did today, but still be what provides the most value over time.
This is how I view writing documentations in many cases, or commenting on pull requests. It’s not really what gets me out of bed in the morning but over time, if the doc are comprehensive and often enough the best place to find correct information then people will naturally look for information there and contribute to it. I aim at creating a virtuous cycle that will bring benefits in the long term, rather than focus my efforts on what looks like the most fun to do right now.
Decide, don’t slide
This advice is not about finding someone, but about how the relationship evolves. The idea is that you shouldn’t just go with the flow and move in together, and then get married because it’s the thing that comes next… Instead these evolutions should seen as opportunity to discuss what these new steps mean to everyone, what each person is looking for and then actually make the decision to move forward if it really makes sense.
In design systems this comes up a lot : everything that you do becomes part of the system, and if it’s very contextual but you don’t make that very clear, you can be sure that in the future it will pop up elsewhere and ruin everything.
I know that earlier I said not to sweat decisions too much, and this kind of sounds like the opposite, but actually I think it shows how we sometimes feel like some things are big decisions, when they aren’t really, and sometimes we think that some things aren’t such big deals and they end up being.
The most frequent example I see is a design choice being made that heavily impact the technical cost of delivering something new and gets it postponed, canceled, or partially done. In some occasions, that design decisions could be changed to something else with little impact for the design team, that would make a huge difference for the tech team. I have never been at a company where this didn’t happen once, yet it’s very rare to see teams having a discussion about these issue and saying “hey, this thing you did is quite complex for us, here are the constraints that we have, do you think you could find something else that would work for you?”.
Parting thoughts
Relationships are very interesting to me, and so is my work, and I always end up finding parallels between the things I read and my job. Have you also found similarities in your dating and work experience on design systems ? What kind of advice would you give to both a friend looking for a love and a co-worker working on the same design system as you do ?
I guess my advice would be to not care as much about how things are going and focus on what you can do to make them better.