Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

This is the best advice here. Mostly around

>They don't have any loyalty to you.

Companies preach "family" and "loyalty". DO NOT BUY INTO THIS MENTALITY. They're not going to hesitate to fire you if it means they can maintain their bottom line.

and

>Even if you don't want to become a manager, when the time is right and you have the right skill set, demand a title with "architect" or equivalent in it. Titles are B.S. but people listen to developers with "architect" as part of their title. I insisted on the title and now I'm being recruited for much higher salaries even though I had the same responsibilities as a "senior".

Title's probably aren't going to be given without some other political reasoning. They have to be claimed. Same goes for "Director", "Head of", and "VP" titles. Titles are rarely assigned based on merit, so stop trying to earn them.

Additionally, I'd like to add the following advice:

Don't take compensation as equity these days. It's the same as taking your salary based on lottery tickets. Especially heed this advice for "nothing" equity offers of ~1% of common stock. It takes a really large exit for that 1% to turn into something meaningful for you. AND that's assuming there are scraps left over for the common stock holders.

If you're self taught, get a degree as soon as you can, even if you take night classes over an extended period. No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

If you're not a founder, NEVER take equity in leu of salary. If they offer a competitive salary and equity, that's a significant plus, but equity as a portion of your compensation value is essentially a scam. if the company goes under or you're let go before the cliff (which is usually two years or more, a lifetime in this industry), all that money disappears: not true of salary. If a founder or officer alludes to houses, cars or other riches as a pitch to join their company run. Seriously.

Take the time to understand systems and infrastructure. Not every dev needs to be a kubernetes expert, but the big difference between a code monkey and a code assassin is that the assassin can deploy their own code to production if necessary. If you're a web dev and you can't configure nginx or apache, you have a gaping hole in your skillset.

Launching off the last point: learn to be competent with linux. Linux is the preeminent environment of the software world and it pays huge career dividends to be able to script, configure, compile, install and maintain linux software and systems.

RTFM. This is a big one. Don't skim. Relax and dedicate some time to a thorough understanding of details. You can save yourself an immense amount of time when working with a new library/framework/language if you actually read the manuals and understand what your tools are capable of, otherwise, you end up wasting tons of time brute forcing your way into a crude solution that may have been trivially and correctly solved by utilizing the tool's strengths and features where appropriate.

> What the customer needs is rarely what they say they want.

I'd like to extend this to include designers, non-technical cofounders, and non-technical colleagues.

I had a situation just recently where I built out a new front end interface for a new feature I had just built. There was a particular work flow that I had carefully laid out for a specific task that involved rearranging items in a list. Not having a 100% explicit spec, I was free to improvise within constraints.

So, I built this interface out and tested it.I then handed it over to my colleague who is responsible for green lighting new features and such. Well, my colleague decided that the interface should be completely rebuilt for better usability. That's fine. No problem, that's my job. Though, it would have been nice to have a spec up front so I don't have to throw away hours of work.

So, I convince my colleague to write out a very detailed user story so I can make the interface just how they want it. I get the user story and I completely rebuild the interface. I then hand it over to the same colleague and they say that the interface still needs improvement. I'm confused at this point because I followed the spec to the tee. They explain how they want to improve the interface and their explanation sounds almost exactly like what I had implemented the first time! Needless to say, I was a bit ticked off. That said, it's best not to make a big deal out of it as I am getting paid for my work and I don't want to make my colleague defensive.

Luckily, I had the old version in version control on another branch so I was able to pull it back into the working branch and make some minor tweaks.

Moral of the story: Non-technical people don't really know how to express what they want to a technical professional. I'm in no way implying that non-technical people are inferior. They just don't understand the job of a technical person and all of it's implementation details. The same issue applies to fields other than software development. For instance, it's difficult to express how you want a contractor to build something if you have no experience building something.

You will also run into people that have no idea how to do your job and have no idea how to express what they want, but also insist that your job is easy. These people are idiots. You just have to humor them until they inevitably fail at their own jobs and go away.

That's just one tool to avoid strain and it's not for everyone.

The important thing is to remember that strain creeps up on you slowly, then hits hard. You can get away with bad habits for years, but left unchecked one day you'll find you can't do anything, it all hurts too much.

Don't push yourself. If you find yourself aching a little, address the problem rather than pushing through it. I know several people that were knocked out of commission for the better part of a year after a few decades of casual neglect.

This is like reading advice from an alternate reality. Almost all the VPs, senior managers, principals, etc. that I've encountered in my career are poorly-dressed nerds, not ring-wearing, macho douchebags. If you are a politician in software, you will eventually get found out by someone competent and get the boot. The only way you can succeed as a politicking fraud is to hop jobs every-time the people around realize you can't actually do anything, or ride sinking ships.

Even if some completely broken companies, this was good advice, it would be a recipe for a pretty pathetic existence.