There’s a sense of satisfaction that sticks with you when you beat your head against a problem for so long and then come to a workable solution that allows you to implement the awesome vision the team has crafted without much compromise.
The above is me showing Sid, who was our User Experience Lead at OpenStudy, the first working prototype of the OpenStudy SmartScore Graph, which depicts a user’s SmartScore over time.
I don’t know if you’ve ever tried to find a line chart that would change its color mid-line based on where in the range the next point landed, but we couldn’t find anything workable when we were looking. So, I extended g.raphael to support it for our needs. The prototype I showed Sid eventually lead to the implementation final version that’s currently live on OpenStudy profiles.
To date, this remains one of the things that I did while I was working at OpenStudy that I am most proud of. And I can sit here today and enjoy that memory, and ultimately share the work I did on this problem with everyone else, because we had a few strong culture elements on our team before I ever got there. Specifically,
- Tenacity – We had tried a number of different solutions before attempting to customize g.raphael. They all failed. The key is here at this point we decided that we had a bone to pick. We considered compromising the design at a few points while this was still in progress, but instead we decided to do that only after all other options were proven to be unfeasible. Sid wanted the strong color association with the score. I was just determined to beat some graphing library into submission for not already doing this for me. ?
- Experimentation – We were ok with investing some time walking down the path of trying to customize g.raphael, even given that none of us had any strong background in SVG or VML graphing. I picked apart the library that day and made sense of some horrible code, and was ultimately successful because we chose not to consider unfamiliar territory as predetermined defeat. We invested some time building a solution that exactly met our needs instead of buying one that met half of them and depriving me of the opportunity to learn what I did about graphing.
There are probably a whole host of other culture elements that played a role as well, but those are the two that stick out to me as I review the Flowdock conversations from that evening. I think there was a lot to be learned from my experiences at OpenStudy, but the biggest one I take away from this memory is that these two culture features on a team are important to me. Being willing to take the road less traveled to get the best solution instead of throwing money at the problem gives your engineers the opportunity to learn that they wouldn’t have otherwise. If I have one goal in my career, it’s to never be someone who gets pigeonholed into doing one thing for multiple decades. Working at places that embrace the attitudes above ensure that I’m always going to be learning, and I’ll always have options that are beneficial to me, and my company, when I decide it’s time to do something a little bit different than what I had been doing before.
I would make the argument that I’m good at what I do. You have everything you need to make your own judgement readily available, if you’d like to. That said, if you are ever trying to recruit someone who shares my views on the above, I’d say this: convincing me that your company culture embraces those values is the starting point for the conversation. If you ever want me to take you, or the company you’re trying to sell me on, seriously, don’t start the conversation talking about benefits. Sell me that you’ve got a team that’s going to craft a challenging vision and a culture that would let me hack on a graph until 3 AM to achieve it if I want to. That is how you get my attention.
End of song.