by David Xiang
The first assignment was to render Mickey Mouse. We were given two things—a massive dump of XYZ coordinates and a deadline. There wasn’t a friendly student forum to discuss homework. There weren’t regular office hours. The homework assignment itself barely counted as an instructional document. All we had was a huge cloud of obscurity—something very normal for a CMU CS course. This was a short interaction I had with a TA:stor
“Hey, which language should we use?”
“Whatever you’re comfortable with. Java or C++ should work.”
“Ok. Is there anything we can download? A homework template or something?”
“Template?! No templates here. You should be able to compile your source and execute it.”
“Ok. Are there any progress markers? How will I know if I’m on the right track?”
“You’ll know you’re on the right track when you render Mickey Mouse. We just need to visually see Mickey by Friday. Also, this is the easiest assignment.”
Now, you might be thinking that doesn’t sound so bad, nothing too strenuous for a coder, but let me give you an idea of where I was coming from. I was a mechanical engineer who at that time had yet to take a single programming course at CMU. How was I even let into this course? I’m not really sure to be honest—it’s all a blur. I had done a tiny amount of programming back in high school, but nothing like what was expected of me here. How do you even get a C++ project started? What’s GCC? What’s a Make file? Should I use Java? What’s the JVM? I don’t have Linux installed, am I screwed?
… it’s sometimes the complete lack of training and resources that makes CMU, CMU
You see what I mean? I was a total noob. Luckily for me, Google had been invented and I had a lot of stamina. After a sleepless week, I pulled through and delivered one rendered Mickey Mouse. I’d never been so happy to see a Disney character on a screen before. I remember the day I got that mouse to show up, I felt like there was a holy light shining down on my computer.
CMU is known for having one of the best engineering programs in the world. People think we have the best teachers, the most thorough training, and the most highly accessible resources. However, it’s sometimes the complete lack of training and resources that makes CMU, CMU. Tenured professors come to campus twice a week, give a couple obscure lectures, then disappear before their TAs can hand out crazy homework assignments. Despite the “world-class” program, there isn’t as much structure as you may think.
Jumping into the deep end is an amazing way to learn. There will be times in your life when you’ll have the opportunity to put yourself through forceful learning or take the easy way out. I recommend everyone try the forceful way. Just remember to jump with discretion; that feeling of drowning can turn into real drowning if you’re not careful.
This is academic pressure and growth. What happens when you don’t work your ass off? You fail. How about a nice textbook and a list of resources? You’re lucky we have Google. Implementation guidelines? Choose whatever programming language you like. Can’t code? You can always drop out. We got used to two simple things—expect nothing and execute everything.
6: Fifteen Minutes Dictate A Year [Career]
Throughout life, we periodically find ourselves in the middle of crucial conversations. Whether they’re personal or professional, they all have one thing in common—they have a direct impact on our lives. You will have many of these conversations throughout your life and you will undoubtedly mess many them up, but you will grow from them, and, more importantly, you will never forget them.
Keep in mind that importance will always be relative; you might be sweating over a performance review, but it’s just another day-to-day meeting for your manager.
The crucial conversations I’m going focus on will be in the context of your career in software development. The conversations will fall along a spectrum. The big, stressful, scary conversations come during final interview rounds and nail-biting salary negotiations. The easy ones might land in your lap during an honest, open conversation with your boss.
A casual chat with the boss might blindside you, but most of the time, you’ll have time to prepare. Always be mindful of when a crucial conversation is about to happen. Keep in mind that importance will always be relative; you might be sweating over a performance review, but it’s just another day-to-day meeting for your manager.
You must be prepared for every crucial conversation, because they can affect your entire life. A fifteen-minute conversation about your salary will dictate what hits your bank account for an entire year. Preparedness is paramount and this chapter can help.
What Do You Want?
As a prerequisite, we must understand what we really want. Friends and family are useful resources, but at the end of the day, only you can define what you want. Always keep the concept of alignment in the back of your head. The big objectives in your life should align with your day-to-day conversations and activities. None of us have a straight path to our own personal North Star, but as long as we think about alignment, we won’t fall into the trap of drifting. According to Napoleon Hill—pioneering self-help author and author of “Think and Grow Rich”—drifting is the absolute worst thing you can do to yourself. Easy for me to say, but obviously, very difficult to do. We can struggle with this together.
If you lack the clarity of thought to divulge your own wants and needs, you will inevitably have an unproductive conversation with your counterparty.
Let’s take the example of learning how to code. Learning how to code is just an activity, but what is your main objective? Break this down. Do you want to become a full-time software developer and make a career out of it? Do you want to level up your technical chops so you can be more literate with computers? Do you want to learn to code just to prototype your disruptive business idea? Your objective will dictate how you pursue your learning. It will influence who you reach out to, what you talk to them about, and the journey you have ahead of you.
How does this relate to crucial conversations? Understanding what you want is the first prerequisite to a successful crucial conversation. If you lack the clarity of thought to divulge your own wants and needs, you will inevitably have an unproductive conversation with your counterparty.
Let’s pretend you’re thinking about quitting your job. Your boss is aware of this and has scheduled a one-on-one with you to talk things over. You can feel the weight pressing down on your shoulders as the time of the meet gets closer and closer. Do you even know why you want to leave? Can you articulate what’s truly bothering you? Do you have any idea of what you would rather do? Let me tell you one thing, your boss definitely doesn’t know! Think about how awkward and useless the conversation will be if you do zero preparation.
Don’t Waste Time
As you clarify internally what you want and develop your North Star, it becomes easier to determine if a new opportunity isn’t going to align with your path. One of my biggest time-wasting moments came when I continued to arrange interviews even though I didn’t really want the position I’d applied for. My mindset was, let’s just see how this goes. Unfortunately, each one of those instances turned out to be a huge waste of my time and other people’s time. If you’re speaking with an employer and realize you don’t want the job, cut it off.
Be Honest with Leverage
A crucial conversation that every developer can relate to is the salary negotiation. A fifteen-minute conversation with a hiring manager will decide what hits your bank account for at least a year.
To prepare for these conversations, be objective about what you bring to the table. The circumstances will be different per conversation— sometimes you will have leverage, other times you won’t. The worst thing you can do is over-represent yourself. For example, many developers I’ve spoken with ask for above-average compensations but don’t have the track records to back it up. Software developers make assumptions about what they should be earning just because Glassdoor says so or because they have friends making the b
ig bucks in similar roles. Averages can be helpful guidelines, but you will only be compensated based on your value and what you negotiate for—not based on what other people negotiate for.
To drive the point home again, be honest about your value. Leverage comes with value, and value takes a long time to accumulate. The only place where you can stretch a little is when you set the expectation for the future; sometimes you can sell your employer on your impact in the years to come. This is a sign of good-will from both parties and will pay future dividends if you deliver on those expectations.
What Other People Want
We’ve established that knowing what you want is priority number one. Discovering what your counterparty wants is priority number two. Consider this as two sides to one coin. When everybody around the table is aware of what everybody else wants, then you can all move forward together. You need to align your needs with your counterparty’s in order to arrive at an agreeable position together. Again, this sounds selfish—but it is not. These are merely the mechanisms to have successful conversations.
For example, let’s imagine that you feel like you must make a set amount of money per year, no matter what it takes. You’ve internalized this. This salary must be met. You’ve prioritized it over the inconvenient commute, the underwhelming work, and a couple questionable interviewer personalities. As a quick aside, I will caution against prioritizing something so strongly at the expense of other factors. If money is truly the deal-breaker for you, your first line of defense should be to not waste time. For example, your target number is probably a financial impossibility for the recently-funded startup. Thus, your effort should be spent targeting medium to large-sized companies that can actually make that number happen.
But what happens if you’ve exhausted your leads and find yourself negotiating with a tiny startup? Your mind is still prioritizing cash. You know the compensation conversation is going to be hard. First, you must diagnose your counterparty’s thoughts so that you can keep their mind open. What does a startup CEO really want? She wants to hire a great developer, pay as little as possible, and get her dream off the ground. You must focus your attention on what she wants. You address her priorities first—you are a great developer, love the mission, and want to put all your energy into shipping code. Don’t think of it as keeping her open to salary leeway; it’s about keeping her mind open, period.
If you’re not careful, your counterparty will easily become combative and go into defensive mode—then you will definitely not get what you want. For example, how do you think the conversation will go if you bring up your salary number right out of the gate? Again, what does a startup CEO want? She really doesn’t want to burn through all her cash reserves! By not being cognizant of what she wants, you’ll completely close off her mind and consequently fail to achieve your salary goal.
When you have proved that you can provide what she wants, you can come back around and discuss money at the tail-end of the conversation:
“I understand your mission and I know I can ship this thing on budget and within six months. To do this comfortably and consistently for you now and into the future, I would need to have my salary raised. Would you be open to discussing that?”
Conclusion
At the start of my career, I didn’t have a clue about this concept. Conversations came and went, and I would think nothing of them. After a few years in the workplace, I noticed that I would never feel positive after having a serious conversation. I was never prepared. I wasn’t clear about what I wanted for myself, let alone what the people I was talking to wanted. I kept having unproductive interactions with important people. The conversation would never push me—or the other person—in a better direction.
In the past few years, I have put in significant effort to become vigilantly conscious of these interactions. I look forward to them, I prepare for them, and I strive to grow from them. There are many more crucial conversations to come for both of us; if you haven’t started thinking about them, get thinking now!
7: Think Beyond The Ticket [Coding]
Tickets—also known as tasks, issues, or stories—are a regular part of developer life. As of today, the Australians are still dominating ticket management software with JIRA and the Atlassian fleet. For tiny teams, tickets might be an unneeded overhead, but for many companies, all your work is tracked with tickets. This ranges from bug fixes, to writing documentation, to designing new architectures.
If getting assigned only one flavor of backlogged tickets comprises one hundred percent of your day, it may be time to ruminate about your job. Software development is not about fixing bugs 24/7. As a developer, there will be a never-ending queue of tickets, but this is not a bad thing. There needs to be a system to organize and track allocated tasks. A lot is said through tickets; let’s get ourselves into the right mindset to tackle them.
Hold a Standard
Hold all ticket-creators accountable. If it’s a UI touch-up on the settings screen, make sure the designer has attached all the relevant assets. If customer service reports a bug, they must provide steps to reproduce the broken behavior. If you’re filing a ticket to your colleague, it better be a step-by-step work of art. Reject any ticket that isn’t up to snuff; incomplete context is a waste of your time. Assuming the ticket is on point, clicking the “Accept” button kicks your job into gear. Someone has created a thoughtful ticket, and you will deliver a thoughtful solution.
Don’t Be a Robot
Regardless of how thorough the ticket description is, there is always more than meets the eye. Do not perform the bare minimum to resolve the issue; adding one extra else/if clause probably isn’t going to cut it. We must always understand the why behind our assignments. Who is the stakeholder and why does it matter to him or her? What kind of technical debt led up to this? Is it an innocent bug or something that turns our whole design upside down?
Do not blindly accept and execute tickets at face value—we are not machines. When tackling tickets, understand the why, have dialogues with the other stakeholders, and explore the edges. I guarantee everyone involved will appreciate it.
Every Edge Case
Enumerate every edge case. If you’re fixing a bug, the ticket will report only one of many scenarios where the problem manifests. Where are the others? Edge cases can also exist outside the context of code. Train yourself to think about edge cases in terms of the whole product or service—I call these the “Business Edge Cases.” If the designer has you implementing a new animation for the onboarding flow, maybe it clashes with an animation they had you work on for the checkout page. Bring that up; it could have slipped their mind. Keep an eye out for both technical and non-technical edge cases.
Parallel Awareness
A software team will be tackling a shared pool of tickets. Always be cognizant of what is happening around you. If you’re working on a task, how does your work affect your colleagues? Does it help someone out? Does it make their life harder? Is someone else working code that overlaps with this ticket? Can you leverage anything in progress? It’s easy to run with a ticket as a walled-off unit of work, but it inevitably leads to divergent implementations and duplicated work without proper communication. Few people have this level of awareness.
Always be cognizant of what is happening around you.
The Whole System
Always consider the entire software system. If the fix is truly a one-liner—that’s awesome. If not, ask yourself, How can I fix this and improve the system at the same time? Tickets are preliminary indicators of vulnerabilities in your code; use them to preemptively target, learn about, and fix weak areas.
Your Personal Queue
A ticket is just the tip of the iceberg. Every ticket symbolizes much more than a singular piece of work. A low-value developer will take each ticket at face value. A high-value developer uses the ticket to gain awareness of the system as a whole. Fixing the bug is just a nice side-effect.
No one else understands the intricacies of the
code like we do and it’s our responsibility to continually improve it.
Routinely create tickets for yourself. This doesn’t have to be officially sanctioned JIRA tickets stamped by management. This could be your personal to-do list that’s scribbled on your notebook. Remember, the non-technical ticket queue will never end, but who’s replenishing the technical one? We are. No one else understands the intricacies of the code like we do and it’s our responsibility to continually improve it.
Crunch Periods
Tickets are a reflection of work and are subject to a wide range of situations. The above points cover the majority of scenarios, but there will always be fire-fights and crunch periods when tickets won’t be created as works of art. For example, if the team is getting ready to launch a big feature at the end of the month, QA might come back with an avalanche of visual problems. It’s probably not reasonable to ask for a thorough description and annotated screen capture for all these issues. During times like these, tickets should be triaged quickly and fixed promptly to unblock the big launch.
Conclusion
Take full responsibility for your tickets. If the scope changes, communicate the differential to any stakeholder ASAP. Hold your colleagues accountable and make sure you have the context you need. Hold yourself accountable and make sure your team knows the true nature of your progress. Think thoughtfully about every ticket you tackle and you will become a better software developer.
8: Choosing Your Words [Daily Life]