In the past few months, I had more opportunities to talk with family and friends in person. Throughout our conversations, one interesting, yet simple question always came up: “What do you do at work? What does you company actually do?”. Well, maybe it’s two, but kind of go hand in hand. For those also in the technology sector, I can simply say “we’re a computer networking company, and we build network switches and the software to make them work, along with network management software to complement them”. But when I’m talking those outside the industry, like my parents, how should I explain it? My goal is to hopefully reference this post when I talk to others about the work I do.
I am a software engineer at a computer networking company. We find interesting solutions to networking problems, implement in software, write automated tests to verify the expected behaviour, and triage issues with said software that are reported by our 24/7 automated testing labs, test engineers, or a customer. Computer networking involves devices known as switches, which contain interfaces that connect to end devices, such as another switch or a computer, via a cable. They are physically part of the internet backbone: without them, we would not be able to send messages to others, have video calls, or play online video games.
Similar to at least one networking textbook I’ve read so far, I like to draw an analogy to our real life postal service. For the purpose of this post, I will treat switch and router to be the same, even though they are slightly different. The widely-used protocol that computers use to communicate with each other is the Internet Protocol (IP). Computers communicate using packets, analogous to how someone would send a package to somebody else. Packets have a destination (IP) address with a source (IP) address, which is like an envelope with a “to” and “from” address. They are sent to a network switch, which decides where the packet needs to go in order to reach its destination, analogous to a post office accepting packages and sending it to the next place. The process repeats: packets travel to other connected network switches, then they get forwarded on other links to other switches until it finally reaches the destination IP address. This is similar to the “in transit” notifications of a postal package, which, depending on the destination, may travel to a local distribution centre, an international airport hub, another local distribution centre, and finally to a local postal office for final delivery. Network switches are the equivalent of a post office or mail distribution hubs, while the cables that connect them together are like highways or planes that travel between the hubs.
Unlike a person, computers send an enormous amount of packets (also known as traffic) every second. Network switches need to handle that traffic and make decisions on them, such as which interface to forward packets through, in the order of nanoseconds or even faster. This is made possible by programming application-specific integrated circuits (ASICs) correctly. These switching ASICs can be developed in-house or bought from a chip vendor (otherwise known as merchant silicon). I am fortunate to be part of a team at my company that programs a specific family of merchant silicon to do the right things.
Our team has groups of developers working on a plethora of features used by our customers. I work on a feature that deals with a well known industry standard timing protocol. High accuracy time is a requirement in media & entertainment networks, and also in high frequency trading environments. My job is to enable this protocol to work on a plethora of switch models, which requires an understanding of how the ASIC in a particular model is programmed. I read through documentation to find interesting things I should program, experiment with them, and verify its behaviour on an actual switch. Once the hardware is working, we run a suite of tests against the switch to verify the protocol behaviour, address any failures, and ultimately enable the functionality for the end customers to use.
While I would like to have no issues with the code we write, bugs will inevitably exist. When our customers run into issues and our dedicated support team suspects a software bug, the issue gets escalated to the software team, where developers, such as myself, dig in to root cause. As such, I also handle customer issues related to this timing protocol, which may involve sifting through logs, recreating a lab setup with switches to reproduce the issue, jumping on a call with the customer at weird times, and fixing any issues found in our software (along with an accompanied test to verify that it fails without the fix and passes with the fix). I used to think that customers were scary people, but through these last few years, it’s taught me the opposite. Customers are people like me: we want things to work, and when things aren’t working, we have to ask the right people to figure it out, give enough information for the other party, and fix the issue. Knowing that “someone” on the other side is there to help me is a huge relief, and being able to be that “someone” for a customer feels like a privilege to be apart of, even if it gets stressful at times.
I guess that about sums up what I do at work. It gets stressful at times, but I think it’s a healthy amount of stress that doesn’t involve me dreading to wake up for work, but rather excited to work on projects that make a positive impact on actual customers.
Anyways, that’s all I got this time around. I have a few other non-work things I still want to write about, so hopefully I will get to them some time next week or the week after.
Until next time!
~Lui
