Live data from Hacker News

Programming: Doing it more vs. doing it better

kevinmartinjose.com

81–90 of 223 posts

Re: Programming: Doing it more vs. doing it better

#81
post #61

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…

None of what you just described defines "competitive". A situation is competitive where one's gain is, another's loss. There's no such dynamic at play when programming, except maybe career advancement in big organizations. When I write better code today than I did yesterday, you, my teammate, will be happier, not sadder.

Re: Programming: Doing it more vs. doing it better

#82

Please 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…

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

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

#83
post #36

Earlier 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…

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?

Re: Programming: Doing it more vs. doing it better

#84
People 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 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

#85
post #79

Earlier 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…

Some do, they are curious, and I can teach them a lot. At this very moment I have a junior engineer in my team. He is eager to learn and we do a lot of peer programming which benefits us both (having to explain why choosing some solution is even harder than making it 'by intuition'.

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

#86
post #45

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

Still when I look at my old code and I see the better approaches I could have taken, it makes me think about the fact that my skills have grown

Re: Programming: Doing it more vs. doing it better

#87

People 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…

I think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.

Re: Programming: Doing it more vs. doing it better

#88
post #3

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

I believe it’s almost identical to other fields: review, revise and reflection is the best way to learn. If someone want to improve his code quality, he should continuously review his code, best together with a “better” programmer. After finding the weak spots of his code, he should try to improve them by himself. To do so, he need to learn from good examples, exploring the reason behind through computer literature and experienced coders. After achieving a better version, he should reflect on his practice, how he might come to the solution himself in the first place, why did he choose the first solution and very soon he will start to recognize certain patterns. Regarding technical expertise, he should find where the challenge lies and start studying and practicing to make the knowledge sticks. He should go out of his comfort zone, challenge his ability and make mistakes. That is the only way to mastery.

Re: Programming: Doing it more vs. doing it better

#89

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

Actually, this might exactly be why the industry pays so well.

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

#90
post #8

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

Post reply on HN