4 ms·
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
by jfoutz 8y ago
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.
- mroche 8y ago> 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.
- jfoutz 8y agoi'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.
- lifeisstillgood 8y agoAnd 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)
- tasuki 8y agoDid they really want optimal rendering of boxes? Would a "good enough" rendering of boxes be good enough to achieve whatever business goals?
- deleted 8y ago[deleted]
- pyrale 8y agoNP-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
- Mirioron 8y agoI 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.
- photonios 8y agoI 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.
- jodrellblank 8y agoThis is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-ethnographic-report-on-stratification-and-olympic-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?
- Mirioron 8y agoI think it does apply to programming, but quantitative increases in programming also come from the adoption of new tools, programming paradigms, programming languages etc.