Hi I'm Fiona and I am a Software Engineer at KrakenFlex.
It's hard to sum up what a Software Engineer does, because there’s so many different parts to it, but it mostly revolves around writing code. I work on a team officially known as Gateways but internally known as The Mighty Geese (I'm not going to lie, we have a lot of geese emojis flying about in our chat channels ).
We are responsible for bringing on new integrations, which basically means that when a new company joins up - this could be a battery site, or an electric vehicle company - we design the architecture and write the code that connects to them. We do this so that we can, in the case of an electric vehicle, keep an eye on the amount of charge in a car and charge it at a time that is good for both the customer and the National Grid. The Funky Gibbons, another dev team we work with a lot, do data analysis on the information we get from the car to decide when to charge the car, and then we send the message along when it is time to charge. It may sound quite simple, but we have over a thousand cars from different companies and we are constantly adding more infrastructure to handle new types of cars or chargers - so there is a lot going on! We have some heat pumps in the process of coming online too.
We call the platform that handles all of our domestic assets the Cloud-to-Cloud platform and it sits on AWS. It is written mostly in Typescript although we do have some Python as well. These are the two languages in most common use across the company. However, our team is special in that we also write in Java sometimes. For commercial sites (think solar, wind or battery farms) we have a little computer that gets installed on site by our electrical engineers that can connect to our cloud so we can talk to the sites and control them like we do an electric vehicle, and the code on these is written in Java.
So without further ado let’s get down to what today has been like:
9:00am
After my morning routine of coffee, getting ready and walking my daughter to school, I start work from my home office at 9am. I spend my first 15 mins checking emails, Slack and my calendar as well as eating my breakfast. I’m basically getting ready for the day and reminding myself what I'll be working on.
9:15am
I go to my team's stand-up. We have a Kanban-style board where we have tickets describing all the different work items we are currently looking at. We move them across the board as the work gets done: from TO DO to ANALYSIS to IN PROGRESS to SOAKING - this usually means we have it on our Development Environment (Dev) in AWS and have set up an end-to-end test that we can monitor and keep an eye out for errors/alarms - and finally to DONE when it is pushed to our Production Environment (Prod) and we are happy it is good enough for customers to use.
Back to stand-up, I explain to the wider team where we are - we have written the code that connects to the solar farms cloud and gets data back and it is in Dev. We have tested it by manually running the Lambda with different inputs to see how it behaves in a range of different situations. This means thinking through how it should behave when it works, but also what could possibly go wrong and making sure it fails in a way that is safe, and informative. We want to easily see what went wrong and hopefully fix it quickly. I tell everyone that next we will be working on some code that automatically checks what data we need when, and if it's time to get updated information it should automatically kick off the Lambda with the correct inputs. After answering a few questions from my manager, and listening to how the other projects are going, we all head off to start working.
9:30am
It's time to get stuck in so I Zoom call the teammate I am pairing with at the moment, Henry. Pairing means we code together, one person typing, one person guiding. It works really well because the typist has someone to proofread, we can continually talk about the best way of doing things, and we can share our knowledge so the work can get done faster and to a higher standard. I find it more fun pairing than working on my own, but also more intense and tiring, so it's nice to have a combination. We check the ticket on our board that we created together a few days ago. This is to make sure we are clear on the requirements of the work, the steps we plan to do it in, and the Acceptance Criteria - the things that need to be true before we can say that task is done. We are going to need a Dynamo Database for this new Lambda, but it's going to need a specific structure, one that none of the tables either of us have worked on have had. We decide that before we start looking into the new code, we want to individually go off and play with creating Dynamo tables for half an hour as well as reading up on AWS’s documentation on how Dynamo works so we can have a better idea of how to structure the table. We Slack each other when we discover anything useful.
10:15am
We come back together and I show Henry what I have come up with. He came up with a similar thing with a few extra tweaks I hadn't thought of which would be really useful. With that decided we pair up to write the code. First we go to Github and download a cookie-cutter Lambda that we all maintain to spin up the new Lambda our code is going in. It's super useful as it means the pipeline in AWS gets automatically set up with all the correct settings and the project structure is all done automatically. This saves a lot of time and also means that all the Lambdas we use have the same format making them easier to understand and maintain.
Once that's all done we push the new project to Github on a new branch and create a pull request for others in our team to check. A pull request is where we put new code that is going to go into the product. Then one or more of the rest of the team can look into it and check for mistakes or give us ideas of better ways of doing things. Once we've made the changes needed, someone approves the pull request and we can push the code to the master branch. It then becomes part of the code base and automatically updates the Dev. It may seem strange to merge code before we've even started writing anything, but we have a 'little and often' policy with pull requests so if we break something it is clear which bit caused the problem. If we started writing code and something broke it would be unclear if it was something wrong with our code or if it was a problem with the lambda setup.
We then start writing the code. Our Lambda had two basic things it needs to do:
Find out if we need more data from the site.
Kick off the telemetry lambda with the correct inputs.
So we handle and test them one at a time. We first get information from the DynamoDB table, like when we last asked for a particular bit of information, which the Lambda then uses to decide if it's time to get more data. We write unit tests for this at the same time as writing the code, again coming up with all the different possibilities where the code could fail as well as checking that when it doesn't fail it does what’s expected. Unit tests test isolated sections of the code, which is very useful for catching bugs before the code has been pushed anywhere. It involves a lot of mocking, pretending to call other bits of code without actually doing it. It means if the test fails it means the problem is isolated to that bit of code. However, often I also want to know how it interacts with other things. In our case, we aren't always sure of the exact format of the response we will get back from DynamoDB, so we also write some integration tests where we actually talk to the DynamoDB table in Dev, to confirm that. We carry on with this together, taking short breaks when needed.
12:30pm
I go for an hour lunch. I have a quick sandwich and salad with my husband and then we head out to the local parkland to walk Sophie - our dog. She's been lying next to me, and more importantly, my radiator all morning and as soon as I get up out of my seat for lunch she is ready for some attention and a walk.
1:30pm
I am back at my desk and checking Electric Vehicle alarms. These are AWS alarms that came in over lunch saying we are failing to connect with a couple of different Teslas. I look into AWS logs to see why and it turns out one of them has a server error that looks like it can be solved easily with a software reboot, but this needs to be done by the customer. I contact the support team to talk to the customer so we can get the car back into a state where we can charge it properly. The second one looks like a temporary connection problem and having a look at the graphs we have I can see we are now getting data again and the car charged correctly overnight, so there was nothing to do there. Another team who are in charge of the front end are looking to automate this process so we won't have to do manual monitoring of vehicle issues anymore, but in the meantime we keep an eye on them. We are always monitoring anyway in case our system fails.
At about 2:00pm Henry and I carry on with our pairing and finish off our code for the lambda. We get interrupted by my daughter getting back from school, bursting into the room and then running out again when she realises my colleague can hear and see her!
3:45pm
Once the lambda is up and running in Dev we populate the DynamoDB table and check the logs to see if it is working as expected. This is end-to-end/soak testing and it tests that the whole system works correctly. But it isn't! It's frustrating when this happens, but really common and it doesn't take long looking into the logs to figure out what went wrong. The format of a timestamp was subtly different between one lambda and the other. Henry does a quick fix and I approve it. We check again and this time it is working! Just in time because it is now 4:15.
4:15pm
Today is Friday and on Friday we have Family Dinner. Family Dinner is where the whole of Octopus comes together to look back over stand out events of the past week. I often enjoy these meetings as they are usually swift and high level, funny and inspiring. They are always focussed on how we can better help the environment and our customers.
Nobody at KrakenFlex is presenting one today, but my manager does sometimes present what we've been working on, usually with some cat pictures thrown in. After a long and busy week it's nice to stop work and be reminded of why we do what we do, that I am a part of something bigger and we are all working together towards a common goal. I also find it a nice buffer where I can start to wind down before the weekend. Just a couple of hours now in a gymnastics studio with my daughter and the weekend truly begins!
Of course my job involves a lot more than just the things I happened to work on today.
One of my favourite parts of the job is that you are constantly given new challenges, a different type of integration, a different language, a new technology, so I don't ever feel like I'm doing the same thing over and over again. I could be creating graphs, designing architecture, working with other teams, from within KrakenFlex or from the wider Octopus tech companies. I could be helping another teammate or getting help from them. I could also be spending a whole day fighting with my laptop because it's not working properly! I then will find out it's because one module I installed is not the right version, or something was indented slightly too much in my Cloud Formation (an AWS thing) file. That is my least favourite part of the job! I didn't grow up scripting and messing around with the innards of computers so it's not my strength, but that’s the great thing about being part of a team. There are a couple of experts and as I pair with them I get better at it.
My most exciting day at the company so far was going down to Slough on a site visit and wearing steel toe capped boots and a high vis jacket as I did some manual tests on a heat pump. It was a nice change from sitting down all day and gave me a whole different perspective on that particular project.
My advice for anyone looking to get into Software Engineering
If you like problem solving and continually learning then I'd recommend considering a career in Software. A degree in Software Engineering is very useful and well worth doing if you can, but if it's not possible for you, don't feel you have missed out. I used to be a teacher and lived with a group of Software Developers while I was training, which is how I got the coding bug. I did a range of courses on and off over a few years and that's how I learned.
If you are a complete beginner I found CodeAcademy to have some really good hands-on courses, and I would recommend Python as a first language to try. It is easier to pick up than a lot of other languages, but that doesn't mean it's not powerful. Developers and Data Scientists alike use Python throughout the industry and there are loads of companies looking for Python developers, so it's not just a learner language.
If you want something a bit more advanced, or want a more university-like approach I found OSSU really high quality. OSSU stands for Open Source Society University. It's on Github (https://github.com/ossu/computer-science). They have gathered together free online courses from a range of different universities that are roughly equivalent to a computer science degree. You can pay to get your assignments marked and get an official certificate at the end, but you don't have to. My favourite course was ‘Nand to Tetris’ (https://www.coursera.org/learn/build-a-computer) where you build a computer from scratch (not physically, but the software). This gives a great understanding of how a computer works. I also found ‘Software Engineering: Introduction’ a really good course on how Software Engineering works in a business https://www.edx.org/course/software-engineering-introduction. It’s a lot more than just coding! If you want a challenge and have big chunks of time to spend on assignments, CS50 (https://www.edx.org/course/introduction-computer-science-harvardx-cs50x#!) I found it really tough, but very thorough, and my coding and understanding of writing software improved loads doing it. Of course you don’t have to do all the courses they have listed, pick and choose what’s most useful to you. I did three of them before getting a job and a couple after, as I felt I needed to.
When you get to the stage where you are applying for jobs, don't forget that they are interviewing you, but you are also interviewing them. You don't want to get the job to find out that it's not a nice place to work. I found my first job, although good, a bit isolating. People tended to do their own work and struggled sometimes with communication as well as remembering what it was like to be a beginner. I think I found this particularly hard coming from teaching which is a very social job, to working on my own day in day out. I would look out for a place that is used to taking on graduates/juniors, or that is at least aware of what it takes to train up someone new and is willing to spend the time teaching you the ropes. Personally, I have found places with people from a range of backgrounds tend to be better places to work because it means they are used to taking on, supporting and learning from people with different perspectives and points of view. This includes age, gender, ethnicity, academic/work background, experience and loads more I am sure. This has the added benefit that the products tend to be better because when designing and implementing something we can come at it from different angles and fill in each other's gaps to get a more robust product.
Being a Software Engineer can be stressful at times, but I still find it a thrill when things I write fix a customer's charging problem or saves them real money. Also, things I write help to reduce the need for fossil fuels across our electricity network. Of course it's not just me; it's me, my team, the other teams in the company and all the other companies and teams across the UK and the world that are doing real, practical things to help clean up our world. It's great to be a small but important part of it all.
Comments