And with a blink of an eye, it’s been more than two and a half years since I started my full time job. As I’ve probably alluded to many times in my past posts, I’ve personally had a bunch of ups and downs while I’ve been working at this computer networking company. Contrastly, I know one of my friends has been jumping around from job to job and getting better pay; however, there’s just something about my company and those in my team that prompt me to stay and grow organically in one place. At least this is how I’ve been feeling up to now.
Anyways, in this post, I figured I would just have a thoughtdump of some things that have been on the top of my mind regarding work for the last little while (been chipping away at this since March), so without further ado, here I go.
Quality is a core value at our company. Decisions at any point are made with this in mind. A question like “Is this feature ready to be shipped?” can be answered by looking at our automated testing results, and “There’s been an escape, how should we fix it?” should definitely involve adding a test case that would fail without the fix and pass with the fix. It feels great to be working in such an environment because rash decisions to ship known, catastrophic, buggy code is thrown out the window. That doesn’t mean we ship code with no bugs, but we ship knowing how a bug could potentially affect a customer, and also that can be addressed in a future code release.
I have worked on a feature that got delayed for several releases because it wasn’t ready. Sure, being delayed sucks, but as our CTO would say, “apologizing for delaying a feature is much better than apologizing for burning down someone’s network, because networks are just that important” (or words to that extent). That is a sentiment worth following, and as time has progressed, I have also been making personal improvements in approaching problems by thinking about the testing aspect. I still have a long ways to go on this front.
Another aspect of our core culture is valuing team success over individual success. Part of everyone’s job is to “leave your door open” to others: anyone can come up to you and ask you questions and there should be no barrier for that. In today’s WFM/hybrid work era, that means being responsive on Google Chat when someone comes to me with questions, or being freely interrupted during the day in the office. This goes both ways, so I can do the same thing: just ping my coworkers online or walk up to their desk and ask if I get stuck on something. The last point there is something that I find takes some time getting used to.
The people you work with determine whether you’ll want to stay at the company. That’s cause when you’re stuck on something, you’ll want to interact with the rest of your team. In my opinion, these types of inter-personal working relationships can make or break a job. It is for this exact reason that I continue to stay at my current job. I can safely ask questions and not feel alienated by their interactions. Part of this is also due to our company culture of doing the right thing and team success rather than individual success.
Likewise, my own interactions with others determine whether your close coworkers stay at the company. I might have mentioned this before, but there is some sort of self-pride helping out others. It helps to boost morale when you’re feeling a bit down while stuck tackling your own problems. Then, when you go back to your problems, you have a little bit of a fresher mind to try and tackle it again.
Also, by building better inter-personal relationships, it makes it easier to ask questions. In one of my teams, we have a group chat with zero barriers to talk about random life/day-to-day things as well to ask “stupid questions”. I’ve asked my fair share of dumb questions, and sometimes you just gotta ask them to get a move on with your tasks.
Documentation is a fundamental piece to any company. It’s how engineers can explain the rationale behind why a given approach was taken for a problem, or transfer knowledge of internal systems or workflows to others. Unfortunately, when priorities change, documentation becomes an afterthought, and often is forgotten about. To nobody’s surprise, this also exists at my company, and I think it could be improved upon.
At my company, I am on the platform team. The easiest way to describe our team is that we take merchant silicon ASICs and program them to do things to incoming and outgoing packets. The chip vendor provides us with reference guides for the ASIC registers, along with additional documentation that is irrelevant to this discussion (NDAs are important). We do some optimizations in house that are pretty cool and we document their designs. So far so good.
If you’re someone starting off new in this area, the ramp up difficulty is hard. You’ll quickly dive into the documentation, only to find out that it’s like you’re jumping into a messy library room: documents are all over the place, the introduction guide is half-written, and you find out things by word of mouth. Do you need to know how to debug something on the chip? There’s a debug manual that someone started a while back, but that someone’s no longer with the company, so nobody’s maintaining it anymore. What do you do? You have to ask around once again.
Personally, I like to have things at my fingertips. I enjoy reading and follow guides and whatnot. I want to understand how something work. I’m not a huge fan of having to ask people on how to do things: that’s a personality trait of mine that I’m working hard to address, but it certainly doesn’t happen overnight. When push comes to shove, I will ask for help, but when given a problem statement and it results in me not being able to easily find the documents I need to get the job done, then it begins to irritate me a bit.
With that said, I am trying to fix this in a few ways. First, the sentiments above were something I’ve told my manager during our one-on-ones and during my performance reviews. If we, as an organization, want to improve, then having upper management aware and encourage better documentation (which usually comes down to allotting time and recognizing that it’s important) will definitely help drive change. It’s similar to the way our company values quality, and the time it takes to build quality software.
Another thing I’ve done is sharing a document with all of my tips and tricks. Everyone’s way of onboarding is slightly different, and everyone usually has their own list of commands they keep to themselves. I wanted to share my sheet because it’s also beneficial for me in a few ways. First, it forces me to stay organized. In order for me to help others, I first need to keep things tidy and searchable, and it doesn’t work if I just litter commands in a document in no particular order and without explanations. Second, I get the nice side effect of having others point out suggestions to me. Perhaps something’s changed, and the workflow is slightly different. Because it’s a Google Doc, they can make suggestions and comment dirrectly on the document, and I can adjust it. Helps me, helps the instigator, and it helps everyone else that comes along to read it later.
The Actual Work
And finally we’re at the core of it all: the actual work. At the end of the day, if the work sucks, then why bother torturing yourself for 8 hours a day, 5 days a week doing it? That’s not to say I haven’t had times where I re-evaluated myself and what I wanted to do. As a software developer, I write code to solve problems. The problems are pretty interesting, and I’m starting to get a little bit more experience writing up design documents, understanding our system architecture a bit more, and reviewing other people’s code. With my great colleagues and work culture, I feel like I still have plenty of opportunities to grow internally, so unless something major happens, I don’t anticipate voluntarily leaving any time soon. Hurray!
Anyways, that’s really all I wanted to talk about in this post. I’m currently out this weekend for an anime convention in Vancouver, so it’s time to rest up!
Until next time!