I am a girl who’s into Eminem, the sound that leaves make when they move in the wind, airplane food and faking my identity at Starbucks. When I’m not at Bulb coding away, I like to doodle, hacky sack and write.
At Bulb, I work on the BEST Pod. BEST is an acronym that stands for Bulb Energy Specialist Technology. Our job is to help our Energy Specialists (the people you talk to via phone, email or online chat) to work as quickly, efficiently and happily as possible. To hear more about the kinds of work my team does, check out my fellow team member, Spyri’s, post.
Being a software engineer is an exciting job because I have the opportunity to turn my team’s ideas and insights into reality.
The researcher, designer and product manager on my team will take a problem and cook up a solution for it.
The solution will be a new feature: a brand new piece of code that allows a web page or application do something that it previously couldn’t do. An example of this would be a form like our smart meter trial list, or a new button that allows our Energy Specialists to access your meter readings quicker and more efficiently.
An idea usually takes several iterations of testing and design until I come into play. Once the problem is my hands, here’s what I get up to:
Planning a solution:
It’s my job to come up with a technical plan for how this solution will look in code.
Often, technical planning starts with some thinking and drawing up a proposed solution with pen and paper. This always helps me get my ideas straight.
If the task is small or obvious, I come up with the solution by myself. If the task requires writing a lot of code or it seems tricky, I often chat with the other software engineers on my team. It’s good to work things out together because the code that I write will have to be built upon later. It needs to be easy to understand!
Next, I start looking into code we’ve already written that will help me solve the problem. It also helps to understand where in the code I will put the new feature.
Building the solution:
Code can look complicated. But at it’s best, code is readable and easy to understand. Writing code can be really relaxing and, oftentimes, so absorbing that the hours of my day fly by.
When writing new code I need to be in constant communication with my team:
- Product manager and researchers check that what I’ve built meets the feature requirements
- Designers make sure that the look and feel of the new feature matches their design
- QAs (quality assurance) testers check that it all works properly (find out more about that from PJ, in his post on being a QA at Bulb)
- Software engineers review and understand the code that I’ve written. They’ll give me feedback on where I could’ve written something better and try to find possible reasons why the code might not work in the way that’s expected.
Deploying the feature:
Once my code has been reviewed and approved by my teammates, we deploy it to production. This puts it straight into the hands of our Energy Specialists, the people who will be using it every day.
Deploying a new feature is my favourite part of the job: it feels great to announce a feature that will make a big change to Energy Specialist’s lives. These changes always mean better, faster service for our members.
Sometimes, all the feedback we receive will be positive. If that’s the case, we’ll get to work on the next set of new features. Other times, the feature we’ve released doesn’t quite work in the way we expected (ie, there are bugs). This means we need to make changes. Either way, feedback from Energy Specialists is essential because it allows us to quickly release and iterate on new features.
Let me know if you have any question about being a software developer at Bulb. =) :3