3 things every programmer must learn (and no one teaches you)
If you read all these tech/coding blogs, you must spend your every waking hour learning the latest technology buzzword. You have no option but to keep running, or you will be left behind. Etc etc.
But is it really true? Do you really need to know the latest super sexy technology to succeed in your career? Certainly my (limited) experience doesn’t say so. While having good coding skills might get you the job, it most certainly does not help you rise up the career ladder.
There are three things every programmer must know to succeed in the real world, and that no one teaches them. No university, no blogs, and certainly none of the online Gurus. These things are simple, and can be expressed simply and shortly. They are:
Be Assertive. Be Visible. Take Ownership.
That’s it. Three simple things, yet it took me ten years to learn them. Boy am I stupid.
Be Assertive
You will meet a lot of different type of people. Most will be nice decent people, and you will be honoured to work with them. A few will be assholes (and I use the term asshole in the most clinical and scientific way possible, as described in Bob Sutton’s book).
Even nice people will at certain times, under pressure, make unreasonable requests.
Every career programmer (as opposed to hobbyists) needs to learn to be assertive. Note now, that assertive is different from aggressive. Assertive is standing up for yourself,_ without attacking or abusing the other person. _This point is very important, as many people assume assertive means picking a fight when someone hurts your feelings. It couldn’t be more wrong. If someone cuts off your car, and you give them the finger, or pull up and abuse them, that is not assertive.
Sometimes, being assertive means walking away. I was at the airport, and a passenger was screaming at the girl behind the counter, for something that was clearly not her fault. She said, “You know what? I don’t have to take this,” and left. That was being assertive.
This is a real problem for programmers, as we are usually a shy and reserved bunch. This can lead to a situation where others, more outgoing types make the decisions for us. I faced this problem early on in my career, when a project was delayed due to problems with the hardware. A senior vice president level manager wanted to know why, and I was too shy (stupid?) to explain why. My direct manager was forced to step in, and though he did an okay job, it wasn’t as good if I had explained myself. For a long time, my impression was ruined with that manager (who just happened to have the final say on promotions).
That’s when I learnt the lesson- I needed to be assertive, and stand up for myself. If there are problems with your work, and there always will be, due to your or others fault, you need to stand up and explain why. Remember, assertive, not aggressive. Be calm and cool, explain your point, but don’t harp on it.
Similarly, if you are asked to stay late or come in on weekends, you need to assert yourself, and not let yourself be bullied. Remember, unless your contract specifically mentions overtime, it is a negotiation, and a negotiation always needs two people to agree. You may still agree to stay late, but make sure you are getting something out of the deal, anything more than a pat on the back.
Be Visible
Another problem I faced was that no one knew about me. I suffered from extreme shyness (and still do, to a degree), and so took on projects where I would spend the maximum of time in front of a computer. While I thought I was doing great work, writing cool code, fixing critical bugs, the impression most people had of me was ………………. Nothing. They had no idea I even existed. When a chance for promotion or interesting projects came along, guess who wasn’t even considered?
Even very senior engineers can face his problem. I was researching a very advanced algorithm the company had created, and was giving a presentation on it. I started off by saying “This algorithm was created by X.” Whereupon Y stood up and said, actually, she had done a lot of work on it too.
This surprised me, as in all the internal documents and code, her name was no where. It seemed X had written most the documents, and “forgotten” to add Y’s name. X got promoted to Chief Engineer, and Y? Well, she’s still at the same position.
This is a very extreme case, but one worth bearing. These documents weren’t written in secret, and Y had a lot of time to correct X’s oversight. But like me, she was shy and assumed that it didn’t matter anyway. Well, it did.
I’m not saying go around blowing your trumpet. But make sure your managers are aware of what you are doing. You will be surprised at how little your manager knows about you. Even if you use agile and something like daily standup meetings, your boss may have 10-20 people reporting to him/her, and honestly forget your work. So make sure everyone is aware of what you are doing, and if someone “forgets” to credit you, you can remind them gently (assertive, not aggressive),
Take Ownership
While its nice to be visible and assertive, it still won’t help you get promoted. See, the only people who get promoted and get really good pay rises are those the company thinks it can’t do without. So when your boss tells you you will only get a 0.5% pay rise, because conditions were tough, and that’s all that headquarters approved, you can bet your 0.5% pay rise that certain star coders got more than 0.5%. If you work for an honest company, they may even tell you that they did this by giving certain people no payrise, just so that the star coders could get a better than average pay rise.
How do you become a star programmer? Not by knowing functional programming or Lisp/Rust, or whatever the Leet programmers think is cool. It is being indispensable to the company. The guy or gal everyone goes to when shit happens (as it invariably will). One way to become indispensable to start taking ownership. Is there a hard to track bug everyone is scared of? Volunteer to look at it. A technical issue irritating and slowing everyone? Offer to script it away, or look for open source software that fixes your problem. And no, you don’t have to do overtime to fix the problems. Let the boss know that you will be spending an hour or two daily of your work hours (or more if its a critical issue) looking at this problem. If the boss disagrees, it may mean the issue isn’t critical enough, or if he wants you to spend personal time looking at the company’s problems, it’s a good time to start updating the CV.
But in most good companies, your boss will be happy to let you spend a few hours looking at the issue. S/He may even be able to justify the time to their own boss, and ask for more time. But the key thing is: You will be seen as a person who takes on hard problems, and is willing to go beyond the bare minimum. Even if you can’t work miracles, or your solution sucks, over time (which maybe a year, or even more), you will be seen as a problem fixer, a goto guy/gal, someone management can trust when the fecal matter hits the fan. And trust me, that’s where you want to be. This will also solve the visibility problem, so next time a promotion/cool new project comes along, you can be damn sure your name will be considered, and maybe even recommended by all the people you helped.
Three simple things, that took me ten years to learn. What did you learn by hard and painful effort? Please share in the comments below.
Related: