Ask HN: What's the difference between 5/10/15 years of exp? | Hacker News Reader

Ask HN: What's the difference between 5/10/15 years of exp?

22 pointsdaryllxd15 comments

I'll soon approach my 5 year anniversary of having a paid programming job. As most of you in the same position would attest, we're basically different people and many times the programmers when we first started. I used to wonder how people get to "x years of experience" and now that I have a few x's around my belt, I realize I still have a lot to learn re: perfecting the craft.

For you guys who've reached bigger milestones just in sheer number of hours of programming, what does it look like? What gets better, not-so-better, and potentially worse?

View on HN

A couple of interesting things - I spend more time reading code now than I used to, less time actually typing out code. I think this is natural with many years of experience.

After this many years you start to see patterns, not design patterns but organizational ones like:

- You really aren't involved with tech decisions. If you are on the IT side it is likely VP's meeting with sales people making decisions. On the product side you are more involved in decision making but if you aren't in a startup, those decisions have likely been made already.

- Tech decisions don't make/break a product. Sure a really bad choice or design of an overall system can have bad impacts but if you want an RDBMS, MySQL vs Postgres? it really won't impact your product enough to make a difference. Picking Oracle might impact your budget a whole lot.

- Learning people's behaviors and personalities and how to interact. This comes with time but can greatly help your career to learn how to communicate and work with people that have diverse ways of working together.

- There are times to craft wonderful code and then there are other times to just get shit done. An example is spending an elapsed 3 months building a solid, extensible way to call an external service, knowing you will have a few of these coming. Then a couple months later, take 2 days to add on a 2nd external service (or Nth). The business goes "its done already? awesome!" Feels good and maintaining that is easy.

Totally agree with all these points. This is my favorite answer so far.

I’d like to emphasize the people aspect point.

It seems like the more experience you gain, the more you realize you’re not in the business of 1s and 0s, you’re actually in the business of people

Want to ditch that oracle DB? You can’t do it with code, you need to influence someone.

Want a requirement to disappear, you need to explain why it can be solved another way.

Want to get better at what you do? Work WITH someone and learn their keyboard shortcuts, design patterns, ways of thinking & command line fu

I've been programming now for 19 years.

The most important thing I've learned is to really, really, really understand the business and problem I'm solving before starting.

I've taken a three processor core, hand tuned assembly language system and rewriten it so that it used only one core and performed 10,000 times better for the customer's metric. This was because I understood the actual problem better than the previous developers.

I've won an online stock trading competition with a bot written in PHP. Again, not because of magical programming skills, but because I understood the problem better than the other competitors.

Miyamoto Musashi, the most famous swordsman in Japan, faced a never ending stream of warriors showing up to his isolated house to fight him for bragging rights. When a warrior showed up and challenged him to a dual, Musashi would go chop down a young tree, remove the branches and fight with that stick/tree instead of a sword. He never lost a fight.

When I first heard this story, I just thought Musashi was doing this to shame his opponents. Swords are all about cutting and being light for speed and maneuverability. A wet piece of wood is an absolutely terrible sword.

I realized today that there was more going on in this story. Japanese swordsmiths didn't know how to make a lot of high quality steel. In the end, most of a Samurai sword was essentially cast iron, and could shatter with single poor blow. Almost the entire Japanese sword art was built around not breaking your sword. But Musashi could ignore all of this and so could attack, defend, and move more efficiently. It's true that a wet piece of wood was a terrible sword, but it could do boatloads of things that a sword could not do.

I used to regard all programming languages as fitting somewhere along a single line of "goodness". Now I realize that the right programming language for project is not about the programming language, but about what best fits the project and the team.

And just like a Real Programmer can write Fortran in any language, you can write clean beautiful code in any language, but this code has to play to the strengths of the language and avoid the language's weaknesses.

I'm 20 years into my career, and 30 years into programming. What consistently gets better are things like breadth and depth of knowledge, problem-solving ability, intuition / heuristics, and the general level or complexity of the technical things I'm able to accomplish successfully. In other words, I've steadily grown personally in terms of programming ability. And that's really wonderful in itself! I love creating things that I wouldn't have known how to even begin 10 years ago.

Basically everything else that's career-related has been all over the place, no consistency at all. Salaries. Roles. The general nature of day-job work. All that has been a random walk, and yes part of the reason is I didn't go all out prioritizing those things. But in general, those things have a component which is the vagaries of other people's perceptions and quirks, or just realities of business. But not everyone's career can be a juggernaut, and I'm a very mediocre career-person.

I was much, much, much happier in my career when I had tons of responsibility and ownership of an obscure product as a junior 20 years ago, than when I found myself slogging through minuscule maintenance duties of huge, household-name, 100-million-user products as a 'senior' 5 or 10 years ago.

The craft itself, though - that only gets better and better, and it's what I care about the most.

What a wonderful answer. I love hearing "programming" as "craft", I can't articulate it yet but it's a combination of science/art/other trades.

Here's my subjective part.

After 5 years, it was fun. 2006. And things were blooming everywhere. I barely knew what things _not_ to read or try.

After 10 years, I began to grasp that tech itself, its mastery, is the worst predictor for a project/company/thing's success/adoption. It's important, but the essence of "it sells" is somewhere else than in "it works, it makes sense and it's beautiful".

After 15 years. I'm full of doubts.

I skimmed enough in the IT world to see different communities/companies that work/think so differently and apart that "the IT world" is fragmented (broken?) to the extent that someone who's a productive expert in their field in some group, will not understand, and not be capable of working in some other group. Although they use the same technology, speak the same language, could work in the same country, for the same customers, but they organize and plan differently, think differently and optimize for different outcomes.

Now for the tech part: it's like when you begin to be more fluent in languages: the more you learn, practice, experiment, play, discuss about, the more you grasp the history, the wider your wold view grows, of how things were, how they are, where they could/should go. Tech as language is a tool. It's the people you do things with that matter in the end.

As, you'll realize, it is as in any other field (from pastries to warfare).

Thank you for answering. At first I was surprised at "someone who's a productive expert in their field in some group, will not understand, and not be capable of working in some other group", but I guess at some level I as a Ruby/JS (and learning Elixir) programmer am drifting apart from the other languages. Like right now I can't visualize myself coding iOS/Android apps just because the tooling is different. I probably could if I really wanted to, but it'd be really hard.

My goal for the next few years is to just keep on mastering the craft as to make it easier to make things or make decisions on things, I hope to continue programming to at least make tools for myself and for other people.

I completely agre re: "its the people you do things with that matter", but I'd like to add "the people you do things for", too. I think everyone (bakers and soldiers included) likes working with nice people and working on something that will be used by other people.

I think the parent was talking less about the differences between programming languages and more about the differences between a programmer working at an early stage startup and a programmer working at a large enterprise company. They are going to go about doing their work in two very different ways. The way they speak, their concerns and the best practices for programming will differ.

My comments are referencing people who like to be hands on, and not people who always wanted manage and coded just because they had to.

As you get more experienced you

1) Get better/faster at recognizing when a project will fail for non technical reasons. Software is one of those fields where somebody who likes coding can feel like every problem is solvable with technology. As you get more experienced, you get better at seeing the non-technology aspects of a problem and when a non-technology aspect is going to support or hinder the success of a project.

2) Developing a desire to deal with non technical aspects of project. Not because you "have to" but because there is the realization that a good/satisfactory solution to a business problem will never occur if you don't take some ownership in the decision making process. This also helps you be more interested in what you are doing because your view of the world is not just a bunch of project documents, tickets, and echo-chamber internal meetings.

After 5 years, I learned how to say "No," to marketing and managers and people who thought something was a good idea, even if they outranked me. Before then, I felt it was my job to say yes to everything and make it happen. (This was also the phase of my career when I once put in a 108-hour work week.) What gets better at this point, is you see problems coming earlier. What gets worse is the disillusionment that comes from realizing not everyone knows what they're talking about.

After 10 years, I learned how to manage people and projects. I don't think it's possible to do this well until you've had at least one excellent boss, one terrible boss, one successful big project, and one failed big project. What gets better is understanding and being able to handle the bigger picture. What gets worse is that you become responsible for things that you don't really have control over.

After 15 years, I learned how to choose the right technologies for a project. I think you begin to get good at this once you've made a few technology decisions and seen how they turn out five or so years later. What gets better is the satisfaction from seeing, understanding, and using long-term patterns in software development. What gets worse is the frustration of seeing people reinventing the wheel or making the same mistakes that you made 15 years earlier.

5 years experience: "What could possibly go wrong?"

10 years experience: "Here's a list of all the things I can think of that could go wrong."

15 years experience: "Here's the thing that could go wrong that matters to you."

I'd love to hear your 20 years experience!

Give me a few more years and I'll get back to you.

I reckon it would be :

20 years experience: "What could possibly go wrong?"

This time a non-rhetorical question, to their team.

The more you learn, the more you realize how little you know. It's a shitty cliche but also totally true. :) What I've learnt is that technology keeps getting better but people stay the same. E.g the frameworks for building web sites are way easier to use than the ones we had ten years ago, but things like dealing with management and conflict resolution stay the same. Scrum and all the modern methods doesn't make one bit of difference.

Reply on news.ycombinator.com