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

I followed the call of an employee with 10yrs more experience than I have and he proposed we move our infrastructure towards docker containers for easier deployment / management.

Generally containerization of our app was a good step at this point, but we made the mistake to also put redis / postgresql into docker, which obviously is an stupid idea if you're trying to scale things. On top of that, docker networking was a science on itself, and we didn't use any proper automation tools.

Docker containers kept running out of disk space / memory and it took a lot of effort to figure out where to place apps. In the end we ended up in the same situation as before, that some containers were on dedicated machines and the rest had a kind of hard limit on the max. # of instances per machine.

Our deployment process went from taking 2 minutes to ~10-15 minutes because of docker registry and extensive jenkins build scripts. It also needed lots of network bandwith to be transferred to the actual hosts. We had to regularly remove unused images because the docker registry or our docker hosts ran out of disk space.

Finally we changed our deployment process to incorporate docker hub because it was advertised as the premium docker building service. We paid for that service, but it took between 20 and 40 minutes to build our images. This was unacceptable for our use case because we needed to fix bugs near-instantly. Customer support from docker the company and their unresponsiveness towards our latency problems was another problem.

After the engineer in question left towards a very well-known european music streaming startup, we finally ditched docker and moved everything to AWS beanstalk. It does proper version management, config management, auto scaling and can be defined with a simple json file and some some straightforward cli tools.

You're going to read your code 100x more than you're going to write it. Optimize the code you write for reading.

Your code will be in production either much longer or much shorter than you think it will. The 5 lines of code you spend three days perfecting will be replaced in a week, and that one-line 3am hack will be out there for ten years.

A good walk around the block will help you solve a problem faster than staring at code.

Find someone smarter than you and learn from them. The corollary is if you're the smartest person in your area, you're more likely to stop learning.

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

You will derive more long-term benefit from finding an answer yourself than finding that answer on Stack Overflow, at the cost of time. When time matters, at least try and understand why the Stack Overflow answer is right.

Don't be afraid to question a decision you don't understand, or don't like. At best, you'll get either your mind or the decision changed. At worst, you will learn something about your co-workers.

There's never enough money, time, or domain specific knowledge.

Office politics matter, regardless of how much you wish they didn't.

One more thing... while it is good to switch it up every few years - don't do it too often. When your 5 years out of school, and have 2 jobs of 2.5 years each, it's perfectly acceptable. When you are 15 years out of school, and have been with six different companies, in the same city, and they all have the same responsibilities, it doesn't look that great.

I was hired into my first cubicle around 1999, doing asp classic web dev. I've gone off on some side tangents here and there, but have more or less been building web apps using MS technologies to this day.

It's not them, it's you. Any problem you have is your problem and the solution is something you're going to have to do. Be it a compiler bug, deadlines blown through by partying interns, shoddy code written by contractors, insane deadlines imposed by self righteous VPs, etc. All of these problems are caused by you. You took these jobs. You fed the mice cookies. You didn't say no. You didn't spruce up your resume and blog on LinkedIn. You are the only person that is ever going to try to help yourself, so if you don't like what's going on, there is no where to look but inwards.

Every line of code is a devil, waiting to bait you. Every curious syntax, handy shortcut, convenient convention that only you and the few who read the docs will know about, is bait in a trap. It's better to write less code, simpler code, and code that eschews advanced features in favor of being obvious. Imagine yourself having not slept for 24hrs, being drunk, with a CRT monitor at 640x480, typing on a keyboard covered in elmer's gluge, and then write code you could debug that way.

In about 20yrs on the job I don't think I've ever seen a situation that truly called for more performance. I've seen bad processes that were too slow because they were bad, and I've seen inner loops that needed to be unrolled, and I've seen (written) code that was hitting the database in ways that were totally bonkers. Slowness is mostly about bad decisions earlier up in the decision tree. Unless you're writing trading algorithms or video games, you likely have no use for your program to run any faster.

Prefer bad working code over good code that still isn't producing any useful output.

Your choice and relationship with your spouse will have more of an impact on your career and long term happiness than anything in technology. Take care of home first. Then go to work.

You are going to need a few key side skills: public speaking, making small talk at parties, presenting to people above your pay grade, technical writing, etc. These are key differentiators that are more valuable than being able to write more or better code.

When you're feeling burned out, take a day or two off. If you aren't able to, or you do and it still doesn't help, then something deeper is wrong.

Cutting down on the drama of deploying and maintaining production software is just as important, maybe more, than fun during development. Yeah some languages are excrutiating to code in, but they run smooth, and that's worth a lot. And some languages are a lot of fun in the editor but a bitch on the server, avoid those.

Steal ruthlessly. Anybody who is doing anything cooler or better or faster than you, buy them lunch and ask them what they're up to. You don't have to follow in their footsteps, necessarily. But at least being familiar with other ways of accomplishing things really helps broaden your horizons when brainstorming or thinking about problems.

It's okay to take long breaks to do something else. You can always come back.

Make friends and stay connected. Your rolodex is your escape hatch if things get ugly.

You are a business. The product is yourself. You're the founder, CEO, president, etc. When you answer the phone, do so as the CEO of You, Inc. Ask yourself: if I was a business person, and one of my employees was representing my business to my customers the way I am doing now, would I fire that person, or promote them?

Knowing which rules are actually enforced and which rules are just for keeping chumps corralled can really help your navigate a bureaucracy.

Making friends with people who make and enforce rules can get you out of following a lot of those rules, or just provide back doors into the processes.

You pick your boss and at work that is likely one of the most important decisions you'll make. If you don't like them, find a new one.

You nailed it! Perfect.