by David Xiang
Bring Up Issues & Maintain Tact
Your relationship with your boss will not always be sunshine and rainbows; you will have your fair share of disagreements and tension. In times like these, the manner in which you bring up issues is extremely important. Always maintain composure, tact, and discretion when bringing up your concerns. Many people underestimate how easy it is to create long-lasting bad will.
There are clear and common themes that arise in every work-based situation. All managers would love their employees to speak up more about their issues as soon as they occur. However, no one wants to have any issue laid at their feet in an emotional or unpleasant manner. If you have an issue, bring it up calmly rather than let your own frustrations and resentment get the better of you.
The average developer does not become disgruntled overnight. It takes a series of negative events that eventually snowball into a mountain of demotivation.
The average developer does not become disgruntled overnight. It takes a series of negative events that eventually snowball into a mountain of demotivation. This may be from too many mundane bug fixes, pointless refactoring efforts, bad chemistry with colleagues, or a loss of faith in the company. By the time the developer chooses to formally bring up these issues, they are biased and mentally exasperated. Suddenly company issues now feel like personal issues. Given these feelings, going into a potentially crucial conversation with your boss is a delicate interaction. Engineering managers can sense this almost immediately and can easily go on the defensive, rather than being the helpful senior team member you need.
As mentioned in the previous section, your relationship with your boss is special, and it is a relationship that must be nurtured. Issues will arise and you must bring them up quickly and respectfully. Do not wait until you are pulling your hair out before you call for a one-on-one.
Micromanagement & Consistency
Micromanagement is pervasive in any job. More often than not, when we reach the point where the word is used in the workplace, it’s because something has gone wrong. Yet employees like to hand the blame to the boss—it’s the boss who is paranoid, who is putting us under unwarranted scrutiny. If this feels like your way of thinking, take a step back and evaluate your own work. Are you producing at the same quality and pace you were a year ago?
Working fast or slow is fine, as long as you are consistently working fast or slow.
Managers increase scrutiny when someone’s work has lost consistency. Consistency is a paramount for developers. Working fast or slow is fine, as long as you are consistently working fast or slow. This is why it is imperative you pace yourself. Having a high output for six months, only to slow down to a crawl for another six months, is reason for any manager to become concerned. Would they be doing their job properly if they were just to ignore the changes in your output? Without any additional information from you in the first place, what choice do they have?
25: Understand What You Are Doing [Coding]
Avoid at all costs any situation where you might find yourself unable to explain why your code is working. I cannot over-stress this; this is a developer’s single most dangerous pitfall. Not being able to explain something that’s broken is a simple matter of debugging, but not being able to explain something that’s working is shooting yourself in the foot.
Understanding your code is a crucial part of your progression and effectiveness as a developer. For any modern project environment, there is a sea of beautiful frameworks and services providing plug-and-play magic to help you create masterful works of software art—all without you really needing to know how anything works. If you add in the right snippets from Stack Overflow and perform some selective copying and pasting, you’ll be able to work your way through a majority of feature requests without really understanding what you’ve done.
Not being able to explain something that’s broken is a simple matter of debugging, but not being able to explain something that’s working is shooting yourself in the foot.
I’ve seen developers do this, and it can be frightening. Is this how you want to develop? I’m sure you already know the answer to that. We must strive to have total understanding of our work.
The Environment
Before diving into code, you will go through a standard environment setup process. During this time, you must understand exactly what is being configured and why. Sometimes you’ll have a colleague sitting beside you who can explain what you don’t get, while other times you might find yourself sifting through stale documentation. Whatever the case, give this process the attention it deserves. Your environment shouldn’t be a mysterious black box.
If your team requires you to install some system packages, for example, ask yourself: What do they do? What files are installed? How do those scripts alter your environment? What do you do if it can’t install the packages you need? Do you need to build anything from source? Take an inventory of all the unique processes that need to be running—MySQL, Redis, Rabbit, etc. If a script starts up twelve different Docker containers, understand at a high level why you need each one.
Familiarize yourself with whatever platform your colleagues have chosen for development. This is extremely straightforward, yet some people neglect to spend the appropriate amount of time doing exactly that. If your whole team is on Ubuntu but you’ve been using Fedora for the past five years, make the transition! A few jobs ago, my team had mandated a custom CentOS image that all the developers were supposed to use. A rogue developer refused to use CentOS and did all his development with Ubuntu. I shouldn’t have to state the obvious, but it was painful for everyone.
Once your local is up and ready for development, you should know exactly what’s running, why it’s running, and every single step it took to get it there.
The Build Process
Every project is organized, interpreted, and built in a different way. After setting up your computer’s environment, you’ll do whatever it takes—no doubt with some help—to get the project ready for development.
Control over the application code is a no-brainer, but control over the build system will give you a leg up and pay dividends.
Periodically take a pass at the build system to really understand how everything comes together. You must understand all the nuances and weird dependencies. Why is the directory structure laid out the way it is? How is third-party code getting integrated into the project? Do you know each and every step of the build? What subset of these steps can you get away with not running and why?
This build and configure process is pervasive across software development—every project has a layer of configuration surrounding its raw application code. This ranges from tricky CMake files with cross-platform compilation clauses, to obscure Webpack configuration flows that only the original author really understands. Do your best to learn about all of them; this will give you control over your project. Control over the application code is a no-brainer, but control over the build system will give you a leg up and pay dividends.
Debugging
Debugging is the best way to understand application flow. Breakpoints are your friends, and you can step, step, step your way into becoming a source-code master with them. If you’re completely stuck, starting with main() always works.
You should never scrub through a sea of source files. This is a waste of time. Debugging will get you up to speed quickly and direct you to the specific files that you need to understand. Execute the code before understanding the source; you’ll be in for a rough time if you do this the other way around.
Testing
For any reasonably-maintained project, there will be some level of testing—you deserve to flip a table right out of the room if there is none. Understanding how tests are structured is another essential part of development. The reasons are similar to why we must understand the build process—control.
Every project will be tested differently, but there are a few common themes. First, there’s always some kind of scaffolding to set up test
data. This could be a static file that loads a bunch of objects into memory before the suite is run, or a dedicated test database that you need to pull from periodically. Whatever it is, where there are tests, there’s data.
Second, tests will likely include mocks for first-party and third-party services. In a world where people love abusing micro-services and paying for SaaS, we make an overwhelming amount of external calls, receive fancy web-hooks, or subscribe to a mashup of publishers. It can be difficult to keep track of what’s ours and what’s not. When looking through the source, understand which paths are real and which paths lead to mocked interfaces. What code are you actually testing? Do the mocks make sense?
Finally, don’t spend too much time trying to understand other people’s test code—it’s going to look ugly. Not many people care how their tests are written, just as long as they’re written. While you shouldn’t really skimp on your test code, it doesn’t have to be as pristine as application code. The minimum requirement here is that you have the tools you need to test, and that you actually write them. Testing is an amazing habit to get into and it will spur you on to write better software and become a better developer. As a professor once told me, every line of untested code is debt!
Deployment
Every single project is deployed somewhere. If you’re writing a Linux library, you’ll generate artifacts, package them into some special binary, and publish it to a repository. If you’re working on a web application, you’ll have to update code, migrate data schemas, and restart processes in project-specific ways on remote servers. Deployment is an intense process! Imagine the processes Netflix goes through to deploy new code and stay online at the same time, just so all of us can continue binge-watching TV shows—it’s amazing!
For large software teams, deployment may be out of your scope, or it could be the only thing you work on. For smaller teams, understanding the deployment procedure is a necessity. Do your best to understand how code gets packaged up and sent to its final destination.
Neighbors
Last but not least, put in the effort to understand neighboring applications. No matter how many things you’re working on, I guarantee there are a hundred more processes, micro-services, and applications that make the machine tick.
Whatever the context, understand your relationship with your direct neighbors. I use the word neighbor to mean any other internal application that your application depends on, or vice versa. How is data exchanged? Where are the interfaces defined? What is your application really responsible for? What is the communication medium between micro-services? You don’t have to go as far as the neighbor’s neighbors, but I won’t stop you.
The end goal of this effort is to strengthen your grasp on the system. You may not understand everything, but you’ll understand a whole lot more than if you remained working in a single-application bubble.
Every company packages their product up with a shiny bow, but if you take a peek under the wrapping, you quickly realize that it’s a chaotic zoo.
Conclusion
In the realms of software, there are a ton of moving pieces that somehow end up working together. Every company packages their product up with a shiny bow, but if you take a peek under the wrapping, you quickly realize that it’s a chaotic zoo. You must put in the effort to understand what you are doing at all times. As you can tell, this is significantly more than just understanding what you’re coding. Don’t just understand how your project is working, but strive to understand how everything works. It’s going to be extremely challenging, but that’s the fun part—right?
26: Red Flags When You Interview [Career]
Significant career decisions are pivotal moments in everyone’s life. A decision almost all of us will face, at some point, is whether or not we sign the dotted line at the bottom of a job offer. Whether it’s your first job or your fifth transition, interviewing and accepting a position are always important moments.
Even though hiring managers are professionally trained recruiters, they’re still human; they can still fumble from time to time.
Anyone who’s transitioned can relate to that moment when you awkwardly excuse yourself to go to a “doctor’s appointment” and slip out for an on-site interview. Everyone can relate to that first twinge of guilt when you start returning intro phone calls from recruiters.
Whatever the situation, you will inevitably find yourself in all kinds of emotional mind-states as you hunt down your first position or make up your mind to jump ship for a new opportunity. This chapter focuses on certain red flags that are good to keep an eye out for while job hunting. These are stressful times. You must stay focused to prevent yourself from making irrational decisions.
Strange Questions
Even though hiring managers are professionally trained recruiters, they’re still human; they can still fumble from time to time. A few years ago, I was speaking with an HR representative at the tail-end of an on-site, when he asked how long I intended to stay with the company if I got the job. What the heck?! At that precise moment, the question didn’t faze me—I was so eager to leave my old job that I brushed it aside without a second thought. This question was outrageous by even the most conservative standards.
Asking how long you intend to work for a prospective employer implies many things—never brush off a question like this. On the surface, this is a blunt and unprofessional way of checking your loyalty. Why would they ask this? If it’s because you’ve changed jobs every six months, then it’s a reasonable question. However, if it’s because the engineers at their company are churning and turnover is at an all-time high, then alarm bells should ring. You might just have pulled back the covers on something you weren’t meant to see.
This question is equivalent to asking someone on your very first date how many years they think you should date before breaking up—ridiculous! My advice here is to stay alert, scrutinize every question, and never brush something like this under the rug. If any question or apparently small remark seems off, there is an underlying backstory to it that can unearth useful insights.
Transparency & Integrity Check
Transparency from you is expected, but don’t forget that you as interviewee can expect the same kind of transparency back from your interviewer. A transparent interview will feel genuine, honest, and like nothing is being held back. Are all your questions being answered thoroughly and to your satisfaction? Does it feel like anything is being purposefully hidden from you? Is anything being over-sold or over-represented? How would you measure the integrity of your potential employer? Pay attention to how things are presented to you, not just what’s presented.
Excessive Salesmanship
You’ve spent the last two weeks showing off your coding chops and dominating the interviews. You’ve proven your worth, and now the company gears up into sales mode in its last pitch to bring you on board. At this stage of the game, you must keep an eye out for excessive salesmanship.
The reality is that the whole world runs off of salesmanship and deals.
Some people are natural salesmen. You immediately like them, you nod your head more when you’re with them, and they just make you feel comfortable. A good salesperson can sell practically anything to anyone; it’s never about what they are selling, but about how you perceive them as a person. These traits are characteristics of many CEOs—it’s one of the reasons they’re in those positions in the first place; they’ve sold their idea to investors and they’ve sold their dream to employees. They might be selling to you right now!
My goal here isn’t to paint sales in a negative light, but to remind you to remain vigilant when you are being sold to. The reality is that the whole world runs off of salesmanship and deals. Everything, from the small contract you sign with Verizon, to the most recent billion-dollar company acquisition, is a sales contract between two parties, at the end of the day. There is nothing wrong with salesmanship; you just need be aware of when and why it’s happening.
When you’re consider
ing the possibility of a new job, be extremely specific with your questions. You and your potential employer will collaboratively uncover—with high integrity—the true nature of the position. If it’s what you want, then the position should sell itself. Specificity begets honesty and will disable any salesmen from speaking at overly generic levels. Excessive high-level rhetoric is an immediate red flag.
Office Interaction Check
When you’re on-site for an interview, make a mental note with regards to how people interact around that office. What’s the vibe like around the water cooler? Do people look lively, or demotivated? Most likely, you won’t be able to directly observe this, but even the smallest intuition can go a long way. Treat it like body language— the office’s body language can carry significant weight in your decision.
More importantly, pay attention to the interactions with your interviewers. Evaluate how your interviewers describe their role, their work, and the company itself. When you ask, “What do you do on a typical day?” how enthusiastic are their answers? Do they care?
When the Interviewer Speaks Ill About the Job
This may seem like a no-brainer, but it happens more often than you’d think. I’ve been asked by an interviewer if I was sure I wanted to work there. This is a polite way of saying:
“Do not take this job! Get out of here ASAP!”
If an interviewer is going out of their way to drop hints like this, something is up—pay attention.
It’s an experience both my friends and I have all been through, and it has consistently led us to unfortunate circumstances. When this happened to me, it threw me off—just not enough. I brushed off the remark as an insignificant hiccup and took the job anyway, because of the nice salary. It wasn’t long before I realized I had made a terrible decision. That was a year and a half of unnecessary stress I will never get back.