Software Developer Life

by David Xiang

  After I’d worked on three or four projects, the seeds of my demotivation had rooted themselves. I wasn’t in control over any of my work. I had no freedom of choice, from which projects I worked on, all the way down to the features I was implementing. Since developers never spoke with the clients, the main creators and delegators of work were always the business analysts. It felt like a big game of telephone.

  We didn’t know why we were working on these tickets, but we had to work on them.

  As a result, life became a never-ending queue of JIRA tickets. These tickets were supposed to map to real requirements, but you can only take things at face value for so long. For me, this was the essence of my demotivation. We didn’t know why we were working on these tickets, but we had to work on them. I knew that in some meeting room somewhere, a conversation was being held about what the engineers should be spending their time on, but that was a conversation I was never a part of.

  I would like to tell you that I personally turned a new leaf and became a happier developer. Unfortunately, that’s not the story. Everything changed when a new developer, Jennifer, joined our team. She single-handedly lifted our team into a better place. Her actions and attitude were exemplary, and I hope they motivate you like they motivated me.

  First, Jenn came in with raw curiosity—a feeling we had all lost long ago. She didn’t mind our never-ending queue of tickets. She would pick up the most mundane ticket and run with it. She asked thoughtful questions and dived into code that no one else wanted to touch.

  At this point, I admit that I wasn’t the happiest camper. My colleagues and I were doing the bare minimum to meet our business analysts’ requirements. We were long past the most important part of software development—caring. When an eager new graduate asks you why you implemented a particular feature the way you did, it’s embarrassing to admit that you got lazy. Jenn made us start caring again.

  Jenn quickly surpassed all her peers in value. About a year into the job, she started venturing into uncharted territory—customer meetings. We realized that if we wanted to sit in on customer meetings, all we had to do was ask. I guess we had been too busy complaining to try! Jenn started attending these meetings, growing relationships with customers, and what started out as quiet observation turned into something much, much more.

  This was a win-win-win situation for us. Clients who were growing tired of our business analysts complacently nodding to their demands now had a person they could have a real back-and-forth discussion with. Since Jenn knew the intricacies behind the implementations, she was able to thoroughly and transparently respond to customers.

  I cannot stress how much they appreciated this. Our status quo of black box communication in the company had been disrupted. Jenn’s interaction with customers turned into model behavior for the entire company. To get on her level, other business analysts had to put in extra time to understand the tech and be ready to give Jenn-level answers to our customers’ probing questions.

  To complete the triple-play win, Jenn’s model interaction was a breath of fresh air for the developers. As requirements cleared up and became reasonable, we started to care more and more about our work. Nebulous tickets with generic descriptions were replaced with focused milestones where everyone understood the why. Once you get everyone on the same page of why, the how turns out to be pretty easy. I wasn’t lying when I said a single person lifted our whole team up!

  The key to unlock all doors is always communication.

  The key to unlock all doors is always communication. Before Jenn stepped up, we were isolated and undeservingly grumpy in our dark developer caves. I didn’t fully appreciate communication until I saw its value through Jenn. She knew all the code, knew all the business requirements, and seamlessly transitioned between the two.

  If you feel like you’re wallowing in demotivation, remember that you are in more control of your attitude than you think; there is something that you can do, and it starts with communication. Don’t stay too long in the grumpy developer cave, don’t wait for a Jenn to come by to motivate you, and don’t underestimate how much control you have over your own mindset.

  11: Speaking At Meetings [Daily Life]

  Meetings are a universal part of every job and contribute significantly to your personal brand within the company. As an introverted engineer, pursuing any kind of presence in team meetings has never come naturally to me, but I have come to appreciate its importance. Whether you like it or not, your personal brand will directly affect your experience in any corporate setting. Meetings develop your brand, and they must be navigated.

  Don’t Speak Right Away

  Unless you are the host, there’s no need to be the first one to speak in a meeting. As an attendee, focus on the meeting’s theme, and get a feel for the mood. What is the current collective state of mind? There is no point speaking up if you have no idea what anyone is thinking— pay attention.

  Whether you like it or not, your personal brand will directly affect your experience in any corporate setting.

  Who’s in the room, who’s listening, and from what position are they participating? The VP is dropping in and just wants a quick overview—no need for nitty-gritty details. Your manager’s ass is on the line and he’s sweating over the new roadmap—give a detailed progress report. The grumpy senior engineer is upset because the team didn’t follow through with their proposed design—let’s not pour any more salt on that wound.

  As the meeting progresses, get as much of a feel for the mood as you can. This shouldn’t take long if you’re perceptive and stay focused—you will have Jedi mind-tricks soon.

  Learn Everyone’s Personality

  People’s current state of mind is fickle; you must go deeper and understand their core personalities. This will take some time, but the knowledge is crucial for the long-term and will improve all future interactions you have with your colleagues.

  Understanding the foundation of your coworkers’ personalities allows for seamless communication with them.

  Understanding the foundation of your coworkers’ personalities allows for seamless communication with them. What’s their basic behavior? Some people love to hear their own voice, so let them air their thoughts. Other people love to be disapprovingly silent; pull them into the conversation with guiding questions. How do your colleagues prefer to digest information? Some people understand things through numbers, others through stories, and others through logic. Gather every single nuance you can from everyone around you, and do it discreetly.

  Understand People’s Expertise

  Understand where everyone’s expertise lies and what they do. Big company or small company, you will be in meetings with a recurring set of people. If you’re ever in the dark, research the meeting participants ahead of time and find out what they work on. Dig into their projects, their background, and what frameworks they’ve been using. It will empower you to have this information on hand, as you will know exactly what the other people are bringing to the table.

  During a meeting, ideas build on each other and you need to be on top— ideally ahead—of the group’s train of thought.

  Focus

  Maintain focus throughout meetings and follow the group’s train of thought. It is easy to let your mind wander. Bring a notebook and scribble down notes on everything, whether it seems important at the time or not. You can flesh them out later. When you get your footing, focus hard on what is being said. During a meeting, ideas build on each other and you need to be on top—ideally ahead—of the group’s train of thought.

  Give and Receive Credit

  There is only so much thunder to go around. Someone will steal yours, just as you will take another’s. If you’re not cognizant of this, you can easily find yourself in someone’s bad graces.

  Give credit where credit is due. For example, let’s say that you’ve been working with Sarah on a feature for the past three months. During a status meeting, you get called upon to give a status report. If you give the repo
rt as if you’ve done everything, you become the jerk thunder-taker—don’t do this. The words you choose are essential:

  “Sarah and I had a few good design meetings, and we came to the conclusion that we shouldn’t use Google APIs for this feature anymore.”

  The we is critical. Try replacing it with I and see how bad it sounds. Acknowledgments live and die through the use of simple words.

  What about the thunder stolen from you? While some may not care for such things, you have the right to expect your dues. If this happens repeatedly, approach Sarah amicably.

  “Sarah, I would appreciate it if you could mention that we both contributed to the project when you give your status updates.”

  Psychology + Body Language

  Read up on basic human psychology and try to become aware of body language. These are basic life skills, abilities that come with time for everyone, but they’re worth working on—in a meeting, being able to read the room is a noteworthy skill.

  When You Don’t Know the Answer

  On those (hopefully) rare occasions when you have the spotlight but no idea what to do or say, the best option is to admit that you don’t have the answer. Right afterwards, communicate to everyone that you intend to follow up on the issue and provide a thorough update later. It can be as simple as saying you’ll look into it. Show that you take every question seriously and will give it attention.

  12: Code Sense [Coding]

  As a software-naïve college junior, I landed an onsite interview with an advertising company in New York City. The job was 100% web programming and I had 0% experience with web code. My expectations were minimal—let’s get through this interview without too much embarrassment and enjoy an all-expenses-paid trip to NYC for the weekend. To my surprise, the internship bar was pretty low, and I passed the interviews with some pre-meditated definitions of encapsulation and polymorphism. I got an offer and took the job.

  Despite my best efforts, I was an extremely confused intern; I had no idea what was going on. I spent that summer monkey coding my way into productivity. Monkey coding is when you copy and paste other pieces of code and carefully massage it to do what you want. For huge code bases, this gets you by and requires minimal knowledge of how things are actually working. I had a few recurring thoughts during my time there:

  I can’t believe I’m allowed to contribute to the codebase. Shouldn’t there be some auditing or something?

  I really didn’t understand that environment setup.

  This seems like a terrible way to implement this, but I’m too much of a noob to propose anything better—this doesn’t feel good.

  I spent that summer monkey coding my way into productivity.

  Despite my unrest, I still had a productive summer. I learned basic web development, wrote some Java, played with SQL, and pushed out a handful of useful features for the company. We even won an internship project challenge just for having a good presentation. All in all, it was a solid eleven weeks.

  That summer was significant for me; I discovered that I severely lacked something. I trampled my way through rampant hacks and poor design, and I couldn’t do anything about it. I got things working, but never felt like I really developed it. I was missing something—the elusive “code sense.” This sixth sense comes with time, and it’s something we as software developers are constantly developing. It’s the first impression you get when you look at a file. It’s the ability to spot bottlenecks and pinpoint vulnerabilities early. It’s being able to thoroughly fix a bug once and for all. It’s avoiding nonsensical dependencies, recognizing subtle side effects, and much, much more.

  Where does your code sense originate from? It comes from writing a lot of code and being conscious of its quality. The more code you write, the cleaner it becomes and the more code sense you accumulate. Here are some of my top points for clean code.

  Leave Code Cleaner Than You Found It

  Every piece of code can perpetually be improved upon. If you see a subtle inconsistency, fix it. If you can’t fix it, question it. This creates a virtuous cycle where everything—from a local variable name to a complex code path—slowly improves.

  The alternative is that the source tree doesn’t get any water. This is the road that leads to a convoluted and frustrating codebase. This is the road that leads to those inevitable complaints you’ll hear from developer friends:

  “Our code base sucks! The people who wrote this were so incompetent!”

  Let’s be honest with ourselves, whose fault is it when the code base sucks?

  There’s an important caveat to all this. You must only change code that actually needs to be changed. If it’s not broken, don’t fix it. This year, Blizzard announced that they’re rebooting StarCraft with some visual touch-ups, but they stated explicitly that they wouldn’t touch anything to do with gameplay. If you can get a project to this level, congratulations. For the rest of us, your code will constantly be in flux and demand change—it needs to be taken care of. Some call this the “Boy Scout Rule.”

  You must only change code that actually needs to be changed. If it’s not broken, don’t fix it.

  Recognize When Things Get Hard to Change

  Clean code is flexible and can easily be updated. You don’t measure software in terms of it being complete or incomplete, you measure it in terms of how well it can withstand change. It’s a bad sign when a simple feature addition feels like you have to rebuild the Death Star.

  Major companies have seen their products fall into obscurity through convoluted software. Unless you’re Google and swim in Scrooge McDuck vaults of gold, the universal rule of “time is money” applies to all software development. As a developer, you are responsible for your company’s code. If the team can’t complete their tasks within a reasonable amount of time, then the software is doing the business a disservice and money will be lost. Always keep an eye on the deadline. Ease of change and overall flexibility are great code health checks.

  Readability

  Many developers—yourself included—will read your code in the future. In one year, I guarantee that you will forget about the classes you wrote this past week. For sanity’s sake, optimize for readability. You are writing software for the future; never underestimate how long your code will stick around in the source.

  Focus on flow, be deliberate with comments, try to keep files under a thousand lines, and don’t get lazy with formatting. Everyone can learn to deal with a condensed coding style and fancy language techniques, but no one can uncover what was on your mind when you put that hack in.

  Consistent and Thoughtful Naming Conventions

  Naming is simultaneously the easiest and hardest part of programming. Put in your utmost to name things consistently and thoughtfully. Do not break existing convention due to personal preference, do not blindly copy-paste, and do not declare variables with single-character names.

  If you’ve done a good job, your peers will nod their heads quietly through most of your code and be able to focus their feedback on core changes.

  Thoughtful naming enables effective communication, which produces happy developers. You will be in endless meetings, code-reviews, and brainstorming sessions. During these gatherings, no one wants to nit-pick over poor naming conventions. Even if there isn’t any verbal nit-picking, just seeing someone else’s awkward naming can leave a bad taste in your mouth. If you’ve done a good job, your peers will nod their heads quietly through most of your code and be able to focus their feedback on core changes. Don’t underestimate the power of naming and consistency in your code, it will save you and your colleagues precious time and brain energy.

  Be Careful with Dependencies

  Be careful with dependencies! This is much easier said than done. If one of your micro-services is heavily catered towards every application it serves, it’s not a very useful service. If two or more objects in the system always rely on each other, ask yourself: Can these things ever exist separately? Should they just be one thing? Thoughtless depend
encies beget technical debt. We must stay vigilant.

  Life becomes simpler with one-way dependencies. They work on many levels, but let’s take a look at a high-level example: third party libraries. You add in a one-liner and get some useful functionality pumped into your project—almost like video game cheat codes. If you’ve done a good job as the third-party author, you will have clear documentation, an intuitive interface, and a seamless integration process for any client to use your code—this is how you get those GitHub stars. There are countless high-caliber projects out there, but for some reason we seldom have that level of detail with our own code.

  My last point is about dependency injection—don’t abuse it. This feature is magical and convenient, but it doesn’t mean you can start making everything available everywhere. Having one hundred parameters in your constructor, or fifty auto-wired private variables, can be extremely convenient, but it still isn’t a good look. Dependency injection makes life easier, but at the end of the day, it’s still a dependency.

  Keep dependencies at the forefront of your thinking. If the machinery in your system is too tightly coupled, the smallest change will have a huge ripple effect and you’ll be cursing the moment you attempt to fix that deceptively innocent-looking bug.