Software Developer Life

Home > Other > Software Developer Life > Page 12
Software Developer Life Page 12

by David Xiang


  While job hunting, it’s convenient to turn a blind eye to the small quirks. You might be desperate, you might be putting your perfect company on a pedestal, or you might be prematurely honeymooning after a hard sell. Stay vigilant at all times. Patiently and objectively think about every interaction and every detail—obvious red flags might be staring you in the face.

  Pay attention to your immediate feelings—especially the negative ones—and you will guard yourself from unfortunate circumstances and stress.

  Listen to Your Gut

  When it comes to job hunting, channel the stereotypical TV detective and listen to your gut. Your gut will know when you fit into the company culture. It will know how much integrity the CEO has while selling you the dream. It will know when your interviewer doesn’t really like their job, even though they’re trying to hide it. Pay attention to your immediate feelings—especially the negative ones—and you will guard yourself from unfortunate circumstances and stress. Career decisions are important decisions; your working life depends on them.

  27: Setting Expectations Clearly [Stories]

  Jessica and I had met and become friends at a budding startup. We were a consumer-focused startup with the lofty goal of building a next-generation web browsing experience on mobile. We liked native applications. We didn’t like cramped, under-optimized webpages where we had to zoom in to click on radio buttons. The mission was to reinvent mobile web browsing and have customers choose us over Chrome, Opera, and the like. The bar had been set high, the undertaking was daunting, but it was enough motivation to inspire a strong team—just another day with your average startup.

  For consumer-based startups, the game plan was pretty simple—raise cash, build something, and get people to download it.

  So how does a young company go about attempting something like this? For consumer-based startups, the game plan was pretty simple—raise cash, build something, and get people to download it. We didn’t have to worry about operations or fine-tuning our sales pipeline, we just needed people to download our app and give us five-star reviews. Money would come after popularity—the commonly held belief at the time. It’s a gross over-simplification, but that’s more or less how it went with many startups.

  Jessica and I were part of the initial batch of developer hires. Right after the startup had raised its goal capital, they hired eight to ten engineers within a few months. Headcount tripled and we were off to the races. Jessica started a couple weeks after me, and we quickly developed a rapport.

  We develop strong bonds with the people hustling beside us in the trenches. The ones who burn the midnight oil with us as we step through buggy code; the ones who hover over our desks waiting to press the release button. The person we can ask any question, with a single swivel of our chair. It’s the only other person reading through our pull requests. There’s something about writing a few hundred thousand lines of code together that fosters friendships.

  My relationship with Jessica was built on our mutual respect for each other as developers. I can be a judgmental person, and I happen to be especially harsh when it comes to other developers’ abilities. Of course, I keep these feelings to myself and always maintain diplomacy, but deep down I know who’s good, who’s so-so, and who’s firing shots in the dark. I know where I fit in the grand scheme; I’m not your level 100 wizard programmer. I can take in requirements, produce solid code, and get the job done up to spec, but you won’t find me writing compilers in my spare time.

  Anyway, once the developer hiring wave had settled down, Jessica stood out immediately. I could tell by her communication, programming skills, and intuition that she was no stranger to the game. She saw the same in me, and a developer-to-developer mutual respect engendered our friendship.

  As the ground troops of the operation, our lives were simple. We had a CTO, a VP of Engineering (VPoE), and other standard-protocol startup roles. The only thing we lacked was a product person, a void that would ultimately kill the company. Product development doesn’t run smoothly when the CEO, designers, and developers all have an opinion and there isn’t anyone laying down the law. Life as an “Individual Contributor” was simple. Jessica and I attended the same meetings, worked in the same code, and talked developer talk whenever we got a breather.

  Fast-forward a year and a half to when the company was in trouble. We’d gone from working behind closed doors, with big ideas and bigger dreams, to the reality of life as a post-launch startup. Product iterations weren’t improving traction, and a major pivot was slowly killing employee motivation.

  During this time, I made the personal decision to leave the company and move on. Even though our tech never reached the level we were hoping for, this was a special experience for me because of the people. I had learned tremendous amounts, made new friends, and fulfilled my urge to see what startups were like. I was sad I wasn’t going to be able to work with Jessica any longer, but we wished each other well and made sure to grab dinner often.

  Luckily for me, it didn’t take too long to find something else, with a business-centric startup looking to start building out its software. Their engineering team only had two people—my old undergraduate roommate and one other remote developer. This startup was drastically different from the last. This was a business-to-business, service-based company that already had a customer base and growing revenue. This is no easy feat. Most startups will bleed one hundred percent of their VC money in an effort to create the next Instagram. The roots of this company were in sales and operations rather than engineering. They were able to make money before actually building any software.

  That was an amazing sell for me, a developer coming from environments where engineering reigned supreme. I wanted to develop practical business and operational skills, instead of praying for downloads. Furthermore, since things were just starting out on the technical end, I would be able to design and implement a whole system from scratch—I had only worked on compartmentalized areas of the stack up to this point. This was an opportunity to give my technical and non-technical skills a major speed boost, and it delivered on all fronts.

  The job description was simple—come in, figure out how the tech complements the business, and facilitate the company’s growth into new markets. Also, let’s not forget the most important part: write a ton of code. I was excited about the engineering journey and was looking forward to a deeper dive into financing, accounting, marketing, and other disciplines.

  Since the company was so small, structure had not been established for any of the departments; it was just a group of people getting stuff done. My old roommate, who recruited me, had only started six months prior. The expectation was that we would be responsible for leading and growing the team. A definitive technical leader hadn’t been established, but the CEO was hoping that my friend and I, leveraging our friendship and relationship, would grow the engineering department from the ground up.

  Fast-forward to a year later. Our technical system had been growing day by day, and it felt like I had received an associate’s degree in accounting and sales. The company was running lean, holding off until cash flow could break even before turning to any new venture capital. We were still only three developers and were stretched thin trying to help all the other departments.

  Pretty soon, we realized that our bandwidth no longer matched our timeline and goals—we needed to get more programmers onboard and start prepping for expansion. I was impressed at how much we had accomplished up to that point, but there’s only so much that three people can physically do. We began to plan for the difficult process of recruitment.

  The first person I thought about recruiting was Jessica. It turned out that the timing was perfect. Jessica had been slugging it out at the same job for a year, but that old startup was finally deciding to close up shop. It was an opportune moment to put on my sales-hat and pitch her on my current company. Jessica and I had kept in touch ever since I’d left, she’d been giving me play-by-plays on random interviews with random compani
es, and I knew that nothing had peaked her interest. She had high standards and a good nose for bull. Jessica was talented, she was on the market, and I was excited at the thought of working with her again.

  I pitched the company, telling her about how it was poised to expand and how we were already making money. We had all the other departments covered—marketing, sales, operations, finance, and product. I told her we had the bread and butter of a real company; this wasn’t going to be a group of twenty engineers burning VC cash. We were sprinting to grow the tech, and we sorely needed her help. Fortunately, I had picked up a thing or two from my new friends in sales, and some of my persuasion techniques had leveled up. I got Jessica to come in for an official interview.

  This is when the story takes a turn for the worse. During this courtship process, there was one important topic that I conveniently ignored—management—and that was a killer omission. At the time, we only had a vague idea of hierarchy within the engineering department. For the moment, the department was completely flat, and all three of us would meet weekly with our CEO and CFO for requirements gathering. Though it was not yet set it stone, I was under the impression that I would eventually begin reporting to my ex-roommate—he was, after all, the one who had recruited me. I also assumed that Jessica would eventually fall somewhere below me, since I was the one to recruit her.

  We were young developers who really had no idea how these things worked.

  We were young developers who really had no idea how these things worked. We swept ticking time bombs under the carpet, and focused on sprinting and coding. The team would eventually fill out and everyone would fall into the right places, or so my ex-roommate and I thought.

  But I was thinking only two steps ahead, when I should have been looking ten miles further. What if Jessica wasn’t cool with reporting to me? I didn’t know the answer to that because I hadn’t asked. What if we were going to hire an external CTO one day? How important was rank to her? My mistake was my purposeful omission in place of an honest communication of our situation. Maybe that kind of stuff can fly with strangers, but it’s a clear red-alert between friends. I told Jessica that the hierarchy wasn’t yet established, but that there would be a need for leadership as our team filled out with more engineers. I did not at any time explain that she may well find herself reporting directly to me.

  I wanted to recruit Jessica and bring her in on this golden opportunity. I held the company in high regard and wanted to share the journey. We needed someone with her coding skills, and I knew she wouldn’t be on the market for long. We needed to get stuff done—I naively put the thorny issue of hierarchy on the back burner. I had expectations that I selectively left out of my sales pitch.

  Now, for Jessica, management wasn’t yet established, which meant she was on the same level as us—one of the ground troops—and had an equal opportunity to eventually climb into a leadership role. The idea that she would have to report to me had never occurred to her, due mainly to me failing to bring it up in our conversations.

  I would quickly learn that having to report to me was a deal-breaker for Jessica. Perhaps it was because of our history as side-by-side developers, perhaps it was our friendship, perhaps she thought I was grossly incompetent, or perhaps it was just pure ego. I’ll never truly know. All I know is that, as far as she was concerned, it was completely unacceptable to be under me on the company totem pole. This simple omission acted as the catalyst for months of stress and misery.

  Jessica accepted the job offer and joined us in our cramped room with her new MacBook Pro. We were in a very different environment now. Remember, at our previous job we were in the trenches and things were simple. We got delegated work from the VPoE and we got it done—no drama. With this company, we were the engineering team responsible for making every single technical decision. Management came to us with their biggest problems, and we built solutions. This was high-level responsibility shared among us, without any indication of who was the technical leader.

  With this level of open-endedness, things soon became complicated. We didn’t always agree on the best direction to take with the software. With five departments asking us to build things, we didn’t always agree about what was the most valuable thing to work on. This was compounded by the new dynamic we had as colleagues. I found myself having to guide Jessica through many non-technical aspects of the job, which was reasonable enough, given that I had been working there for almost a year. But I could tell she felt uncomfortable having me show her the ropes.

  I was also behaving differently. Since I expected to step into a leadership role, I had begun acting as if that were already the case. Small things I did, which would have meant nothing if clear lines of authority had been established, got under Jessica’s skin. I would ask her simple questions like whether she was enjoying her work, the kind of questions managers ask new staff, and would be met with the glazed eyes. My day-to-day peace of mind was taking a punch to the stomach, as I became evermore preoccupied with Jessica and our professional relationship.

  Before long, it was blatantly obvious that things were not working out. I took it upon myself to try to fix them. I had hired Jessica; I was the one responsible for the problems. I had been trying to do this on my own for a while, but the issue was reaching breaking point. It was time to address the matter head on.

  From an engineering execution point of view, we needed Jessica. Her coding skills were unreal; she had the potential to provide an insane amount of value. But our working relationship had broken down so much that it was affecting her work. To make things worse, I was right about the eventual managerial structure; I would report to my ex-roommate and Jessica would report to me, and this was about to become official. It was time to have a crucial conversation.

  This single issue was the deal-breaker. By the time our scheduled meeting took place, Jessica already knew what was coming and had developed a resentment towards me—understandably. I tried to empathize with her anger; it was wrong of me to keep my expectations hidden from her when I sold her the job. Every time I opened my mouth, I could feel her discomfort.

  Jessica ended up leaving the company. By the time this happened we had completely stopped hanging out. We had spent so much time and energy dealing with this problem at work that we had forgotten we were friends in the first place. The late nights grabbing dinner and drinks were over. This unfortunate professional drama had stained the friendship.

  This took place over four long, arduous months. The root cause of it went all the way back to those days when I was pitching the company to Jessica as a friend and fellow coder. I should have made it crystal clear right then that she would probably be reporting to me, which would have enabled Jessica to make the most informed decision possible. If I had spoken openly back then, I have a hunch Jessica would have turned the offer down. I would rather have lost a coder than a friend, but what’s done is done.

  We had spent so much time and energy dealing with this problem at work that we had forgotten we were friends in the first place.

  This was painful learning experience for me. The smallest discrepancies can blow up in your face if they are left unaddressed. It was an honest mistake on my end, and it won’t happen again. The best way to help others make an informed decision is if you lay all the cards out on the table beforehand.

  28: Your Initiative [Learning]

  There are only three stages of learning in life: what your parents teach you, what an institution teaches you, and what life teaches you. Being severely unqualified to talk about parenting, I’ll move right on to the other two stages.

  Learning in school is like night and day with real life’s lessons. Academia is relatively easy. An iterated curriculum has been established and provided for you; you spend zero mental energy planning. All you need to do is follow the path given to you and pass the classes. This is table stakes, and you will be guaranteed intellectual growth.

  A lot of my friends were surprised by how slowly they were learning after they lef
t school; some even wanted to go back, just to have that academic rocket progression again.

  When life hits, you suddenly have to plan your own curriculum, and this catches people off guard. A lot of my friends were surprised by how slowly they were learning after they left school; some even wanted to go back, just to have that academic rocket progression again. Whatever your situation, your learning will always be in your control—and it all starts with your initiative.

  Opportunities to learn will be present for your whole life—as Henry Ford said, anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning is young. For some of you, this may be a no-brainer. You might work at Google, where you can ingest huge amounts of information from qualified engineers on an almost daily basis. You might have an amazing mentor guiding you step-by-step through your career. You might be working on an amazing project where you’re able to pick up a variety of new skills. If this sounds like you, feel free to skip this chapter—this is for everyone else.

  There’s a learning curve for any job. Once it plateaus, many people can turn on the cruise control as things get easy. Don’t expect to get pushed hard by your performance reviews; they are most likely an inconvenience for your manager. At the end of the day, the only thing you have is your initiative; it has to be strong and it has to be a habit. I cannot instill this value into you, but I can show you its potential.

  Asking

  Asking is a very easy thing to do; it just needs to be done with a little bit of humility. There will always be someone more experienced than you, and it will be up to you to utilize that person’s knowledge. Remember, this is your responsibility, not theirs. Your superior is not a soothsayer and will not be able to read your mind. They have the skills and experience; you have the honest introspection and self-awareness. Mix in some thoughtful questions, and you have a formula for growth. Simply asking, “How could I have implemented this better?” goes a long way.

 

‹ Prev