10 Things People Don't Tell You About Being a Programmer

Time for another 10 Things, this time about programming.

1. You'll get good at learning new topics and becoming an expert within a short time. That's because you will be handed assignment/features/tasks that you don't know from up or down but you will figure it out, solve the problem, and become an expert in some new arcane knowledge along the way.
2. You'll fix the same bug over and over. Normally some hairbrained bug you introduce yourself too many times before you learn to work around your own mistake. This is called experience.
3. Managers won't build your career. That's your job pal. You want something? Figure out how to get it. Set a path, get support from your boss, and do it. Your boss is too busy keeping you and your teammates on track while keeping others out of your hair so you can build code.
4. You will get good at dumbing down what you do for a living. People don't get programmer speak. I can speak English that others won't understand a word of it unless they are also a programmer. You will need to temper that enthusiasm for the non-programmer mortals of the world.
5. You'll learn when they want you to think and when they want you to code. Programmers are people. We are opinionated, quiet, loud, argumentative, you name it. But there are times when people want your input and times they don't. Learning when to recognize this will help.
6. The one language is! You will be a jackass and piss off the non-believers of your language, editor, IDE, etc of choice. We all have done it. Try to tone it down. Unless you are trying to take the piss out of someone, then by all means, be a jackass.
7. Code wins arguments. You can sit in a room for hours on end debating the best path forward. Or you can go get shit done. There is time for both but when you get bogged down in meeting/analysis paralysis, it's time to shut up and code.
8. You need to read code to code. Don't like that OSS library that says it solves your problem but comes with no documentation? Then read it. Read the code. Read the program that implements it. Look at how it works. The code is the documentation. Test cases exist? Read them, they show how the devs intended the methods to be used. Sample programs? Read them. Read before you go off and try to solve stuff someone else solved already.
9. Learn your tools. Don't be a baby. New team uses a different tool as part of their process? Learn it. Your attachment to the one true revision control system or whatever is just laziness. Most of your tools work similarly or are based on a fundamental design decision. Go read up on that, figure out why someone wrote the tool, what problem it is supposed to solve, how your team uses it, and then read some of the docs on it. Learn it, be a shepard to the unlearned. Help your team be more efficient with their tools.
10. More programmers have died from not checking return codes or catching exceptions than for any other reason. This is a serious ailment that only you can cure. Or am I dreaming that? Whatever. Check your damn return codes. Does it throw an exception? Then catch that puppy.