At the start of 2013, I was working as a software developer for a consulting company called DevFacto in Edmonton AB, Canada. By the end of 2013, I was still working as a software developer, however, for a different company called Emerald Therapeutics in Menlo Park, California. This has been quite a big change for myself so to start off 2014 I’m going to take some time to reflect on my change in employment situation.
I believe my mug is still featured in at least one piece of stock photography on the DevFacto website (which is nothing if not flattering). It was my first job out of university and the skills that I developed while working there have proved to be invaluable. I had the privilege of working with an amazing group of people (both professionally and personally), some of whom I became close friends with. It was a hard decision to leave and I miss my former colleagues deeply. Throughout my tenure there, I grew tremendously both as a person and as a software developer. I will forever cherish the (almost) 2 years I spent there.
Early 2013, and opportunity arose for me to move down to California and work for a small biotech startup (Emerald Therapeutics). As of the time of writing I don’t think we have anything on our website but someday that link will have something interesting behind it.
I was starting to get a little restless at my previous job and I wanted to try working on something more long-term. I wanted to try working on something that was more product-like that I could contribute to the development of for more than a few months (most of my past consulting projects were in the range of about 4 months). I was starting to find consulting a little exhausting. One would put a lot of effort into getting started with a new team/business/problem, and by the time you were familiar with everything and starting to get into a groove, the project would be over and you would be onto something completely different. On the other hand, having the variety of projects/clients was incredibly valuable and has made me a better developer as a result.
I’ve always wanted to work on something related to the sciences, something that I could ascribe more “meaning” to. Something that could potentially have global significance to society, instead of just improving business process or generating more revenue. That’s not to say that those aren’t worthwhile pursuits, I’ve always just been wanting for something more. As a result, the prospect of working for a small company trying to innovate in the fields of biotechnology and pharmaceutical research was incredibly exciting.
So, I went through the most intense interview process I have ever undergone. I took part in a few Skype interviews, wrote the hardest test I have ever written, and flew down to California in June to do the in person interview. It was a full day of activities and by the time I got back to my friend’s place (where I was staying) I pretty much just passed out after walking in the door. I spent a bit more time visiting the San Francisco area and flew back home to Edmonton a few days later. Then the waiting game began.
I heard back a week or two later with a job offer (approaching the end of June now). I “thought” about it overnight (like I would have said no). Not only did they want to hire me, they wanted me to start August 1. That’s essentially one month to quit my current job, start a new job, and move between countries. It was a ridiculous thought at the time, yet it was definitely possible. So I did it. That month was a whirlwind of wrapping stuff up at work, arranging flights, immigration, packing, moving, and saying goodbye to everyone very abruptly.
As for the actual transition from DevFacto to Emerald: it’s been pretty smooth. I think that working as a consultant, the fact that I had to change teams/projects/clients so frequently helped a lot in that regard. If nothing else, being a consultant taught me how to adapt quickly. Whether it be to a new business domain, a new team, or a new language/framework. I think that ability to adapt to change quickly is the single most important skill that I acquired during my time as a consultant.
This is not to say that the transition was instant or painless; I’m still trying to figure out how best fit in as part of the team. I think I have rocked the boat a lot and going forward I need to do a better job of picking the right battles to fight. I think the most challenging part for me has been the fact that not everyone that is working on our software in-house is a developer by profession. It can be hard to communicate why doing something a certain way may not be a good idea from a software perspective when we don’t share the same background. It’s also important to have scientists on the team, since we are writing software for them to use. The concerns of the scientists writing software are different from my concerns from writing software, and I think there are things to be learned from both perspectives. The challenge going forward is going to be striking the right balance between the software as a construct, and it’s ability to easily meet the needs of the scientists.
So far it’s been a great learning experience that is making me reconsider why I do things the way I do (and if there is a real reason why I’m doing something in a particular way). The act of articulating the reasons behind an idea/process/philosophy make you think long and hard about whether or not it is truly worthwhile. It follows then that I must continue to work towards improving my communication skills in articulating not just what may be problematic in our software, but why.
It’s also been interesting to see the types of decisions that non-software (as a career) people make when writing code. Seeing how other individuals conceptualize solutions to problems, and how they go about implementing their solutions. I see a lot of similar mistakes that I would have made a couple years ago when first starting to write actual applications. I also see a lot of solutions to things that I never would have considered (for better and for worse). I think part of the problem with writing what one may call “good” code is that so much of it comes from experience; there is only so much you can learn from reading or being told things. It’s hard to appreciate why X is a terrible idea until you write something that uses X and then have to dig yourself out of an incredibly deep hole 3 months later.
I think that as a result of having such a diverse group of people coming from such a variety of backgrounds, that we suffer from the XY problem quite heavily (whereby one asks how to accomplish their solution Y, when they are really trying to solve X). Being an intelligent group of people, we all like to try and come up with our own solutions to the problems we face before we go and seek help. The issues that then tend to arise are twofold: awareness and communication of intent. A common problem within any appreciably complex discipline when solving problems is a simple awareness of the larger problem space and the tools/techniques available to solve your problems. This comes up a lot in software when someone may ask “how do I remove the last 3 characters from a string,” what they really mean is “how do I get the file extension from a filename”. This often leads us down the road of asking the wrong questions and arriving at an inferior solution due to a lack of context. This is why I rarely answer a question directly but try and inquire at least a little into what the person is actually trying to accomplish.
I don’t think people truly appreciate how much about software development boils down to effective communication between human beings. Whether it be communicating through your code, in a design meeting, or a conversation with a customer. Software development is communication, and a software project either crumbles or thrives because of it.
2014 is going to be an exciting year. Lot’s of exciting problems to tackle at Emerald, and I look forward to working with everyone to build a great team and some great software (in that order).