Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming: Doing it more vs. doing it better

kevinmartinjose.com

Post reply on HN
Print view View original

151–160 of 223 posts

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

#151

Post by konamicode »

rvanmil wrote: post #87
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 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.

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

Ousterhout uses the term "tactical tornado"s, which I quite like (source: https://twitter.com/johofer/status/1035442341199446017 apologies I don't have a better source handy).

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

#153

Post by remeq »

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 despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams and presentations but I am an engineer, and I like myself and my life and as a result I just want to do and be surrounded by beautiful things so I honestly don't give a shit if some product will not be delivered on time because product managers did include only business requirements and ignored requirement of my engineering team that we need to be able to sign our name under the code we write and be surrounded be beautiful things in our work life. Sorry, but engineers are part of the team, part of the product, if you ignored that at the beginning, it is not our fault.

Also, ability to write beautiful code implies the ability to deliver code much more then vice versa because there is a good chance that someone who actually is capable of writing beautiful code had to get to that level by actually also delivering stuff to production in the past.

So yes, in my world, someone who writes a beautiful code (meaning - correct, performant, maintainable, understandable, clever and so on) is a pretty good candidate to be a role model.

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

#155

Post by mikekchar »

polyterative wrote: post #86
sbov wrote: post #45

Earlier quoted context omitted.

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

Yeah, being able to recognise the garbage I wrote yesterday is an increase in learning. It doesn't necessarily imply that I won't write different garbage today ;-)

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

#156

Post by mpartel »

rvanmil wrote: post #87
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 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.

Moreover, I think there's an 80/20-ish sweet spot. With an attitude of moderation, you can keep a brisk pace and achieve a pretty clean codebase with little extra effort.

It seems best to defer architecting just long enough to see that some component is becoming problematic, but not much longer. Do it too early and you waste effort. Do it too late and you have a much larger mess to clean up.

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

#157

Post by meddlepal »

ArcMex wrote: post #119
FrankyHollywood wrote: post #85

Earlier quoted context omitted.

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…

"hiring the ones I think are eager and willing to learn" Where do you draw the line? How often can a junior approach you before you grow tired of them constantly asking you for help/guidance?

Not the OP, but I give junior engineers a lot of slack. I'm happy to spend a lot of time working with them. And you know if one keeps asking me lots if questions or looking fir guidance that's fine... maybe I need to do a better job explaining or send them off to look at something else that might be a better teaching aide.

The hardest problem with mentoring juniors is that most companies don't recognize the work put in. Still too many places judge purely on your direct work-in to work-out ratio.

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

#158

Post by jstimpfle »

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.

A considerable advantage would be knowing that you shouldn't use a linked list in most scenarios.

The next best would be understanding that there are many different ways to do "linked lists", and it's important to control the choice. Software dependencies have a huge cost.

The next best advantage would be recognizing that if you need to reverse a linked list in practice, you're probably doing it wrong.

Writing a linked list implementation isn't hard. There aren't many things that are hard to implement. What's hard is making good decisions what to implement. No library can help there.

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

#159

Post by cousin_it »

fluffycat wrote: post #148
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 have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time…

Most of the damage I've seen was from people who think they can write beautiful code, but instead write a slow overengineered framework and use clout to force everyone else's code into that framework. Sadly, these people are often smart and experienced. It's more of an attitude problem: they are not content with making a library that will sit at the bottom of the call stack, when they could instead make a framework that sits at the top.

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

#160

Post by adamlett »

soup10 wrote: post #108
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.

In my 20 years of programming i've never heard of a well architectured codebase that is cleanly written, problem free, future proof and a joy to maintain.

Lots of open source projects are well architected and cleanly written[1]. Demanding that they also be problem free, or future proof, is a red herring. I've never heard any proponent of clean code claim that these are side effects of clean code.

[1] Examples I can think of off the top of my head: KHTML/Webkit, Hanami.rb, the Go standard library, sqlite...

Post reply on HN