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

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

#101

Post by throwawayjava » Mon, Apr 08, 2019, 8:17 AM UTC

skrebbel wrote: post #81

ralusek wrote: post #61

Earlier quoted context omitted.

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.

All of the things mentioned are ways that bad programming can "allow a competitor to win out". Programming is competitive because markets are competitive.

Now, markets aren't always zero-sum. But they are often competitive.

> When I write better code today than I did yesterday, you, my teammate, will be happier, not sadder.

That's also true in football...

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

#102

Post by ensiferum » Mon, Apr 08, 2019, 8:18 AM UTC

For learning, produce as much as possible. For production, produce as little as possible.

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

#103

Post by franciscop » Mon, Apr 08, 2019, 8:18 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…

This, 1000x times. Experience throwing code does a lot in my experience (~7 years programming, 4 professionally). Learn the best practices, and know when they break. Heck, purposely break them and see if/when/how they bite you back!

A very good rule of thumb to recognize the former group is to simply ask "when is this best practice not valid"? This will tell me whether they are consciously proposing it or mindlessly adding complexity. For every single "best practice" I can find you a case where it's not valid, and if you cannot then there's something very wrong.

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

#104

Post by muzani » Mon, Apr 08, 2019, 8:19 AM UTC

I've been facing this in the past year after I started doubling my consulting rates. A part of me wanted to do 2x better work as well, and that just ended up in getting less work and lower quality work done.

Taking my sweet time is definitely not productive either.

I find the balance is to treat it like sketching. Instead of trying to "print" out code, well designed from scratch, from top to bottom. It's better to sketch out the main "lines" of it. It involves a lot of erasing past lines and old code, or even making redundant code at times. You definitely need a lot of scaffolding and placeholders, especially early on.

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

#105

Post by robaato » Mon, Apr 08, 2019, 8:20 AM UTC

MRD85 wrote: post #70

lifeisstillgood wrote: post #53

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…

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.

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

#106

Post by alexgmcm » Mon, Apr 08, 2019, 8:32 AM UTC

The author has another blog post about learning to play the violin and how it taught him the importance of deliberate practice which I feel is probably what he is also trying to get across in this post.

I am experiencing something similar as I continue to study the classical guitar.

I agree that the importance of deliberate practice over just coding and coding really does matter - in my day job I will write many lines of code doing the same string processing etc. (I work in Data Science) but when I am trying to learn I really want to think if I am doing it in a Pythonic way, how I might make the code more reusable and so on.

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

#107

Post by a_imho » Mon, Apr 08, 2019, 8:37 AM UTC

lifeisstillgood wrote: post #53

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…

There are all kinds of programmers, even 0x and negative contribution ones.

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

#108

Post by soup10 » Mon, Apr 08, 2019, 8:40 AM UTC

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.

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.

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

#109

Post by photonios » Mon, Apr 08, 2019, 8:44 AM UTC

derpherpsson wrote: post #62

I spent my first 4 years after the university at a company with very little quality control. We had to talk the bosses into having code reviews. When we began having code reviews my older colleagues never complained about anything - everything went through. That truly was quantity over quality. Oftentimes I had to wade through piece-of-shit code that really made my soul hurt. Really. Bad. But in hindsight that was go…

This mirrors my experience. I spend the first two years of my career working somewhere where pretty much everything went through.

There were some projects in the company lead by developers that were some of the best I ever worked with. They upheld very high standards and the code was some of the best I've seen. Most projects were a total mess and nobody asked questions or reviewed code.

I worked on both type of projects. I think it really helped me. Some projects I just wrote code hours and hours on end without little regard to quality, but later on other projects within the company I was exposed to people and code that was significantly better.

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

#110

Post by Ma8ee » Mon, Apr 08, 2019, 8:45 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…

Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost.

I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered.

I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours.

Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.