Tag Archives: design library

The problems I’m excited to solve

I’ve recently been told that as someone who has passed 40, I should not talk about my age because that may hurt future chances of employment. I disagree with this for two reasons. 

One, ageism is one of the many “isms” people face in employment. It’s also one that seems to get less sympathy which is fair – with age usually comes resources, power, etc that cause this to be far, far less of a challenge than sexism or racism. And I am not trying to dispute or change that assumption. But I am someone with a lot of privilege, so I think I have an obligation to use that to talk about it since I can assume more risk.

Two, I think aging is a benefit. I am far more kind, empathetic, thoughtful than I was in my 20s and even 30s. I’ve suffered loss and experienced deep grief. I’ve not had my own children but I’ve helped in the raising of my niece and nephew as well as trying to be a good role model and source of advice for my younger cousins, of which I have many. I’ve gained a lot of perspective and patience that I didn’t have early in my career. I think that’s led me to be a better person and colleague, hopefully.

All that to say as I’m about to turn 45 in a few months and I reflect back on a programming career that, depending on whether you count personally or professionally is somewhere between 18-25 years, I’ve been thinking about what problems still excite me to solve. What kinds of opportunities or challenges still are processing in the deep recesses of my mind even as I’ve gotten better about shutting off once I step away from my keyboard. Because, like most programmers, even if I’m not actively thinking about some technical problems my mind is often running them on a thread somewhere.

At my current job at MassMutual I’ve worked on several teams, often concurrently. I worked on the relaunch team for the anniversary when I started, helping to build a new brand and site. On a “robo advisor” team, offering financial advice to our customers. On the authentication team handling login and signup. On the calculators team offering a suite of tools to determine how much of different types of protection our customers might need. Finally on a team that builds a tool that allows advisors to service their book of business and customers, handling common transactions, and providing policy details. Also a few other teams here or there to help and, again, I was often working on two or more of these teams concurrently.

With the exception of all but the first these are what I’d refer to as application teams – ones building a specific application for a purpose. But for the last several years, since before even the pandemic I believe I’ve honestly lost track, I’ve also worked on our design library team. Building what one of my colleagues described as “Blueprint Design System is MassMutual’s design system that includes reusable styles and components that are consistent, accessible, and responsive”.

Aside, this got further confusing as there already was a blueprint CSS framework which only I was aware of and hadn’t been updated in around a decade when I brought it up, again showing my age. Also MassMutual later acquired a company with Blueprint in the name adding internal confusion at times.

My point is that this last team has been one of the great joys of my career for multiple reasons. 

First, on most previous teams I’d worked with I’d been the sole “UX Developer” type. Which is to say I was the one that did most, if not all, of the HTML and CSS / SASS development usually with only cursory review by the rest of my team. This was the first time I could actually both give and receive constructive criticism from other developers that had an interest and skill set very similar to mine. As a result my skills in both writing and evaluating code grew immensely. And I learned a great deal about what I should comment on and the tone it should carry, through a lot of mistakes.

Second, the team was a mix of developers and designers working together to provide patterns in Figma, HTML / CSS, and React depending on the user’s need. Which is to say if someone was a designer they could use Figma components to build designs for the applications they worked with. If someone was a developer and used React they could use our React components and if they used some other JavaScript library they could use our CSS file and HTML patterns to build their own components. But to my first note here being able to collaborate with people in design was very rewarding as it caused me to rethink problems and challenged many assumptions I had, causing me to grow to be less rigid as it was less of design “throwing something over the wall” and more of a collective effort. We both grew more invested in each other’s success by this partnership. Plus I was fortunate to work on a team just loaded with lovely and talented people, which is always a bonus.

Third, approaching problems from a library versus an application perspective causes you to think differently about solutions. It goes back to that description from my colleague – reusable and consistent. How do you make something that is useful to teams – managing that slider between specific and generic? How do you offer some variants while also constraining them so it’s not just a soup of helper classes and multiple components that all solve similar problems only slightly differently so that it’s confusing what teams should use and the product cohesion suffers? Because, again, the goal is to provide a library in which multiple teams are using so that the site looks more like it’s built by one team instead of dozens each building small sections of it.

We built this on top of the bootstrap library, something which several jobs and multiple freelance gigs I’ve worked with have used so I had a ton of familiarity with. I’d also grown to understand its problems – by trying to be everything to everyone it suffers. Internally we took several measures to limit this like not including almost all of the utilities and helpers but also being mindful of the examples we used – trying to limit the variants we talked about in our internal documentation even if someone familiar with the underlying framework could understand more options might be available, although potentially not branded.

This also gave us some unique challenges with branding and cohesion. Often we would want something to look a certain way, say like an H2, but we would not know where in the code it may appear semantically. In the bootstrap model you’d use some helper classes. But where we had so many consumers we wanted to make it simple if something changed – like if a card header suddenly went from looking like an H2 to an H3 – so they’d have minimal code changes beyond ticking up the version, if we could help it. One of my colleagues started playing with SASS placeholders and it’s something we ended up using extensively.

This would allow us to build a bunch of typographic styles and instead of having them assign a class we’d use a placeholder so we could do something like .card .title { @extend %h2; }, moving the helper classes from the HTML to the SASS basically. Which means if later on it should be %h3 or %h4 we’d simply change the SASS, tick up the version, and they’d update – no further code changes.

Maybe this is a simple thing and everyone is doing it. I know in the bootstrap SASS they do something similar, though often through mixins instead. But it just was something I found exciting and powerful, enabling me to solve problems in a much cleaner way. And that was many of the things I found on this team – when I had to think about how to build a library to help other people, what concessions and trade offs did I have to make in order to make their lives as easy as possible? That was interesting and kindled my passion for my craft and work.

I think the library has brought a lot of value. Many of the teams at MassMutual use it, meaning they don’t have to write their own CSS, patterns, or components – saving them untold amounts of time. The company benefits as it’s more consistent in design and branding, as well as being responsive and accessible since that’s built into the library components. And those of us working on it enjoy working with each other to solve problems as well as the reward of hearing feedback from other developers who benefitted.

So to answer my original question – these are the types of problems I’m excited to solve. Using my skills and experience to provide library components that save my colleagues time and effort while also providing the company I work for with multiple types of value. Finding unique and interesting ways to solve those problems and manage the tradeoffs that are inherent in anything we do. Using my skills and talents to help people in whatever way I can, even if it might not change the world.

I hope I can continue to be blessed with opportunities to solve problems like this for however long the rest of my career is.