Earlier quoted context omitted.
Small percentages matter when the game is competitive. Programming is not competitive. I agree with your argument but I think your analogy is bad.
How on earth is programming not competitive? Coming up with the wrong data model can result in millions of dollars in technical debt, a failure to fully realize a product, or certainly allow a competitor to win out. Bad programmers can structure a product so poorly that it is simply unpleasant to work on, and you won't be able to hire or retain engineers. I think moreso than most careers, a single software engineer i…
Programming: Doing it more vs. doing it better
81–90 of 223 posts
Re: Programming: Doing it more vs. doing it better
#82Please stop thinking there are 10x programmers - or perhaps stop thinking it means 10x better . It is simply 10x more valuable . And that depends on the organisation you work for, the state of the code base and so on. Look at it this way - sports stars are regularly 10x, 100x more valuable to their team management than A.N.Other professional player. Take football (soccer) - Ronaldo is a waaaay better player than I am…
"Please stop thinking there are 10x programmers" I don't really agree, since I consider myself a 10x engineer. I have countless of examples of guys struggling for 2 months on some project. They get stuck, ask for help and I look at it and build it from scratch in a week. It's not I'm typing faster, it's more about choosing the right architecture and libraries. You can save insane amounts of time by making the right d…
Are you a 10x engineer or are they 0.1x engineers and how do you differentiate the two?
Re: Programming: Doing it more vs. doing it better
#83Earlier quoted context omitted.
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 f…
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 te…
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?
Re: Programming: Doing it more vs. doing it better
#84How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it when it's done; inspiration comes from working on something, not from thinking about it) and never even meet their own estimates for how long it'll take them to deliver. They will tell you they are taking so long because they haven't decided yet how to best implement something, but they don't even have a straightforward implementation (there's always one). If they were truly concerned with "the best way", they'd have several solutions implemented already, together with metrics and benchmarks. They haven't, because they're vain impostors and not capable programmers.
Re: Programming: Doing it more vs. doing it better
#85Earlier quoted context omitted.
"Please stop thinking there are 10x programmers" I don't really agree, since I consider myself a 10x engineer. I have countless of examples of guys struggling for 2 months on some project. They get stuck, ask for help and I look at it and build it from scratch in a week. It's not I'm typing faster, it's more about choosing the right architecture and libraries. You can save insane amounts of time by making the right d…
I have countless of examples of guys struggling for 2 months on some project. They get stuck, ask for help and I look at it and build it from scratch in a week. Have you ever wondered why the engineers don't come and ask your advice before they waste a couple of months? I'd much rather be known as an approachable and helpful engineer who juniors can ask for advice, even if it means I'll never be known as a 10X engine…
But the ones who don't are more difficult for me. I think some might be shy or unaware things can go better. The most trouble I have is with the really stuborn who don't want to learn, and think they know it all.
I try to avoid these engineers as much as possible, by hiring the ones I think are eager and willing to learn.
Re: Programming: Doing it more vs. doing it better
#86Earlier quoted context omitted.
In my experience, even programmers are poor judges of good quality of code. Usually the criteria they are using to evaluate quality is: "Can I do what I want to do quickly?" This tends to boil down pretty quickly to "Is the code similar to code I've worked on recently?" Understanding the long term consequences of your actions is pretty tough and the ground keeps shifting under your feet. In that environment, having s…
Yes, I'm always extremely wary of programmers who claim they advance so fast in the art that code they wrote in the last year or two is "garbage". It's more likely that they are just no longer familiar with that old code.
Re: Programming: Doing it more vs. doing it better
#87People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
Re: Programming: Doing it more vs. doing it better
#88I suspect there may be better ways to practice, rather than just doing it more? Some people put effort into memorization of commonly used idioms. Here's another dubious analogy: when learning music, you do need to practice, but playing a song all the way through a bunch of times is a rather inefficient way to practice it.
Re: Programming: Doing it more vs. doing it better
#89Please stop thinking there are 10x programmers - or perhaps stop thinking it means 10x better . It is simply 10x more valuable . And that depends on the organisation you work for, the state of the code base and so on. Look at it this way - sports stars are regularly 10x, 100x more valuable to their team management than A.N.Other professional player. Take football (soccer) - Ronaldo is a waaaay better player than I am…
Small percentages matter when the game is competitive. Programming is not competitive. I agree with your argument but I think your analogy is bad.
Facebook's biggest threat is not dying on its own, but the possibility of future programmers disrupting it. They're fine with paying billions for companies like Instagram and WhatsApp, because of the possibility that these companies would target the same market and hurt their profit margins. They pay very high amounts to poach employees from other large companies as well.
Re: Programming: Doing it more vs. doing it better
#90Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…
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.