
Ask HN: What's the difference between 5/10/15 years of exp? - daryllxd
I&#x27;ll soon approach my 5 year anniversary of having a paid programming job. As most of you in the same position would attest, we&#x27;re basically different people and many times the programmers when we first started. I used to wonder how people get to &quot;x years of experience&quot; and now that I have a few x&#x27;s around my belt, I realize I still have a lot to learn re: perfecting the craft.<p>For you guys who&#x27;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?
======
matt_s
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.

~~~
w4tson
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

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

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

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

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

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

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

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

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

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

~~~
quickthrower2
I'd love to hear your 20 years experience!

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

~~~
quickthrower2
I reckon it would be :

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

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

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

