Live data from Hacker News

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

news.ycombinator.com

101–110 of 538 posts

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

#101

I have been developing professionally for 20 years and I'm in my early 40s. What I've learned: * Salary compression is real: most companies are not going to keep giving you raises to match what the market would give you for your skills. They would rather you leave and take all of the institutional knowledge with you than pay you the amount you could get elsewhere. Even if that means hiring someone else at market valu…

Where "recruiter" = "freelance recruitment agent": there are an awful lot of bad ones, so if you find a good one hang onto them. They're less likely to be blacklisted by employers.

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

#102
Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost.

Solve real world​ problems. Doing elegant things is very difficult because the real world is much more convoluted than theory.

Do a few things in depth. Don't jump at the latest thing every few months.

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

#103

build it to work first, then refactor the code to be pleasant. You often learn so much about the problem while getting even a rudimentary spaghetti code implementation working that you couldn't possibly have designed a comprehensive set of objects/interfaces up front, so get it running first, take what you learned about the problem and update the code to be readable and well-designed.

Yeah. Do spike but don't show it to management before minimal cleanup refactoring! They may think it is done.

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

#104

Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost. Solve real world​ problems. Doing elegant things is very difficult because the real world is much more convoluted than theory. Do a few things in depth. Don't jump at the latest thing every few months.

> Work somewhere where software is the main product and not just a cost center. > Doing elegant things is very difficult...

These are great! I would also add: be certain that the organization shares your values. If you really care about code quality, elegant solutions, etc, you'll have a frustrating time working at a company that doesn't prioritize those things.

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

#105
5 things:

1. That statistics and metrics collection is incredibly important even if you only ever use it via libraries.

2. That code performance doesn't matter if the code is incorrect or insecure. So much of my life in industry has been tainted with an influence to conform to the cultural norm of "fast is best." This influence and culture is one of the most counterproductive parts of our industry.

3. The industry is actually full of great people, but those people avoid most of the media hubs that projects have access to because a tiny slice of terrible people dominate discourse. These assholes set the tone for the entire industry, and should be ostracized and punished. It's not everyone, it's a thin coating of hate.

4. Corollary to 2 and 3, I wish I learned to ask for help earlier in my career. I wish I could go back to my younger self and take the chip I'd acquired working with government contractors.

5. Corollary to 4, I wish I realized that I should be reading academic papers and that the people writing them weren't wasting time. Much of what's considered modern state of the art is in fact 5-10 year old work out of universities and MSR.

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

#106

That shipping stable software that works and meets requirements is what people really want. In other words, what the non-tech business people want, or your customers want, is software that fixes their problems, makes their lives easier or makes them more money. It's easy for us programmers to become fixated on using a newer JS framework, a slightly tighter Java loop or the latest cool language. Took me a few years to…

I strongly agree. However, there are special cases where you are exposed to a new technology which enables new outcomes. I was fortunate enough to blunder into using the Web in '92 and Java in early '95 and they were tools where the "how" did matter quite a lot... [NB I haven't touched Java in a dozen years or so]

Also there are differences in further employment perspectives.

I mean if you have a problem to solve and you have a choice to use some old tech that you already know, but it is going out fashion, and some new one, then the choice of the newer one improves your employability in the future. For example, I guess in 2000 there was not that much people with 5 years of experience of using Java in production, but those who had it, had to have pretty good chances to easily find decent job.

Of course there is a risk to bet on wrong technology, but at least you keep learning instead of just using ageing tools and becoming more and more disconnected from the current state of the art. It can be as scary as this https://news.ycombinator.com/item?id=11886753, a story of a guy who successfully solved business problems and delivered products with jQuery for a long time and then eventually found that he was out of demand because businesses started looking for people with experience of using React and he didn't have it.

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

#107

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 stari…

> 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.

Maybe. I think the other side is find someone smarter than you, but less experienced, and teach them.

You learn much more from teaching than being taught.

If you're at loss of finding smart adults, find some children ; they're probably all smarter than you, in the sense of finding good questions (which is much more interesting than finding good answers; finding answers is just work, finding great questions require inspiration. A perfectly good example of a good question is: "why is the sky blue?").

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

#108
A reliable build pipeline is your most valuable asset. It could even be argued that what you build should be determined by whether your build pipeline can build it. Tinker with the pipeline at your peril. Be very careful what you do with it. Only when you are sure it works, submit new capabilities to it.

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

#109

Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost. Solve real world​ problems. Doing elegant things is very difficult because the real world is much more convoluted than theory. Do a few things in depth. Don't jump at the latest thing every few months.

Couldn't agree more.

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

#110

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 stari…

> 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.

On that note, I was surprised to see this comment when looking through the source code of the now-venerable program traceroute -

"Don't use this as a coding example. I was trying to find a routing problem and this code sort-of popped out after 48 hours without sleep. I was amazed it ever compiled, much less ran. [...] Van Jacobson (van@ee.lbl.gov) Tue Dec 20 03:50:13 PST 1988"

Post reply on HN