While 3 years isn't much from a whole career perspective, I do believe those may be the three most important years, where you learn the most etc; I'm at about 10 years now, and don't feel like my level has significantly improved since then. I mean sure, I'm more experienced now and know more languages etc etc, but it's not like I'm 10x more productive or smart or better than I was 10 years ago.

Being 10× more productive doesn't always feel like being 10× more productive. It can mean spending two days on a project which, seven years ago, you would have spent five days planning out, two days implementing, and eight days debugging; or you would have spent five days planning out, eight days just beginning to implement it the wrong way before someone pointed out that there was a library that already did what you needed, and then two days implementing the actual solution. It can look like half-assing things that need to be half-assed and thoroughly solving things that need to be thoroughly solved, instead of thoroughly solving everything. It can look like writing unit tests for your code that find the stupid bugs right after you write them when it's easy to fix them, instead of spending a bunch of time debugging the whole system when you do an integration test. Conversely, it can look like having less unit tests and therefore less code to change when you need to change something.

In the original "10×" study, some programmers were never able to finish the assignment at all (within the allotted time); probably they either couldn't figure out a workable attack on the problem (like Ron Jeffries on Sudoku: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...) or they wrote their code as cleverly as possible so that debugging it was beyond their ability. The 0.1× programmers in the study were the ones who almost didn't finish in the time that the researchers gave them. Presumably you can think of problems that you know how to solve now that you didn't know how to solve in any finite time seven years ago; presumably also you've learned how to avoid introducing bugs that you would have introduced then, costing you, again, unbounded time to diagnose.

Or maybe not. Maybe I just learn slowly. I've certainly worked with programmers with only a few years of experience who were better than I was; maybe they'd already hit their performance ceilings. But I doubt it.

Is "10x more productive" even the right way to assess ourselves? I may be writing 1.5 times as much code as I was 2 years ago, but that code per line is much more sophisticated and gets a lot more work done, as I've learned more and more libraries and learned more tips/tricks/shortcuts.

I would say that your description is indeed of someone who's "more productive"

> code [...] is much more sophisticated and gets a lot more work done > [familiar with] more and more libraries > I've [...] learned more tips/tricks/shortcuts

I'd even throw something like "code is closer to correct on the first revision" into the productivity column.

I suspect it depends on what you're building. Some problems in computing are drastically harder than others. Crud-like web applications, for example, are a well-trodden path now, but there are many applications of software that are not as straight forward.

Weird, I feel I'm still improving a lot after 15 years but perhaps doing new stuff just keeps challenging what you know.

> Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.

Could you elaborate on that? Maybe with an example of something that would fall into this "hack together in an afternoon" category?

I am still a beginner with less than 5 years of professional experience, but usually there seem to be rather large overhead to putting together new projects/services and getting everything up an running.

I can imagine being faster to proof of concepts in some environments (like a very involved framework - RoR/Django..), but not in others..

Well, one night in 2007 I wrote a 3-D rendering engine in JS http://canonical.org/~kragen/sw/torus and one Friday night in 2013 I wrote a raytracer in C http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra.... It took me until almost 4 AM, at which point I had reflection, color, and Lambertian shading from a tabular ASCII scene file format; a few days later I added procedural textures, a K-V-pair scene file format, specular highlights, and some more textures.

One night last year I wrote http://canonical.org/~kragen/sw/dev3/usql.py, a toy SQL database supporting queries that join up to two tables. I would have implemented more of SQL, but I had set myself a two-hour time limit, and there isn't a parsing engine in the Python standard library.

Last month I wrote a Mandelbrot set renderer in Python, but it was slow, so I rewrote it in Lua using LuaJIT, which made it extremely fast. That took less than an hour, but I subsequently added some more features to it, so it represents maybe a few hours of work now: https://gitlab.com/kragen/bubbleos/blob/master/yeso/mand.lua

(That one will only run on Linux right now, or MacOS with X11, because it uses my GUI library Yeso, which I haven't ported to Quartz or GDI yet. The others are portable.)

aspmisc, dev3, and bubbleos are Git repos you can clone if you like. You may need to append /.git to the URL.

Those were all purely programming exercises, not drawing on frameworks and libraries and whatnot beyond the very basic stuff that comes with the languages in question (and, in the Mandelbrot case, the Yeso library), but of course I've also learned how to use a bunch of tools; I can spin up a new React project with an Express server and get something working in an hour or two, I can hack together a visualization with D3 in minutes, I can spin up a test server on Bithost in a few minutes, I can import stuff into SQLite or LevelDB in a few minutes, I can write a website scraper using Beautiful Soup and urllib2 in half an hour or so, and so on. So if there's something that's easy to do in SQLite, I don't waste my time doing it the hard way in Python, and vice versa.

I think there's enormous value in investing in tools like Docker to reduce the overhead in spinning up a new environment. There's also a lot to be said for improving low-level skills like typing, text editing, and writing and debugging simple code. It allows you to devote more attention, and more uninterrupted attention, to higher-level tasks like system design. But mostly programming more productively is not about writing code faster, although that sure helps; it's about writing less code.

Well, those are indeed impressive given the time you spent on them. I'll get back to you in 20 years to check if I got there.

> But that doesn't mean I spend all my time doing things I can do without thinking

But you do, or at least give the appearance of it:

> Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.

I'm pretty sure that's the core of the idea. What you're doing in an afternoon looks just like being able to code without thinking to someone who would still take a week on it.

I’m a little skeptical of 3 years making an expert, but I’ll stipulate it’s certainly possible for the reasons you mentioned.

I’m basically an old fart who has learned and forgotten a lot of stuff.

It really depends on what you need. I think the 3 year programmer will struggle when moving out of their experience.

The person with decades of practice have faced and failed at a dozen core cs problems. They’ll probably fail, but they can explain their state at any given moment.

The 3 year person will fail or fail and self destruct. It’s bad for everyone involved.

Every once in a while your lottery ticket wins. That has nothing to do with experience. A kid can win and good for them.

I guess my biased opinion is, you get a small advantage with people with our track records.

Newbs can do amazing stuff. Old farts, like us, can also do amazing stuff. You can’t know up front which to pick.

I dunno man, be good to your coworkers. They often end up being amazing.

> The person with decades of practice have faced and failed at a dozen core cs problems. They’ll probably fail, but they can explain their state at any given moment.

This is a pretty critical point in my opinion, but it also depends on the individuals drive. I personally put a distinction between programmer/scripter and computer scientist. One knows how to write code to get stuff done, the other knows some much deeper algorithmic and structural concepts that they can use to explain what they are doing and why they are doing it. And in today’s world it is much easier to be a programmer than a computer scientist.

It may be a broad oversimplification, but that’s my general purpose take on it. Currently, I know I’m a programmer/scripter but it works for what I do in my sysadmin and pipeline work. In the future I plan on revisiting some of the more core concepts to edge back into the CS world, but for now I need to do what I can.

i'm confident i've hit an NP complete problem once. I don't remember the nitty gritty details, but it had something to do with optimal rendering of boxes on a screen. kinda like bin packing. I've been asked a few times, but this one stands out.

usually, my spidey sense kicks in, and i inform my manager what they're asking is hard, like multiple people for years with no guarantee of success hard. Mostly, they cut the feature. rarely they say keep poking at it for a while. I've probably messed that up a few times. But at least once, i felt that the problem was 3sat. i'm not a doctor. i'm not a moron. the problem seemed really hard, and i think i mapped it to 3sat. Perhaps i messed it up, and it wasn't really np-complete. Either way, it's not like i could look up the answer in a book.

nobody wants to pay for original research. Very few people should do original research. I'm not a person that should do original research. I think i saved the company a lot of money by cutting the feature.

And this. Your value to the organisation for recognising a problem, arguing for a low cost solution and having the reputation to be believed is way larger than even a PhD researcher in the area who could have delivered an improved solution.

By the way, packing problems are 70% optimal by putting the largest in first and keep going till the next largest won't fit. (It's like the old fart description - I cannot quote the source but the spider sense remembers the shape of the problem)

NP-hard problems are not always unfeasible. There are pretty good 3-sat solvers out of the box depending on your problem size.

That being said, I don't know the details of your situation

Did they really want optimal rendering of boxes? Would a "good enough" rendering of boxes be good enough to achieve whatever business goals?

I think it depends on how much time they spend programming and what they program.

1. There's a difference between 3 years of experience 4 hours a day 5 days a week and 9 hours a day 7 days a week. That's 20 hours vs 63 hours per week. Furthermore, the 63-hours-per-week person has all of that experience in the last 3 year context. A 20 hours-per-week person would take 9 years to get the same amount of experience in terms of time. Technology changes much more in 9 years than 3.

Now, 9 hours of actual programming per day is very unrealistic. It's also the case that the 9 year person has much more varied experience due to technology changing, so they end up with different skills.

2. If you work on one project/system then after a while what you often deal with is specific to that system. It might not translate well to general programming or other tasks.

I've done programming for at least 9 years, but most of it has been on and off. I would certainly consider somebody with 5 years experience to be better than me in most circumstances.

This is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-...

but it's a counter to the popular idea that "more work" is what it takes to become better at something. Two people in the same group will find that the one who tries more will get better results, but training for more time won't get them to a better group. Instead, qualitative changes are needed - probably many of them - people to work with, ways to think about work, habits of work, adopting the styles of those who are better, etc.

What if it applies to programming also?

I think it does apply to programming, but quantitative increases in programming also come from the adoption of new tools, programming paradigms, programming languages etc.

I think you're using "quantitative increase" to mean "measurable improvement in output", but in the article sense it means simply "more quantity of practise" without changing the kind of practice.

Quantitative would be "I write more lines of code", "I solve more challenge problems", "I write and release more programs", "I code for more minutes each day, more days each week, more weeks in a year", "I suffer and endure more". This might get you further up in your friend group or class ranking, but won't take you to a new level (so claimed).

Quantitative changes would be things you suggest, like "I use different tools", "I approach problem solving in a new way", "I lean towards hard problems instead of retrying easy things", "I work with different people to learn new ideas", "I use languages which let me do more with less code", etc. (so claimed) those can take you to better output, even if your quantity of practice overall decreases.

We always say "practice makes perfect", but "do what winning people do" seems better advice than "do more of what you are doing, when you aren't winning". Phrased like that it's almost tautological - training longer with bad form, won't give you good form.

I agree with this. I know quite a few people who not only write code for work, but they spend massive amounts of their spare time building things or contributing to open source projects.

Although it's not guaranteed, it's likely these kind of people are significantly better than their peers.

Programming is no different than any other discipline. You aren't going to be an expert in anything in only 3 years. Expert physician? Wont even be out of residency yet. Expert car mechanic? No way. Expert troll on hacker news? Maybe.

Expert car mechanic doesn't take 3 yrs. I went from knowing nothing about cars to building my first race car in 2 years in my late teen years and that's without the wealth of knowledge I can find online today. ... and not just jamming a bigger v8 engine, but slamming a turbo on a 4 banger and not blowing up the engine and shaving almost 3 seconds off the stock 1/4 mile times, with limited budget too.

Something I see with most IT folks is that they think they are so special and feel very threatened when other's can learn what they can and faster too. Being an expert in 3 years is possible in most fields, all you need is dedication and deliberate practice.

We are not special, let's get over it. The only crap getting in the way of youngster's today is filtering out the noise since there's too much crap. But once they sort it out, they will move 10x faster than most of us old timers ever did.

> Being an expert in 3 years is possible in most fields, all you need is dedication and deliberate practice.

Do you have anything other than a personal anecdote to back that up?

> But once they sort it out, they will move 10x faster than most of us old timers ever did.

So instead of 36 months, youngsters today can become experts in most fields in 3.6 months? That sounds preposterous. I assume you think that because of the internet and modern tech enabling much faster learning. But then old timers have access to the same tech and knowledge. So why can't they move just as fast?

I think it is possible to be a React.js or Vue.js expert within 3 years (they've only been around for 5 years), but expert knowledge with these libraries also requires some fundamental knowledge of Javascript and the DOM that I believe can be learned in parallel with these libraries.

I think generally you are correct, but these might be the exceptions to the rule.

You could be a vue expert in only a few months if you already know programming and web development. In my experience vue only adds a few things on top of javascript which are incredibly helpful but not complex to understand.

I’ve been involved with hiring and I do part time work as an examiner for CS students, both those who go straight through their education, but also on diploma degrees where people upskill after having worked for a while. Kind of like a masters but at bachelor level.

I’ve seen one or two rockstar developers in my time, but even they, would have had trouble keeping up with the silver foxes I know.

I think young programmers have an easier time picking up X framework because they have more time. That’s not really as valuable as knowing computation though, and I frankly think a lot of the YouTube and MOOCs you praise are to blame for the general lack of CS knowledge among a lot of young programmers. Some of them (the college ones) are great introductionary courses, but the majority of MOOCs are amateurs teaching amateurs.

Maybe that works in software because software is in high demand. I mean, I build a RPA process in a few days by google programming. It certainly works, sure, but I also know that it could have been build a lot smarter and more efficient by someone who knew how. That’s the thing with software though, you can get by if you deliver something that works okish. At least until you have to work in a field like medical software, where you code is quite literally never allowed to fail. Because someone will die if it does. At that point you’ll want the 25 years of experience, every time, and if that’s true for medical software, I don’t see why it wouldn’t be true everywhere.

I call BS. Of course there are extreme outliers, like savants who are composing sonatas at age 3, but programming is a different animal.

Sure, someone with 3 years experience could easily be better in some narrow way, but any programmer worth anything after 30 years experience has forgotten more than a 3 year coder could have possibly learned if he was literally reading white papers all day long for those 3 years and retaining 100% of it. There just isn't enough time in 3 years to cover the breadth of knowledge needed to be "better" than someone decent who has 30 years experience.

It depends on what kind of software you're developing. But ultimately there will be other people to whom the 3 year veteran is a smart newbie.

To adopt a standard set of terminology — while fully acknowledging the limitations of the model — consider the Dreyfus model of skill acquisition.

I've met or worked with programmers with 3 years of experience who demonstrated competence, but never proficiency.

Some programmers have a strong natural intuition, and a competent programmer with a strong natural intuition may appear proficient. It's a tricky distinction, but important to recognize (especially for the programmers themselves and anyone mentoring them).

However, I think most people with 3 years of professional experience programming are advanced beginners reaching competence in a few specific areas.

I can say from knowing Kragen that there are very few mortals who could run circles around him after 3 years of programming. Trying to imagine what they might be like, Christopher Strachey comes to mind -- it seems he impressed Alan Turing with his first program: https://history.computer.org/pioneers/strachey.html

While I wouldn't have described myself as a beginner 3 years into my dev career, I certainly wouldn't have described myself as "expert" either - perhaps "advanced beginner" or "competent" would have been more appropriate.

For me, part of being "expert" is having broad experience, and that takes time. I think I would have used "expert" to describe my abilities after somewhere between 5 and 10 years.

3 years of professional experience (and working on mobile applications as side gigs since 12 after their dad teached them how to do simple scripts with PHP at 8)

I can believe that.

Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful.

Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?

I think OP has provided good context. But I will try to answer the question you _really_ seem to be asking: unfortunately there is no shortcut.

There are things you can do that will, like the author said, give you faster feedback and thus let you get better _if_ you use that feedback. You might write a lot of code and read a lot of code and internalize good patterns. Eventually you will have enough experience and the confidence that comes with it, to take on bigger and bigger challenges. I don’t know what happens after that for I am still in that stage. But I have observed more experienced programmers and one thing they’re very god at is _really reading_ others’ code thoroughly and being able to spot better ways of doing things (which I imagine is through experience) and also thinking a little bit in the future rather than simply the assigned task. e.g. if assigned to create a new system, they won’t just follow the design specs blindly, but will question the design choices rigorously, helping improve the design a lot, and then implement something a tiny bit better than the eventual design.

Maybe I’m making it a bigger deal than it is, but I’ve worked closely with senior engineers and it’s _always_ a fascinating experience. They will question your design and code very very deeply but all of them will be good questions and will help you either improve your design or not add spurious code.

This is very helpful. Your points make me think of the need for immersing in the experience and intently considering not only the 'what' but also the 'why' of actions, as well as alternative approaches to solve problems.

It also makes me think of the importance of stepping back, questioning the scope of "design choices" available, and anticipating things other "than simply the assigned task", possibly for some long-term aim, as you write. This is neat, thanks.

For me the biggest learning experience was building a system for a company, (a moderately complex CRUD app at the end of the day) and maintaining it for 4+ years.

If I had to go back and modify the code, if I didn't understand it straight away then it was usually worth refactoring. It was my own code so I had no one else to blame if it was crap.

That probably has expanded into reading others code and seeing better ways of doing things like you say.

No, they didn't do the modern day ceremonies around programming such as TDD. What they did was code a lot. Code a lot of different things, knew where to draw the line and "finish" up their projects. Maybe out of their many projects, they really took one or two all the way and polished, but most were fast, done and the lessons learned. ... They also stayed deep in the language and didn't rely much on frameworks & libraries.

Here's a sample of things you can do to vary your programming knowledge fast.

Learn multiple languages C, asm, forth, lisp, prolog, any OOP

Code a card game, blackjack, cribbage, poker Code a board game, checkers Code a puzzle game, tetris Code an adventure game (text) Code your own text editor Code your own interpreter (BASIC or your own language) Code a network server & client (not REST, socket programming & threads) Code a basic CRUD app

They are deeply curious about a lot of things and soak up as much as they can, that's all I can say.

I like your notes on varying programming languages yet staying deep in one. I think this is turning into a consensus among the folks here who've been kindly offering advice.

And will consider this: "Maybe out of their many projects, they really took one or two all the way and polished, but most were fast, done and the lessons learned. ... They also stayed deep in the language and didn't rely much on frameworks & libraries."

This is also useful: "Code your own text editor Code your own interpreter". I find these types of things intrinsically motivating, thank you.

These people have their experience in one field for all these years, therefore they know a lot about it. They also work with limited number of technologies, which makes them good in them.

So, basically, they are good in certain tasks, so as long as they do these tasks you won't notice their lack of experience in other stuff.

> any skills/traits in those people

There are no patterns, to be honest, otherwise everybody would do it. There are best practices (some of them are debatable, like mentioned TDD) which you can read and try to incorporate, but don't treat them as dogmas.

Solve challenging tasks, reflect on your code, try different stuff, actively talk and discuss solutions with more experienced engineers, and you'll learn (relatively) quickly.

Very useful. Good notes on solving, reflecting, and actively talking.

And that point you write: "They also work with limited number of technologies, which makes them good in them. So, basically, they are good in certain tasks". An interesting observation, thank you.

> There are people programming at 3 yrs that are experts and will run circles around you and your 38 years.

Yeah, there are; I've had the privilege of working with some of them. Probably they're even better now than they were then, though.