I'm not that old, only a decade and a half of experience, but some things I've been explicitly told:

• it's not enough to be a good programmer, all the immigrants from india willing to do your job for half the cost are good enough programmers. You need to develop your business accumen and your software architecture knowledge.
• That new API/framework whatever is 99% the same as the others, they don't make you better software.
• As hard as it is, be friends with Sales
• Most programming languages are the same to a certain level. It's just syntax, learn the paradigms and you can be a good developer in every language you see, so long as you know the paradigms the language supports

For what it's worth, these are mine:

• Don't be afraid to speak out with ideas or criticisms when you're a junior. You're probably wrong but people will notice you and see you learning etc. Obviously when you're wrong, accept it and then go find out why. Ask your senior / lead why you're wrong, even if you think you know why, you might be surprised
• Ask the duck, dear god, please ask the duck first.
• Stay up to date, but at some point you see that all new developments are mostly minor incremental advances. When someone asks "omg, you haven't heard of X", it'll take you 3 mins on google to know more about it than they do (because you're up to date on all the underlying info). One example is a Java developer I was chatting with, and I mentioned YAML, he'd never heard of it. 3 minutes later he was telling me the inherit problems with it.

These aren't part of a overarching philosophy, but they come easily to mind:

1. Learn vi or Emacs. Actually, learn a little vi no matter what, because it's the only decent editor you're guaranteed to have on non-Windows machines.

2. Ask dumb questions.

3. If you're stuck working on stuff you're not crazy about, spend a few evenings working on something cool that is useful to the company. Most shops will give you a shot at building it out.

4. Get good at estimating, communicating, and sourcing IP and tools.

5. Work at a startup (or start one!) before having kids or developing other attachments makes your risk tolerance too high. Paul Graham is right about the experience multiplier you get at a startup.

6. HR is not your friend.

7. Profile your code. So much learnings.

Save money and learn to invest - which is harder than it looks - because sooner than you think you will be an old guy with out of date skills.

A question to the older guys: When you get older, does your passion for developing decreases?

No so old but I have some baggage.

Aside from what other people already said, if some technology feels magical, don't run from it, and don't just try to wing in superstitious ways (it works if I do this but I have no clue why). With enough dedication, and curiosity most likely you could start understanding it and that would probably make you a better professional.

If you want to keep growing in the field you have to keep learning new things, even technologies that are not directly related to what you do, many many times those new ideas can be useful in other things.

There is no problem in being a specialist in something, but learning improves the way you think, widens your toolset. As a side note it's a matter of just looking into history to realize that many "discoveries" are just rehashed ideas, just applied to different things.

A question to the older guys: What is your thought about the "Garbage in, is Garbage out"?

RTFM
No, seriously. READ IT! Don't feed yourselves exclusively on example snippets.

When I was young I used to solve problems by writing code. When I got older I preferred to solve problems by not writing code. Reuse is your friend. Fully understand the libraries available to you and make the most of them. Understand the real costs of new code - the debugging, the documentation, the maintenance, the potential surprises. Use the tools you already have.

Write code that protects itself. In the C language there is an assert() function that lets you sanity-check things as you go along, and other languages have a similar feature. These checks get compiled out when you hand a flag to the compiler, so they won't cause a performance hit. I used to put millions of them in all my internal interfaces (these are the places you'll catch most of your bugs). Sanity-check the arguments, the pointers, the counters, the terminators on your strings, the link lists. Often you'll make a dumb mistake over in one corner of the code, and then trip an assert somewhere else the first time you try to run it, and the debugger shows you the whole story. It saves a lot of time and grief.

If you are not using an syntax-sensitive editor, you are either already very good at what you do, or foolishly handicapping yourself. Be honest about this.

If you are not using version-control software to keep track of your changes and your build configurations, spank yourself and go to bed without supper. You're very, very bad.

Write code so humans can read it. Optimize only the stuff you have to, which mostly means your architecture and your design. Few modules really need to be optimized, and when they do, you'll know.

Don't get stuck maintaining code in a dying language. Change jobs if you have to, do what it takes to to keep your skills fresh. Nothing is sadder than a middle-aged guy with out-of-date skills looking for his next job.

Now and again, look around the office and ask yourself who you most want to be like in five years. If you can answer that question, do the work to become that guy. If you can't, start looking for your next gig.

A question to the older guys: Is there a natural selection that weeds out bad developers as you get older?

• Spend more time coding and less time networking. You have time for Voat? You aren't maximizing your programming potential.
• No matter the language, no matter the project, the more you code the more you learn and the better you become as a result.
• Be very accepting of qualified opinions. In other words, don't let your project be guided by jerk offs on Twitter who've never worked on a project of note.
• The famous programmers you idolize: Most of them are not as great as you think, and some of them are downright despicable human beings. I'm not naming names.
• No matter what anyone else says about your project, language, technique, just keep coding.
• Your program sucks for the same reasons all software sucks. Commit long term to improving your code, and your program may come to suck less than others.

And me? I've never worked on a project of note. Despite programming since 1983, learning a dozen languages, and going back to school in the 2000s, I never got a programming job or found success. Mostly because I didn't know then the things I just told you above.

Good luck and thanks for reading my rant.

Don't be proud of how clever you are in your code. Clever code is often the most fragile code and a nightmare for others to maintain. Learn to manipulate the feature, bug or requirement so you can code it simply rather than making some clever abomination that saved a few lines of code. Also learn the fundamentals of software architecture so you can reduce or eliminate dependencies on frameworks to make things happen. Always analyze and think before you code.