I like the teamwork of a corporate environment, and I would not have guessed that about myself before I got into this industry. I was never that kind of guy. As a young person, I rarely participated in any kind of team activity. I’m sure this is no surprise to anyone who has met me, but just for emphasis I’ll say it: I was never on the football team or any other sports team. The only “sport” I ever enjoyed, loosely defined, is swimming—which I did alone.
Before I started working as a software developer, I did not even totally understand what people meant by “teamwork”. It sounded like one of those buzzwords people ask you about during interviews, and to answer that people just say something meaningless that sounds like they work well with others. They’re just trying to gauge whether you seem like a total asshole, right?
But now I get it, and I think what I’m writing here might really be useful to anyone pursuing a career as a software developer if you think the job means sitting in front of a computer writing code all day. It can mean that. I think some people have carved out a career for themselves like that, but the job doesn’t have to be like that and for most developers it is nothing like that.
I’d rather be concrete and specific instead of talking in abstractions, so I will tell you a little about myself and my work situation. I’m going to use fake names for other people though just because they might not like being specifically mentioned in my blog. Even so, I have only positive things to say about them.
At work, I am on a team we call “BFS”—Business Flow Service. Nobody ever says entire phrases. Everything is an acronym. Our team’s project is a sort of middle-man that helps in the process of delivering insurance quotes to people in real time. We expose an endpoint for the frontend to send quote requests, and we collect all of the relevant information, and we process various business rules. We call a lot of internal and external services to accomplish that. The main thing BFS does is coordination and translating between all of the other services. We do not actually compute quotes. We gather the information from a lot of different sources, and we pass it into a different service that computes the rates. That service is called SRE—Single Rating Engine.
BFS is my team. I keep abreast of what they are doing some of the time in case I need to tag in on something. We have some engineers who are more senior than I am, and some who are just getting started. My teammates are the first people I go to if I need help understanding a business requirement, or even if I need help with engineering stuff because my code isn’t working or I need fresh ideas. However, I don’t always keep up with everything they are doing. Part of the beauty of working on a team is that I don’t have to know everything they are doing. I trust my teammates to do good work. So this may seem counter-intuitive, but most of the time I don’t work with my teammates. I work in parallel with them on separate tasks.
The “teamwork” I’m talking about in our corporate culture is larger than just my team, the BFS team. Our project directly interacts with maybe a dozen other services, and also the frontend, which is an Angular app. So a lot of my job requires interaction with the teams that own those other services. Often, the people on those other teams are the people I actually work with, because we have to work together to make sure our projects are integrated correctly.
We have to work with the frontend app a lot because we directly serve the frontend. All of the other backend services are hidden behind BFS. We are the interface. The frontend is called AgentQuote, and it is a team of several very skilled engineers, but I don’t know all of them. I know a few of them, and basically to me those people are AgentQuote. I know the AgentQuote team lead of course, and really if I have random question or something I should go through her. But also I know the most senior engineer on the server side of that project—Barry. From my point of view Barry is AQ. I work further back on the backend, so I usually don’t care at all about the client-side frontend. The JavaScript stuff is irrelevant to me. From where I’m sitting, if I look in the direction of AQ, what I see is the server-side project that hosts AQ and communicates with BFS. And if I need to speak directly with an engineer who knows that stuff really well, then Barry is my man. So I’ll just ping Barry.
Sometimes I have to work even more tightly with Barry because we have to agree on the best way to pass data from BFS into AQ or vice versa. So I might draft a format and deploy that to test, and then Barry would integrate that into his systems, and we’d work together to make sure the systems were properly integrated.
The BFS team also works hand-in-hand with the Single Rating Engine team, SRE. That team also has several very skilled engineers. And of course I know the team lead Mary, but she is a very, very busy woman. So…maybe I shouldn’t bother individual engineers with my random SRE questions, but we do that all the time. I know some of the people on SRE, and to me those people are SRE. My main contact person in this case is Kelly. She’s a senior developer who has been here forever. She’s also friendly, and she and I worked together on California. That is: while the company was rolling out a major release of California-specific code, I was working on the BFS side of things for California, and she was working on the SRE side. California represents about half our business or more.
An important thing to keep in mind here is that these other projects, like SRE, have gigantic code bases, and I absolutely do not know the code over there. It would be totally impractical and inefficient for me to dive into the code myself if I had questions about how something worked. Becoming familiar with the code in my own team took about 5 months, and there is still stuff to learn. I’d say it took 5 months just to become familiar enough with it so that I can act as a subject matter expert (SME) representing BFS to other teams, but that doesn’t mean I know everything in our code base. It’s a huge project.
Learning the SRE code would be a fool’s errand that nobody is paying me for, and it would not help me do my job. Plus: there are like a dozen other projects we interact with. There’s no way I could possibly familiarize myself with all of that—not even the software directly tied to our BFS project.
That is one of the reasons why these relationships with people on other teams are so important, and when I speak about “teamwork” in our corporate environment, I mean all of us working together—not just me working on my BFS team with other BFS engineers. I mean working together with the engineers who represent all of those other teams we work with. And not just other engineers, but also people who represent Product, and our project managers.
I really enjoy this aspect of the job. I enjoy opportunities to work with Barry and Kelly and the other engineers I know who represent the other teams. They are skilled professionals, and I learn from them, and also I enjoy their company when we have a reason to work together.
In a similar way, I think to several people in other teams I represent BFS. Our team’s best SME was elevated into management, and now she is the BFS team lead. Basically, she is BFS, but her time is very scarce. And the more time she spends managing and attending meetings, the further she gets from a direct understanding of the code base. So I have become one of our SMEs. Specifically I’m mostly a BFS California SME. We have another member on the team who knows the Texas, Arizona, and Georgia stuff better than I do. I enjoy the respect afforded to me as a representative of the BFS team. When people need to know something about BFS, they often come to me. Not just any job offers that feeling of respect.
What I’m getting at overall is that corporate software development is very much about people. And not just in a meaningless, feel-good sense. I’m not in HR. I don’t say meaningless bullshit. I mean that my interface for interacting with the SRE team and its code is Kelly or maybe her team lead Mary. Yes, it is a software project, but I don’t touch their code. If I need something from SRE, I talk to the people. For me, those engineers are the project. And it helps very much to actually know those engineers as people. I don’t need to know details about their personal lives, but having a friendly acquaintanceship with Kelly is much more useful to me than trying to learn their code. It’s also just more pleasant.
adamcross.blog 