Live data from Hacker News

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

news.ycombinator.com

501–510 of 538 posts

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

#501

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…

All good advice. After about the same amount of time, I am seeing things from the other side -- that of the manager / employer. I have had quite a few employees who came to me and sheepishly told me they were accepting another offer. In every case, my response has been "Congratulations!" and it's sincere because these people are also my friends. I want them to win! As their manager, part of my job is to provide an environment where they can grow their skills. If they grow faster than the business grows, economics tells me what to expect.

If you tell your employer you're leaving for more money and they get angry (assuming you didn't just consume a bunch of money in training), that's a sign that you made the right move.

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

#502
I wish I'd realized that I wouldn't enjoy it anymore and be bored of it after 15 years, and that I invested in a skill that despite paying well does also put me in the line of fire of cardiovascular disease, carpal tunnel, feeling like a zombie from sitting alone in front of a screen all day, and general burnout from death marches and the like.

It took me a long time to get this bored of it though, so if you are similar you should be OK for a long time maybe.

If you get paid well, don't spend to match your income. Save as much as you can. You never know if you'll lose the drive 10 years in.

I know the world of code can be very exciting, but after a lot of work you start to see there is nothing new under the sun and you fix and write the same old things in different forms. And most of the problems you grapple with are man-made, like the idiocy of using languages without static typing voluntarily

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

#503
post #107

Earlier quoted context omitted.

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

If you can't find someone to teach you, then yeah, this would be a good alternative. And so long as you're willing to put significant effort into correctly answering their questions, it should be a good substitute. That said, teaching will not typically help you learn something new, though it will help refine the knowledge you already have. For example, answering "Why is the sky blue" will give the chance to refine y…

> unlikely to guide you into learning about quantum mechanics

True, but that depends on assuming the person teaching is really only interested/aware of an answer that deals with refraction, and that the median mental model most people have isn't close to understanding the mechanics of refraction. I've noticed that the levels of abstractions we employ are all affected by these sorts of questions, perhaps the same question a year later would afford one the chance to unravel a particular layer assuming the layers above it are sufficiently saturated in understanding :D

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

#504
post #229

Earlier quoted context omitted.

> For me, I can't do the front-end stuff Why not? What's stopping you from learning?

I tried many times, I simply doesn't seem to be good at it.

I'm in a similar situation, but don't think of this as an unsolvable problem:

1. Find people who are great at it and be interested in how they do it. I think of this as learning to read good design before you write it. They may be interested in how you do what you do as well. 2. For me, one of the most productive steps was learning the basic mechanics of the bootstrap CSS framework. It did not make me better at designing beautiful web pages, but it did help me make something minimally usable (i.e. not repulsive) that lets me get my ideas roughed out. With a few days of learning, you may be surprised by what you can do. 3. If the best you can do is a cookie cutter design that lets you get started, congratulations! You can get started! What I mean is, I have felt what you are feeling, and there are ways around the problem. Good luck!

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

#505
This advice is situational, but if you find yourself on a team with some experienced, talented, productive programmers, pay attention to what they're doing and learn as much as you can from them. (Things like: what they choose to spend their time on, what trade-offs they make, how they evaluate technologies, when they listen to customers and other stakeholders and when they ignore them.)

Most programmers are short-sighted, selfish, and lazy, so it's unusual to find yourself with a group earnest talented people who have experience. Appreciate it, and take advantage of it while you can.

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

#506

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…

> Titles are B.S. but people listen to developers with "architect" as part of their title.

I would be careful with this advice. It might get you a cushy job and a higher salary at bad companies, but I think it's bad for your career in the long run.

In my experience most "architects" don't do any real work while cooking up a bunch of "best-practices" that sound good in a vacuum but either fail completely or create a big unnecessary mess when it comes to actual implementation.

In my experience, real practitioners who are actually worth paying attention to usually have the title "Lead", "Manager", "Director", or "Principal".

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

#507

Sitting in front of a computer 60+ hours a week is not great for your body. Take the time to understand good ergonomics, buy yourself a great keyboard (like the Kinesis Advantage), and ditch QWERTY.

> Sitting in front of a computer 60+ hours a week is not great for your body.

The next sentence should be: So don't fucking do that. You do your family, your employer, your coworkers, and most importantly yourself no favors by working 60 hours a week in front of a screen. It doesn't matter if you're working for yourself or someone else.

If you think otherwise, you've been brainwashed.

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

#508

Earlier quoted context omitted.

TDD seems to be mentioned in a lot of responses here. I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way. My main thing with TDD right now is - how do I avoid writing tests that are too tightly coupled? I've gotten burned in the past, not even doing TDD, with tests that "know…

Tests and TDD are different things. I view TDD as a workaround for a lack of a REPL. When the code is finished, the tests can be written or polished but writing them before any code is just one variation of testing.

The point of TDD is you can define the behavior before writing the code. ie. you define the expected result:

  def test_sum():
      assert sum(1, 2, 3) == 6
  def test_sum_no_args():
      assert sum() == 0
  def test_sum_negatives():
      assert sum(-1, -2) == -3
etc, and then you write the function.

This means you only do the "REPL" testing once ever for each case - and you can rerun the tests for all future changes. If ever type the same function + args into the REPL more than once - you have done redundant work and are wasting your time.

Likewise if you're in the habit of writing tests after your function is made - it shows you haven't put much thought, which means you haven't done the proper analysis of why the function exists, if the function is really one function or should be two functions, what arguments it can take, what it should return etc.

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

#509
post #36

If I could go back in time and give myself advice it would be: 0) Nothing is too hard to do, no matter how much those doing it might seem like towering titans many levels above you, or how out of your reach it may seem. Nothing is too hard, there are only things that take time, and things that take more time. If you put in the work, those titans will be your peers before you realise it. Of course, you can't do everyt…

Regarding 2, how do you suggest I avoid "spinning my wheels and learning nothing"? Over the last 6 months I've becoming increasingly aware of this problem with me, but I don't know how to fix it.

There's some really great advice here from others. I'll add what I personally needed to learn:

I got comfortable with the small subset of the language I knew, and then used those tools to try to tackle all problems. I eschewed some of the more powerful abstractions because they seemed complicated and unnecessary, and because learning them would take me longer than forging ahead with the tools I already knew.

What I didn't realise, and seems obvious in hindsight, was the time to learn those new tools was an investment. If I knew them, I would not only be able to tackle problems faster than I could with my current tools, I would also be able to tackle far larger problems than were feasible to do with such basic toolset.

I think a possible rule of thumb for when you are being limited in such a way is when you're hitting a ceiling - when there's a complexity point you can reach, but no matter what you do you can't seem to push past it to make bigger/better things, it's time to "level up".

Another possible rule of thumb is if there's some framework or library or technique that others seem to be using and you look at it and think "but that's way more complicated than how I'm doing it!". Maybe it isn't unnecessarily complicated, maybe that extra complexity is the "cover charge" for being able to create larger and more powerful software. (An example: using an MVC framework rather than a bunch of pages with in-line database queries and templating.)

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

#510

Read more into things than you need to given the opportunity. Let's say you need an icon for something, but don't know much about design. Once in a while, try making it on your own. Learn about the pen tool, image formats, etc. Let's say you need a simple SELECT from MySQL. Read more into how they actually work under the covers, in large-scale environments, or how they change for MSSQL / Postgres. Let's say you need…

That's a luxury that many people probably don't have, as most people have to get things done under certain timelines.

If your timelines are so severe that you can't spend five minutes reading the jQuery docs in a day, it might be time to look for a new job.
Post reply on HN