Hacker News Reader

Comment by segmondy | Hacker News Reader

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking around the computer for 25yrs and think I'm a pretty good programmer too. But I have been impressed by some 2 yrs old & 3 yrs old experiences.

View on HN

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.

Reply on news.ycombinator.com