Someone pointed out to me the other day that I am a bit of “an old fart” in the .NET development space. At first, I was about to protest and insist that I wasn’t that old. Then it occurred to me that I have been using .NET since the first public beta, which came out in 2001 (if I recall correctly, which I may not, because I’m old). That said, as I think back over my career and the loads of developers who eventually got out of the industry, I wistfully contemplated giving some advice to the folks just getting started. The reasons for it are many. First, I want to see more people succeed. Second, I’ve watched loads of people fail (or worse, not rise to the full level of their potential), including screwing up via self-sabotage. Here, then, are some things that I’ve noticed that might serve as “lifehacks” for making your climb through your career a little easier as well as making your survival more likely.
Specialize early. Let’s say you are working on the .NET stack (this isn’t a bad starting point for the day job, but you may want to pick a different stack for your long-term career, as some of the newer ones are compelling with less competition, as .NET was when I started). Learn enough to get around, but then pick an area where you can (reasonably) quickly get to the top of the heap and study it deeply. It may not even be .NET, but something else that you use as part of your job. Seriously, if you are junior to me and are a whiz in AngularJS, git, WCF, etc., I’ll probably defer to you on difficult questions. The point here is to get yourself into a position where folks higher up the food chain rely on you to varying degrees and see others doing the same. They won’t remember your title when they are looking for another developer to join them at their next position, but they will remember skills. Further, you have to remember that it isn’t as efficient for more established developers to learn new technologies (or it doesn’t feel that way to them), because they already know how to do the task at hand another way (or a dozen, if you are talking about Microsoft data access technologies over the last 20 years) and they are more established to the degree that they cannot examine every new thing in detail as it comes out. You’re in a position to help them, while improving things for yourself. You’ll notice this pattern more in this post.
Talk to your current boss and senior peers about your career trajectory early on. You’ll be surprised how many will take you under their wing. And if you happen to get the one in a hundred who feels threatened by this, get out of where you are as soon as you are able to do so – time is the only thing you can’t make more of and your career will suffer for the waste. That doesn’t mean that they will always be able to help you immediately, but they might keep the idea in mind when they are cleaning out their bookshelf at home and run across something that isn’t useful to them, but would help you a lot. And find out where they hope to go, because you may well run across something that can help them (including jobs elsewhere that might be a good promotion for them).
Talk to (and learn from) people in other departments. Never let things devolve into an “us vs. them” situation. Many organizations do an absolutely terrible job of allowing communication between departments. This is a place where personal interaction between you and members of that department can be a godsend for both parties. Further, you’d be amazed at the amount of overlap that really happens between jobs. You’ll regularly deal with the general ledger if you are doing any accounting-related programming, and it’s helpful for both you and the people interacting with that system to be able to communicate directly. Also, don’t leave sales and marketing out. If you think you aren’t doing marketing when submitting your resume somewhere and doing sales when you are interviewing, you’re out of your mind. I’ve conducted interviews from the other side of the table, and it’s quite clear which developers realize that they are marketing themselves and which ones don’t. You can bet that makes a difference in how people perceive you too.
Watch how you phrase things. Telling someone “this system sucks” is not helpful. It’s far better to ask why the system is the way it is. Be conscious of the fact that a lot of things in this industry have changed and the rate accelerates a little every year. Code from 5 years ago is as bad as medicine from 500 years ago in some cases. And code that had many hands in it over a lot of years and was initially written under pressure is as bad as battlefield medicine was 500 years ago. That’s not to say that the system doesn’t still suck, but that you are missing the opportunity to learn from someone else’s war stories and potentially pissing them off to boot. They may be real interested in a better approach, having been continually burned by the old one. Set things up right and you are the person who delivers that approach, rather than yet another greenhorn mouthing off because “classic ADO.NET, ewwwwww”.
Be careful how you advise others. Yes, the older coder may be stuck in his ways. He’s also seen some stuff, probably including something that looked just like what you are doing now and that failed in the way that the thing you are suggesting is going to fail soon. Then again, he can be wrong. Lots of developers remembered the debacle that was VB 6 web classes and some of the old school ActiveX stuff that kind of worked, but opened a security portal to hell from which many organizations still haven’t escaped more than a decade later. Many of them missed the boat when silverlight came out (along with the revenue), then saw that technology fail to pan out as well as it could for the same sorts of reasons that killed the prior two. On the other hand, they may think “Javascript sucks, because I used it in 1998 and it sucked then and NEVER AGAIN”. Find out why before you make a judgment – I know a number of things I’ve thought were dandy and awesome over the years later proved to be nothing but crap, just like the old-timers said. Further, if you do get their opinion on it respectfully, when something comes up that is using that technology and they see that it is awesome, guess who is coming to you for advice. You move further up in someone’s estimation of you by helping them than you’ll ever move by trying to convince them you are smarter than them.
Never leave a good job over just benefits or money, and never take a job just for those reasons either. I’ve done it once for each, having left a great job for the worst one I’m likely to ever have for a mere $10K raise, and turned down a good job for the second-worst job I’ve ever had, simply because I could work from home. It takes an awful lot of money to be able to ignore a soul-sucking job, and that amount will never really cover up the pain (plus, it will trap you there when the pain gets worse, because you’re not going to find a replacement position as easily at the same rate unless you’ve really worked to improve your skills).
Expect to hop jobs a lot. I hear frequent complaints that IT people change jobs frequently. There is good reason for this, as that is the only way to get a raise that is in excess of inflation for a lot of companies. I have, twice in my career, gotten raises. Both were less than the rate of inflation occurring at the time. The system is horribly broken, but you can’t fix it, so you have to live with it. Just be careful that you don’t jump too quickly and too often, as you’ll start getting a reputation. Set a reminder in your google calendar to update your resume every 3-6 months and do it when the reminder goes off. That way, if you get downsized, you are fairly close to ready to start looking for a new job, rather than being flat-footed and panicking for a day trying to find your resume and update it. Desperation shows on resumes.
Never practice resume-driven-development. You want to use a new technology? Do it on a side project of your own and bring it in to show people. Don’t try to make it happen at the office. When everyone is doing that without good, solid reasons (and especially when the new technology is still version 1.0 or worse), it can quickly make a system nigh unmaintainable. Further, when a department is known to allow this sort of thing, it undermines the people who are bringing new-ish technology in to solve problems that are really costing the company money (versus simply cleaning up dirty code).
Practice the things you want to get better at every day. If that means learning to debug better, learning to use your environment better, typing or reading faster, or simply refactoring code (you do this, right?), practice every day. Keep solid discipline about the way you practice and do not allow sloppiness that you don’t want in your method to get in. Remember that practice doesn’t make perfect; practice makes permanent. You can become one of the top 5% in most things in technology simply by continual practice at a low level.
Take care of your health. Those bottles of soda you drink while you are coding all day and half the night are not your friend, nor is sitting still in a dark room all day every day. Nor is hopping outside very 20 minutes for a cigarette, screwed up sleep from chugging caffeine all day, or back/neck problems from sloppy posture. It’s far easier to keep the weight (and subsequent other problems) away when you keep them from occurring in the first place than it is to fix them. This may mean a little less time for coding (and probably playing games or watching TV at home), but it beats being sick, dead, or fervently wishing. It’s also much easier to interview well when you have the confidence of a decent physique than it is when you are ashamed of being out of shape (not fat-shaming here – just pointing out that most folks find it mentally easier to carry themselves well when they are healthy).
Don’t neglect your mental health either. Physical health helps with this, as does being willing to walk away from crappy jobs or personal situations. Keep a “finger fund” in the bank. At least, that’s what I call mine. It enables me to raise my middle finger and walk away. Having had it in place, I’ve almost never had to use it, but the people I know who don’t have one really need it.
Work on your communication skills. Yes, it’s stupid that as human beings that the packaging of a message often matters as much or more than the contents. It’s also an immutable fact of life. If you haven’t read “How to win friends and influence people” by Carnegie, stop reading and do so now.
Learn how not to be stupid in office politics. I’ve seen loads of highly competent developers get steamrolled because they aren’t paying attention to what is actually going on in the office, versus what is being said. Words are wind; learn to watch actions. Keep notes somewhere safe about who interacts with whom and how – many decisions are made by informal networks instead of company committees. Learn when to keep your mouth shut to avoid creating problems for yourself. I suggest reading “The 48 laws of power” by Robert Greene if you need some practical instruction.
Have some lines that you will not allow to be crossed. If they are, your resume should go out that night. It may be an employer demanding that you do something unethical; it may be a jerk that believes you should always put your family’s needs behind those of the company because they lied to a client and are willing to burn you out to cover their own butt (true story, bro), but have the line. When it is crossed, get out of there, even if an apology is made.
Learn how to look for signs that you are about to get burned. Is the company telling everyone else what’s going on with them after some big thing that is coming up, but hasn’t said anything to you? That’s because you aren’t going to be there, son. Get that resume ready. Did the awesome guy that hired you just get canned due to internal squabbling? Send the resume out now, even if it is the middle of the day. It’s not likely that the other faction will keep his management style, and new management always seems to fire someone and rearrange the office when they come in (a new dog sniffs around the yard and pees on something too, if you like apt analogies). If you are a junior dev, it’s probably you getting the firing or the bad desk.
I know that some of the above sounds terribly jaundiced. It’s not intended as such. Engineering your career is just like engineering anything else in that one needs to carefully account for failure cases. You’re going to learn a lot as a junior developer in a very tight timeframe (my first couple years easily tripled the value of my skillset and probably would have doubled my pay were it not for the recession). But you do need to be aware of not only how to grow your career in the direction that you want, but be capable of avoiding things that knock it off-course. The latter is routinely done in a very poor way, and most problems can be avoided by proper prior planning, decent interpersonal skills, and observing what is going on the environment. Sometimes you’ll get blindsided by career-shattering things, but most of the time, you can see trouble coming a mile off if you know where to look. You’ll note that I didn’t suggest anything technological in this post. That’s with good reason – it’s because it matter less than the rest. I’ve seen some absolutely skunky programmers get senior leadership positions because they knew how to play office games and I’ve seen some brilliant people fired because they did not (or because they couldn’t express themselves clearly).