Hey, it’s me again. You might remember me from such under-appreciated classics as “People are Not Resources” and “Agile/Scrum is Bullshit”, but more likely for my previous piece, “10 Things Every Developer Should Learn.” Welcome to “9 Things Every Developer Should Do.” It's not exactly a follow-up to “10 Things”— more like a spiritual successor.
Tenacity Is Your #1 Skill
Every developer will be handed problems. It’s part of the job and one of the more rewarding parts at that. But your career is made or broken by how you handle those problems; I’ve made my career out of being the go-to engineer for the big, hairy problems that no one else can figure out. Being able to take something that other people have tried to solve, whether that’s a coding problem, an issue with some operation’s functionality, or getting a new technology working; it doesn’t really matter as long as you can do it. And the big secret is that it doesn’t take any special knowledge or skill, you just have to keep at it until you get it done. That’s it. Are you going to have doubts as to whether you can do it? Yeah, of course you are. I’ve had them too. Are you going to want to give up? Yep, but that’s when you need to push through and just get it done.
My first job in technology was as an on-site IT guy for a retail company. Being the only IT guy for the company had its ups and downs (sometimes I really miss the freedom I had, since I could basically implement, build, and work on whatever I wanted), but one episode that marked a watershed moment was when I failed to upgrade our Active Directory domain version. Being a green engineer I had the bright idea to upgrade our domain from Server 2003 to Server 2008R2, seeing as I was in the middle of decomming our 2003 domain controller. So I pulled up the MSDN how-to, got all my stuff together, and dove into the process.
Then it failed. At 3 P.M. on a Tuesday.
Everything went down. E-mail, RDP logins, everything. Fast forward to 3 A.M. that next morning, I’m still at the office: tired, hungry, frustrated, standing in the server room trying desperately to recover our primary domain controller, when I have this thought: I could just leave and never come back. I could block all the company numbers, leave my key in the office, grab my stuff, and just walk out. No one has to know I ever worked here. Someone else can fix this problem.
I didn’t do any of that. I stayed. I worked the problem and eventually got it fixed. Sure, I had caused the problem in the first place, but fixing it felt amazing at the same time. Tenacity won out.
Never Stop Learning
I cannot stress this point enough: you have to be willing to learn if you want to grow in your career. If you don’t want to grow and are happy with being a .NET 4 developer for your entire career, well, to each their own, but if you have even the slightest inclination to move up, change positions, or do something different, you have to be willing to learn new things. “New things” could be new languages, new technologies, new methods, etc., but you need to continue your education in some capacity. Doing so not only makes you more valuable to your current employer but it also gives you more leverage when negotiating compensation and opens up more opportunities should you decide to go elsewhere.
Challenge the Status Quo and Ask the “Dumb” Questions
My favorite question to ask is “Why?” and I would argue that it should become yours, too. Challenging the status quo won’t always make you the most popular person in the room, but innovation demands that we stop and ask why. No good thing comes out of maintaining the equilibrium — either we lose sight of the original goal and our goals become maintaining what’s already there, or we step back, examine why things are the way they are, and find out if there’s a better way to do things.
The best way I’ve found to do this is to take it back to the basics and ask the “dumb questions.” You don’t have to come out and say “Why are we doing this?”—not only will some people see that as rude, but it’s also pretty vague. Instead, asking something like “Is there a specific reason why we’re using Product X for this part?” will get you the same result, but in a more focused and direct way.
Read the Fucking Logs/Manual/Documentation
I really can’t stress this enough: you have to actually read what is given to you. Any application, library, package, language, or whatever that’s worth it’s salt will have a decent enough documentation set. Even if it’s something as simple as an API reference, you have to actually use it.
Way too many times I’ve had someone ask for help on an issue, one that they’ve been banging their heads against for a long time, only for me to discover the answer literally staring them in the face. Log outputs and error messages are there for a reason and you should read them. Often they tell you exactly what is wrong, and if not, there’s usually someone on Stack Overflow or Server Fault that has a solution for your problem. Before you jump down a rabbit hole and start looking at kernel parameters or trying to find obscure bugs on Bugzilla that explain your symptoms, you should try stopping, reading the output, and taking it at face value. If it says that it's missing a field value in some XML tag, try adding the field value to the XML, don’t go chasing down a phantom issue that may or may not have been introduced when you upgraded Tomcat versions if the answer is literally written out in a log file in front of you.
This exact scenario played out soon after I joined my current team. We got paged by our network operations center because they were seeing an issue in production where some message queues wouldn’t connect. Three managers and I stayed after hours (hey, free dinner!) and banged our collective heads against this problem for hours. We tried everything we could think of: rebuild the Tomcat cluster, update the machine images, check what kernel modules were loaded, run down every single DNS failure mode we could think of: you name it, we did it. I was new to this particular stack at the time and was pretty much only there because I wanted to impress my new bosses and because I could be a fresh pair of eyes on the problem. I made one critical mistake, though, in that I didn’t re-check everyone else’s work. When you’re running down a production issue there’s no time to “play nice” or try not to step on everyone’s toes because in that moment no one cares (rather no one should care) if you check their work or try to find something they missed. When I finally decided to go back and look at the logs despite someone having said they already had, I discovered the root cause: Tomcat had changed a tag name in its XML configuration. The tag we had been using was no longer valid and we needed to change it to a new value. I quickly tested it and poof! Tomcat came up and started working as expected.
The moral of this story isn’t how I fixed the problem, the moral is that oftentimes what the logs or errors or documentation tells you is exactly what the problem or error is. Take it at face value, try that solution first, and if that doesn’t work then you can fall down the rabbit hole.
Stand Up, Walk Away, Get Coffee
There’s no rule that says you have to stay at your desk. When you get frustrated, stuck on something, or just tired, unless you’re literally chained to your desk, get up and walk around. Go get some coffee, chat with some colleagues, do something to take your mind off work. The human brain is a strange organ — even when you’re not actively thinking about a problem it's still trying to work through solutions in the background. Letting your mind relax and wander isn’t wasted time, it’s time spent letting your brain work through things asynchronously.
I’m a shower thinker. Not exactly practical for working in an office, but when I’m working from home or I have a problem that is bugging me outside office hours I like to hop in the shower and let my mind wander. There’s something about being in the shower, for me at least, that lets my mind wander in a way that it doesn’t when I’m just sitting and thinking elsewhere. Some of my more awesome ideas have come from just sitting in the shower and zoning out. It sounds counterintuitive but it goes back to letting your brain work through problems in the background: it’s always thinking, always working, so give it time to think and work.
Now, I’m not talking about 24/7 always-on, always-answering-email kind of availability, but generally, someone should be able to reach you when they need to. Whether you are on-call or not (if you have an on-call rotation) someone from your team or your management hierarchy should be able to reach you should the proverbial fan be hit by any proverbial excrement. This goes doubly if you’re working remotely: always be reachable during office hours. It doesn’t matter if its Slack, e-mail, text, phone, Skype, Facebook Messenger, AIM, Twitch, or whatever, your team needs to be able to reach you and, possibly more importantly, you need to be able to participate in your team’s discussions.
Win as a Team, Die as an Individual
Just as important as your relationship with your manager is your relationship with your peers. You need to build and reinforce that peer-to-peer relationship — you live as a team and you die as a team. Especially so if you are a senior member of that team, you need to recognize your peers when they do awesome work and take responsibility for your failures when they happen, because they will happen. No manager is going to fault you for making a mistake (the good ones won’t, at least), the greater sin is not learning from those mistakes (see #7). So when you screw up just take the responsibility for it, learn from it, and don’t do it again. The absolute worst thing you can do is lay the blame for your mistakes at the feet of your peers.
The opposite is true for success, though. When you win as a team, don’t take personal credit for it. If someone wants to call you out for your contributions, let them, but taking credit for things that were a team effort is also the worst thing you can do.
Toxic Workplaces Kill
There is no software job more important than your personal well-being. Let me repeat that:
There is no software job more important than your personal well-being.
There is no boss, no peer, no bit of code, and no company that deserves to be more important than your well-being. It's okay to leave your job, especially when you find yourself in a toxic environment and there’s no way to remove yourself from it inside the company. Find a new job, put in your notice, and walk away.
Early in my career, I worked at a small software shop that did commercial and government contracting for digital communications systems. It was a small ~20-person office (dogs not included), the kind where everyone knew everyone and I felt like I was the odd one out from day one. I was excited to start there, though, because while I had been a full-time admin in my previous position, this position offered more in terms of technologies and opportunities to learn development and DevOps (in fact, this was the position that drove me to learn Python and AngularJS, so I guess that’s a win). They touted their “flat structure” as a way of saying that everyone was equal and you’re your own boss, but in reality, it became very clear very quickly that there were two or three people who really ran the office, despite titles and whatnot. The office, in general, was a high-tension, backstab-y, snitchfest that made it a not-at-all pleasant place to work. Asking questions was frowned upon, and my counterpart (the long-time IT guy) had anger management problems, meaning if you caught him on a bad day/hour/minute he was liable to just yell at you for literally anything. Needless to say, it didn’t work out there.
Walking out of the door for the last time on that Friday I realized that I had been internalizing so much stress and so much tension that the relief of never having to deal with those assholes outweighed any frustration or fear I had about being without gainful employment. It was literally a weight off my shoulders. By Tuesday I had found a new job at a small MSP that I thoroughly enjoyed and where I met one of my good friends. The moral of this story is really simple: get out. Monster.com has a really great guide for checking if your work environment is hostile, I highly suggest you go check it out and evaluate your current working environment.
If You Don’t Want to Do [Thing], Don’t Put It on Your Resumé
This is something I’ve been guilty of and I’m sure I’ll make this mistake again. When you’re looking for a new job it's fairly obvious you want to make your resumé look as good as possible. So what do we do? We put everything we’ve ever worked on onto our CV. Every technology, every tool, every language we’ve written
hello world in, it’s all there. But somehow we’re always surprised when we get hired and they ask us to work with or manage a piece of technology we actively dislike. It usually goes something like this:
Now you’re stuck being “the Jenkins person.”
So how do you avoid this scenario? Treat your resumé not as simply a catalog of your past career, but also as shaping the next step in your career path. Your CV sets the boundaries within which people will hire you. If you make those boundaries as broad as possible you’ll get more responses, but the odds are that most of those responses won’t be for positions you actually want. By narrowing the focus of your CV to the technologies that you’re really good at and actually want to use, you ensure that you won’t find yourself in a position that you don’t really like, necessitating yet another job search.
Did I miss something? What are some things that you think every developer should do? Let me know in the comments!