Can you guess what a software developer does? You’ll probably refer to its stereotype, a guy sitting in front of a screen for most of the day. Although not far from the truth at the surface, there is much more to it than that! Each day is a new adventure from finding a solution to an elusive problem to creating a new feature for a customer.
Many graduates relocate to a different state, move closer to work, or get used to the long travel times. I’m the latter. It could be worse, I’ve become accustomed to it after travelling longer distances during my university days.
Before I started as a graduate, I had the impression that every problem was already solved, and I was the only one trawling through Stack Overflow (for those who don’t know, this is the place to go for programming answers). This is far from the truth and every day there are new problems to solve, more code to write and lots to learn!
My typical day is normally 8.00 am - 5.00 pm which can vary on whether deadlines are approaching or communication with teams across time zones. Remember, Honeywell is a global company. So, I get up just before 6am, take two trains and walk a short distance to the office; during which I normally drown out the noise of the train and its passengers with music and try to stay awake as I code on my laptop.
Here at Honeywell we use scrum, an environment which promotes collaboration, efficiency and communication to shorten lead time – from when a customer wants something to a completed software feature. This includes several rituals (meetings) which can vary from daily (stand-up), weekly (grooming) and bi-weekly (planning, reviews and retrospectives). Every 2 weeks is considered a sprint (which may vary between different teams, in the same or different organizations), a cycle of iterative software development where the team commits to completing a set of tasks (stories). It was confusing at first, but it works.
It's not always the idyllic world where we write code and it works the first time. Even the most experienced developers struggle to create the perfect solution the first time; it takes time, creativity, a good understanding of design patterns and debugging. Debugging - now there is a word which summarises some of my days. The ability to debug efficiently is an excellent tool in your arsenal which can save you pain-staking hours of looking through the code for the one line fix. Yes, you heard right, many a time the root cause is a missing word, missing line or syntax error. In the end, persistence, and a fresh point of reference can be your greatest weapons in the fight to find those software bugs.
So, one day, I was attempting to get an integration test to pass. Of course, I didn’t write the test myself. Do you believe me? On a tangent, an integration test is where you write a bit of code to execute in isolation, under controlled conditions, to interrogate the software feature like an end user would – to provide a high level of confidence that, yes, this feature is working. Production code is easy to write, but it’s the integration and unit testing that consumes all your day. Is it necessary? Of course, it is! Without them, how would you be able to confident that the software you have written is working effectively. When you have a well written program, with unit tests backing it up, like an emperor and his expansive army, any war can be won. Are you still interested in software development? You should be! It is often gratifying to deliver a feature, that you know works, into a customer’s hands, or even fixing an extremely annoying bug that is starting to invade your sleep.
Back to the earlier scenario – I was testing a feature where I was updating a variable in a database through REST calls (the internet is built upon it), but there were several layers to pass through, guarded by error handling. After several hours, I noted to myself that the test should be passing, and the code was doing what it was supposed to. Since, there were several lays of various calls, it was quite challenging to debug. We were running integration tests through Docker containers (isolated virtualised environment that run atop the OS) and it was calling multiple containers along it’s logic. Interested in what I’m talking about? Have a look at microservice architecture. Looking at the exception thrown wasn’t very useful, just a blur of characters pointing to any number of problems. What I did was try to isolate where the problem was happening by analysing the flow of data through functions and asking a bunch of questions to myself. Is what gets passed in expected? Is this call working? Is it returning the correct object? Then looking at one log line that I had written yielded the answer. Light bulb! It was quite obscure, the reason why it wasn’t working was buried deep under several levels of abstraction, in the last place I would ever look. Basically, I setup my test to insert some specific data in elastic (third party no-sql solution) but a helper class was injecting some hardcoded value to make the code look in a different index (like a database table) which wasn’t created! In the end, it was a simple ten character change but it literally took hours to solve!
And as you get a grasp on the product you can become somewhat of an expert. Anyone new joining the team can lean on you for knowledge sharing like confirming the meaning of a specific error code – it’s because you did the hard yards and have already solved it! Always some portion of the day is satisfying these requests, talking about ideas and the best way to solve the problem at hand. Also, peer programming is common – two minds as one – it rapidly improves your programming skills, especially pairing with a top-notch developer (there are plenty at Honeywell). I did mention that we are collaborative.
It’s also very typical that I will look at code reviews (pull-requests) from a few minutes to a few hours per day. It’s part of the process of effectively managing changes to a project where multiple developers are working in parallel. Git is probably the best version control system – any changes to the code base can be created on a feature branch, and then merged back into the mainline. It’s this merging process where peers can review the delta changes, make comments and suggestions. Just by participating in code reviews, you get to view other developers coding style, design patterns, bad practices and habits (everyone has them!).
Other activities can fill the rest of the day like sharing ideas within meetings, skype conversations, replying to email threads, creating Gliffy diagrams, looking at build logs and the list goes on. Don’t forget writing code – that’s the most important bit!
At 5.00 pm or so, I take the long train trip home, again packed with people, listening to music, coding furiously on my laptop and looking forward to the next day where I can hopefully learn something new! Well, there it is, my typical day! Hopefully you are still reading and didn’t find this boring. Creative writing may not be my strong suit but I know coding is. Most definitely yes. All the suffering in the last 7 years at university was all worth it! At Honeywell, there is never a dull moment (well almost never) and you will always be learning something new and interesting. It’s always fulfilling to see that even as a graduate with limited experience, you can greatly contribute and improve as a software developer.