Programming: Doing it more vs. doing it better • Hacker News Board

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

#121

Post by lazyjones » Mon, Apr 08, 2019, 9:06 AM UTC

klichtman wrote: post #115

lazyjones wrote: post #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…

I agree with most of this, but it is more a matter of talking about programming or being an architecture astronaut. You can still write beautiful code and be productive. OpenBSD contains some examples. Of course, as you say one should not talk about writing beautiful code. Just do it.

> You can still write beautiful code and be productive. OpenBSD contains some examples.

Yes, by all means - if you can, do it. But please try to become as productive as John Carmack first before you aspire to write similarly beautiful code.

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

#122

Post by [deleted] » Mon, Apr 08, 2019, 9:08 AM UTC

flukus wrote: post #82

FrankyHollywood wrote: post #71

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. Are you a 10x engineer or are they 0.1x engineers and how do you differentiate the two?

[deleted]

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

#123

Post by black-alert » Mon, Apr 08, 2019, 9:14 AM UTC

lazyjones wrote: post #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…

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive.

Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment.

I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not capable? At this very moment I am working on a total rewrite of an unmanageable codebase that was written by a very 'productive' guy.

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

#124

Post by pyrale » Mon, Apr 08, 2019, 9:16 AM UTC

lazyjones wrote: post #98

rvanmil wrote: post #87

Earlier quoted context omitted.

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.

Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really overrated. I left a huge pile of it in my previous company (amassed over 18 years of programming in Perl) and guess what: it's doing great, more profitable than ever before. The code has been slowly enhanced, some of it refactored. Code quality (as in "beauty", no…

This may be hard to hear depending on your experience, but some companies need to develop code over decades. When the problem is not money but ability to maintain, delivering a poc one month earlier is not always a competitive edge.

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

#125

Post by extra_rice » Mon, Apr 08, 2019, 9:29 AM UTC

lazyjones wrote: post #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…

Just as bad as the people who obsess over "beautiful code" and whatnot are the people who straight out reject the idea, then label those who observe them the "enemy" of this industry.

I think the key here really is mindfulness. Developers read code significantly more than they write them, and one of the primary goals of best practices and clean coding guidelines is to help teams communicate effectively through code. Writing code well is a skill, but that doesn't start and end at taking all the "rules" to heart; that's just the first step. The next is really to recognise that there aren't any rules, but more heuristics based on collective experiences. Software development is not an exact science, and just like the Agile Manifesto, clean coding guidelines only provide framework upon which to build any team's practices: a starting point from which to find what actually works for their project.

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

#126

Post by pyrale » Mon, Apr 08, 2019, 9:33 AM UTC

jfoutz wrote: post #49

mroche wrote: post #44

Earlier quoted context omitted.

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

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…

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

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

#127

Post by radosc » Mon, Apr 08, 2019, 9:37 AM UTC

I do not believe the ceramics story. It is either nice fake to prove the point or what that particular teacher valued was a natural expression rather than perfection. Applying that principle to photography would mean that every one of us is now an artist because we made 1000s of vacation photos and photographers that used just film cameras are bound to produce lower quality work. I've also seen many startups that generated a lot of low-quality code that became a tech debt super fast, and all it needed is someone stopping the line and rethinking the whole thing.

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

#128

Post by muzani » Mon, Apr 08, 2019, 9:40 AM UTC

arethuza wrote: post #118

muzani wrote: post #96

Earlier quoted context omitted.

To an extent, it really isn't hard to be a 10x programmer. Take, for example, the median level 1x programmer. Perhaps a Java programmer working at a large tech corporation on a team of 1000+ in Indonesia or Brazil. That guy isn't visiting HN. That guy doesn't read tech articles at home. He may join a few programmer groups on Reddit or Facebook. But his main concern is that he gets paid and feeds his family. He doesn'…

I suspect a considerable advantage is knowing that there are bound to be existing things to reverse a list and not writing it yourself.

It's quite trivial, yes, but that's why we use it as a benchmark for the 1x programmer. Someone who can get work done, and scales in high numbers.

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

#129

Post by MRD85 » Mon, Apr 08, 2019, 9:42 AM UTC

robaato wrote: post #105

MRD85 wrote: post #70

Earlier quoted context omitted.

Is Ronaldo 10x as likely to get a hat-trick to send his team forward in Champions League when they needed 3-0 to progress? He's not running 10x as far but he is so much better due to little things, such as being in the right spot at the right time. Compare this to programming. A programmer who makes good decisions early on the project will likely save his company a lot of money down the line. A few poor decisions her…

Yes! Though Ronaldo is also known for how hard he trains - he is not relying just on his (massive) talent. Experience gives you exposure to other solutions and can give insights and alternative ways of approaching stuff which as you say can make a huge difference. Sometimes you do just have to grind things out though.

I'm actually arguing that some parts of being a good programmer are things you're born with and that other parts are hard work. I feel some people just understand programming more naturally and if you give that person experience and they work hard then you'll get an amazing programmer at the end.

I could never have been as good as Ronaldo. I could never have even been a professional soccer player, I'm simply not athletic enough.

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

#130

Post by extra_rice » Mon, Apr 08, 2019, 9:44 AM UTC

scarejunba wrote: post #100

rvanmil wrote: post #87

Earlier quoted context omitted.

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.

It actually doesn't matter because you can always rewrite a working product. If you never have a product nothing helps. In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.

> It actually doesn't matter because you can always rewrite a working product.

False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.