When you’re starting your career in any field, you probably have high hopes but don’t really know what to expect. Should you keep your head down and do what you’re told or should you aim only for ambitious projects? Here’s what I’ve learned in my experience as a software developer.

Let me bat out a few suggestions based on my experience and observations. This list is not all-inclusive—because it can’t be. Your experience will be unique.

1. Don’t be afraid to learn on the job. Sadly, bookshelves at most workplaces are mostly just set-dressing (look at what our hackers claim to read!). You rarely see anyone reading one, especially not during core work hours. Still, you have a computer and can read papers and most books through an e-reader. So get to it. You’re not going to learn much if you just do what you’re assigned and little more. You also won’t move forward if you ask for more work and get grunt work. Be willing to slow down and do things right and read up on the fundamentals. How do people develop an expertise in a coveted domain like machine learning? One day at a time.

2. Manage your career aggressively. Take responsibility for your own education and progress. One out of ten people (if that) find a mentor who will clear paths and pull strings and make sure they come out on top for promotions and plum projects. If you’re in that other nine, and you will be most of the time, no one’s looking out for you. So look out for yourself. Don’t ask for more work unless you trust that person to give you better work than you’d get otherwise. When you can, do the bare minimum amount of work that’s not advancing your career or teaching you something; if it has no career-adding value, people probably don’t care enough about it for it to matter that you’re putting in a minimum effort, as long as you don’t get in anyone’s way. After three years, if you’re not being groomed for something bigger and badder, external promotion (read: changing jobs) is usually the way to go.

3. Recognize under-performance and over-performance and avoid them. There are a lot of low-effort players who stay employed for years. This isn’t a bad strategy if you’re settled, but I wouldn’t fall too low. That said, the only people who typically get fired for under-performance are the people who fail so badly that they generate work for others. People who hide and do little tend not to make any enemies. At the same time, be cautious of over-performance. This isn’t like college where challenging your professor’s ideas could earn you an ‘A’ if you argued your point well. Over-performers often generate extra work for their superiors and colleagues and draw unwanted attention (see: McNulty in The Wire) and are more likely to be culled for “performance” (98 percent of “performance management” in companies is politics) than under-performers. I’m not saying that you shouldn’t work hard and do a good job and learn as much as you can. That’s not necessarily over-performance; in my experience, though, over-performance—being recklessly ambitious, perhaps—is much more dangerous than under-performance. It can get you just as fired and it will happen a lot faster. If you end up stuck between the two, ebb towards under-performance.

4. Never ask for permission unless it would be reckless not to. Want to spend a week investigating something on your own initiative? Don’t ask for permission. You won’t get it. You might not actually be doing your boss a favor when you ask for permission; from their perspective, you’re asking for the right to pass the buck if your project doesn’t pan out. Since he can deny you and your buck-passing after-the-fact, in any case, because he outranks you, you don’t really gain anything from such a promise you might extract in the first place. So there’s no upside in asking for that permission. Of course, if you’re going to do something that presents a real risk to the business or where his permission would be reasonably expected, then go ahead and ask for permission. If the loss is small and the risk is appropriate to your level in the company (and any programming job where you’re not trusted with days to weeks of your own time is not worth having) then don’t ask for permission. Just do it, and do it well.

5. Never apologize for being autonomous or using your own time. You can admit that a project or investigation didn’t pan out, although it’s best if you can spin it as a discovery exercise, but you should never apologize for a failed side project. It sets a precedent of you as a subordinate who needs more supervision. After describing something you did of your own initiative, don’t say to the boss, “Don’t worry, I did it strictly as a weekend project.” If your company won’t let you work on something during normal work hours, then don’t do it on their behalf for any reason. Respect your time. Or no one else will.

6. Learn CS666 (what I call the politics of software development) and you can usually forget about it. Refuse to learn it, and it’ll be with you forever. As we get older, we tend to see the value in transferable and general skills: functional programming rather than Spring/Hibernate; algorithms rather than quirks of a Java 1.4 legacy system. Well, CS666 ain’t pretty, but it’s transferable across the industry in a way that no programming language ever will be. I’m not saying that one should become a political animal or get obsessed with the politics, because that won’t end well, but one ought to be politically aware because there’s politics in everything we do. It’s good to start studying people and their moves early, even if you’re not planning to play (and when you’re young, you shouldn’t play often). Whether you get the Hadoop cluster in time, who gets to make the technical decisions, whether you get that feature freeze you’ve been asking for so you can clear away some technical debt, and what projects you’re assigned… all politics, man. For better or worse, Meritocracy is the software engineer’s Prince Charming and, in the real world you’d best be on the side that gets to define “merit” and structure how it is measured. If you learn CS666, you get some time to breathe and forget about it and just do great work. If you don’t learn it, your career will be shaped by those who are better at it.

7. Don’t be quixotic and try to prove your bosses wrong. When young engineers feel that their ideas are better than those of their superiors but find a lack of support, they often double down and throw in a lot of hours. “Let’s prove our bosses wrong… by sacrificing our own time on something they will own!” Sorry, but if you have to throw down weekends (except on a rare occasion, like a production emergency) to bring a project through, that means that your bosses don’t actually care that much about it. Otherwise, you’d have the time and resources and no patience for quixotry in yourself or others. Rather than trying to hit a home run with a cracked bat, you just should just let that game be. When bosses are “shown up” by people they doubted, they don’t give that person an automatic promotion or raise. They find a way to confirm their negative impression (and your earnest self-association with a disliked project has put some stink on you) and, even if you succeed, you fail. If nothing else, there’s always “He did a great job on that, but he was distracted from his assigned work and so I can’t trust him going forward/we can’t let him set a precedent/it was actually my idea.”

8. Don’t fight other peoples’ battles. As you’re young and inexperienced, you probably don’t have any real power in most cases. Your intelligence doesn’t automatically give you credibility. If you get involved in someone else’s fight, or stand up for someone being unjustly treated, you’ll just get mowed down. Watch Mad Men and The Wire and Breaking Bad for how people really are when there are any stakes. Save all your energy for your own fights. The corporate world is not a place where social justice is valued—people protest by leaving, not picketing—and you won’t make any friends as a crusader. If you fight for yourself and it ends badly, you at least get some respect from some people (and that may pay off, years down the line) for your self-preservation. If you fight for other people, you’re seen as an arrogant young fuck who didn’t know the rules.

9. Try to avoid thinking in terms of “good” versus “bad.” Be ready to play it either way. Young people, especially in technology, tend to fall into those traps—labeling something like a job or a company “good” or “bad” and thus reacting emotionally and sub-optimally. You might think something like: “I’m not going to work hard because my boss yelled at Sam today and I’m upset” or “I’m going to sacrifice my own health and career goals and throw 90 hours per week after grunt work because this is a great start-up and we’re changing the world.”

Yeah, fuck that. Every organization is a mix of good and bad. Whatever the territory, use it to your advantage. Boss yells a lot? That actually makes him less of a threat to your career, should he go against you, because they probably aren’t trusted by their own superiors either. Assigned a boring project? It’s probably boring to your managers too, which means they won’t look at you much. You can put in a few hours per week and have 30-40+ left over to learn skills for your next job. Fucked-up culture? If you can stand it and others can’t, you’re a valued employee—and you can treat it as a learning opportunity (“MBA by counterexample”). It’s important to stop thinking of every event as “good” or “bad” in some biblical sense and just see the angles and how to play it. This is a skill that seems to improve greatly with age. You stop sizing complex entities like corporations as “good” or “evil” and just learn how the play the landscape as it is.

10. Never step back on the salary scale except to be a founder. As a corollary, if you step back, expect to be treated as a founder. A 10% drop is permissible if you’re changing industries (out of finance and into biotech research) or moving to a lower cost-of-living area. Beyond that, the answer is “no” unless you’re making a permanent move. Most people are actually really bad at assessing how good someone is at his or her job, which means that, in the private sector, your salary is the best assessment of your global rank and is a starting point for future negotiations. You better have a damn good reason if you step back, and it better be a high-status one. Employee positions at start-ups are no exception (count the equity at zero, for the purpose of this item). If you leave a $150,000 per year hedge fund job for $90,000 “plus equity” (like, what? 0.05 percent?) then, congratulations, you’re now a $90,000/year programmer. That’s actually quite fine (being a $90k programmer) if you’ve moved to a less expensive area and intend to stay there, and it’s fine if the company is arguably idealistic (e.g. clean energy) because you can probably bounce back to where you were if you’re a good negotiator, but if you took that drop for other unjustifiable reasons, then you’re just a chump and, no, you’re not changing the world by fixing bugs in ad servers.

11. Exercise. It affects your health, your self-confidence, your sex life, your poise and your career. That hour of exercise pays itself off in increased productivity. If you find yourself no longer exercising, you’re throwing down too many hours and you need to garbage-collect your life.

12. Long hours: sometimes okay, usually harmful. The difference between 12% growth and 6% growth is meaningful. Applied to a $60,000 salary over 10 years, one takes you to $107,451 and the other takes you to $186,351. That’s a big difference (not just in salary, but in the level of job that those numbers suggest). When your work is multiplicative in nature and your input/output relationship is truly exponential, work hard. Don’t work long hours on the merely additive stuff (“more of the same”) that doesn’t advance your career or knowledge in a long-standing way. If you’re just doubling up on grunt work so some jerk boss can save money because you’re working two positions and taking one salary, then fuck it. Walk away. It may not feel like the case, but he needs you more than you need him.

13. Recognize core technological trends apart from fluff. Half of the “NoSQL” databases and “big data” technologies that are hot buzzwords won’t be around in 15 years. On the other hand, a thorough working knowledge of linear algebra (and a lack of fear with respect to the topic!) will always suit you well. There’s a lot of nonsense in “data science” but there is some meat to it. Likewise, there’s a lot of puffery and goofiness in “NoSQL” but non-relational databases do have their place. It’s your job (and you get better at this over time, but start making guesses when you’re young) to figure out what are core technological principles that make sense and are worth learning for the long term (e.g. functional programming) and which are just fads. It’s often useful to have fluency in the fads (for example, if you need a job right now) but you shouldn’t spend too much time on them. Buzzword-compliant programmers with weak fundamentals get stuck writing glue code and having to learn new junk when their old junky knowledge goes out of style.

14. Finally, learn as much as you can. It’s hard. It takes work. This is probably redundant with some of the other points, but once you’ve learned enough politics to stay afloat, it’s important to level up technically. And, when you’re out of school and probably not going back, it’s hard. Even the really smart people find it hard to read the cutting-edge papers. (In part, that’s because many papers aren’t well-written, but that’s another topic.) No one is born with the ability to look at complex equations and just intuit what they mean. That stuff took the smartest people in the world hundreds of years to discover and, once discovered, it’s much easier for the rest of us to follow along… but it’s not without difficulty. If you want to be a great programmer, you’ll probably have to study as an adult (with no grades!) harder than 95% of college students (and, maybe, 65% of graduate students) actually do study.

“What do software developers age 30 and over know now that they wish they had known in their 20s?” originally appeared on Quora. You can follow Quora on Twitter, Facebook, and Google+.

This answer has been edited for grammar and clarity.

Image adapted from Family Business and isak55 (Shutterstock). Want to see your work on Lifehacker? Email Andy.