Ask HN: Bad programmer producing good code • Hacker News Board

Re: Ask HN: Bad programmer producing good code

#21

Post by fedd » Thu, May 13, 2021, 5:19 AM UTC

afarrell wrote: post #18

aristofun wrote: post #16

Good programming is not about writing perfect chunks of code or following best practices. Its about making good design decisions. Period. And this is something you can’t google, only accumulate through experience.

> only accumulate through experience You need both experience and also reflecting on that experience —-- usually in a social process.

You say "usually", so I assume googling forums for similar design decisions and having internal discussion within myself can count, without having a crowd of fellow programmers physically beside you? If you're capable to hold such an internal reflection, then basically you can "google for experience"

Re: Ask HN: Bad programmer producing good code

#22

Post by fedd » Thu, May 13, 2021, 5:37 AM UTC

aristofun wrote: post #16

Good programming is not about writing perfect chunks of code or following best practices. Its about making good design decisions. Period. And this is something you can’t google, only accumulate through experience.

I would agree but I am adding the people that pay for the coders work into this equation ("managers"), and they need function in time. Some (most?) of them seem to consider the design decisions the coders problem. It's in the coders interest to make the code easily expandable, integrable, reusable, readable, to make the coders life easier, to allow them to easily meet the business goals.

Of course every programmer would like to make the best design, but sometimes there's no time for it, and that's when slow/fast/experiensed characteristics come into play

Re: Ask HN: Bad programmer producing good code

#23

Post by fedd » Thu, May 13, 2021, 7:59 AM UTC

bjourne wrote: post #17

Why are they bad if they create good code? :) Personally, I don't think classifying developers as you do works. I think it is very one dimensional.. Like ELO ratings in chess. Good coders are good at everything, bad coders are bad at everything.

Because they miss deadlines. Of course we can characterize the developers differently. I am considering the employer perspective

Re: Ask HN: Bad programmer producing good code

#24

Post by afarrell » Thu, May 13, 2021, 9:34 AM UTC

fedd wrote: post #21

afarrell wrote: post #18

Earlier quoted context omitted.

> only accumulate through experience You need both experience and also reflecting on that experience —-- usually in a social process.

You say "usually", so I assume googling forums for similar design decisions and having internal discussion within myself can count, without having a crowd of fellow programmers physically beside you? If you're capable to hold such an internal reflection, then basically you can "google for experience"

It depends on the quality of the conversation

Re: Ask HN: Bad programmer producing good code

#25

Post by afarrell » Thu, May 13, 2021, 9:40 AM UTC

AnimalMuppet wrote: post #14

fedd wrote: post #5

Earlier quoted context omitted.

Thanks! And what's JPL? Do you mean NASA?

JPL is Jet Propulsion Laboratory in Pasadena, California. They are a part of NASA, but are a distinct sub-entity.

Having done consulting for JPL, they do also need people producing line-of-business apps.

But not every role within JPL needs the same approach.

Re: Ask HN: Bad programmer producing good code

#26

Post by aristofun » Thu, May 13, 2021, 11:47 AM UTC

fedd wrote: post #21

afarrell wrote: post #18

Earlier quoted context omitted.

> only accumulate through experience You need both experience and also reflecting on that experience —-- usually in a social process.

You say "usually", so I assume googling forums for similar design decisions and having internal discussion within myself can count, without having a crowd of fellow programmers physically beside you? If you're capable to hold such an internal reflection, then basically you can "google for experience"

“Internal discussions with myself” can be helpful. But on their own they will never get you very far.

Unless you’re already very experienced and talented to build your own unique path.

Re: Ask HN: Bad programmer producing good code

#27

Post by deeteecee » Thu, May 13, 2021, 4:39 PM UTC

Your explanation was a bit unclear in the beginning but I think I got the point. From my perspective, you're describing two skilled coders (neither bad) but asking about the speed tradeoff, neither being bad.

I try to be that ideal programmer that switches between being both the fast or slow programmer and situationally adapts depending on the climate of the product and the company.

Who would I hire?

The ideal programmer if I can find it but otherwise, I'd just hire a mix of both.

Re: Ask HN: Bad programmer producing good code

#28

Post by sloaken » Thu, May 13, 2021, 7:20 PM UTC

I think it is a multi dimensional problem. You have programmers who are insightful, and those that need insight provided. You have fast and slow. Ones who document their design and code, and those I have a name I do not use in polite company. You have ones who do a great job exploring a customers detailed needs. Others who are good at debugging other peoples stuff. I am sure there are more aspects that you can rate people on. As to which to hire, depends on availability, money, and need. Do not hire a super star if you need a help desk techie.

Re: Ask HN: Bad programmer producing good code

#29

Post by dave_sid » Thu, May 13, 2021, 10:06 PM UTC

To equate slow as bad right off the mark is a bit of an odd premise. I’d rather have a slow surgeon work on me that was meticulous and precise than a fast one that got the job done quickly but left in a few bugs.

It might be that the slow programmer more than makes up for the time by saving hours, days or weeks of tester’s and support team’s time further down the line.

Re: Ask HN: Bad programmer producing good code

#30

Post by enchiridion » Fri, May 14, 2021, 6:48 AM UTC

100011_100001 wrote: post #11

I've met two types of good programmers. Fast programmers that write something dirty first, and iterate it until it's working well. John Carmack is like that. Slow programmers that think about a problem and then write code that covers all scenarios they want to cover. There are advantages to both styles. Both styles have disadvantages as well. Fast programmers sometimes have the tendency to not deal with details, so t…

My favorite way to program is a bit like "applied science". Lots and lots of small quick and dirty experiments to test hypotheses, followed by a slower integration period.