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

111–120 of 223 posts

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

#111

Post by arethuza »

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…

"inspiration comes from working on something, not from thinking about it"

Not sure about that - the applications I'm most proud of actually came from extended periods where I was involved in maintaining an existing system, carefully thinking about how it could be improved, so when a chance came I could propose a new application with a well defined list of benefits. Note that by "extended period" I mean a couple of years!

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

#112

Post by averros »

It's very easy: most coders are undisciplined hackers, not engineers. Unfortunately the prevalent macho coder culture (agile, and the rest of that crap along the lines of "move fast break things") positively encourages hacking away without much planning, design, or forethought.

Real engineers spend most of their time learning, thinking, designing, and planning. Coding for them is mostly exercise for fingers, something which needs to be done but ultimately providing no challenge. They learned not only from textbooks but also from their own mistakes, and know what to watch for and where to double-check themselves.

The outcomes are strikingly different: code produced by real engineers usually simply works. No need to babysit it in production. It also solves the real problem rather than "improving" on something which was adequate in the first place (face it: most new software replacing the older one is worse - more bloat, more bugs, harder to use). The real engineer understands that complexity is THE enemy, and breeding (or dragging in) unnecessary complexity is a hallmark of a freaking amateur.

Oh, and academia doesn't teach engineering. Your C.S. degree means shit. Old codgers who remember punching cards and incantations like //GO.SYSIN DD * may be tired of learning the shiny new toys and aren't up to the speed on the latest jargon, but over the years of wrangling code they acquired wisdom, and you'd be very well advised to listen to them.

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

#113

Post by arethuza »

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.

I've heard of plenty (mostly in the future tense) - reality often seems somewhat different.

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

#114

Post by donquichotte »

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…

What I really admire is people who manage to do all of it: start projects, finish them, and produce beautiful code that is simple to reason about.

Whenever I feel bad, sad or just in need on some enlightenment, I go to https://github.com/fogleman and browse Michael's repos.

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

#115

Post by klichtman »

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.

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

#116

Post by momania »

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…

Adding to that: written code has no value, only running code has. The quality of what running code is, or needs to be, depends on the stage of your product and who will be responsible for keeping the code running (either the developer himself or an ops team for instance).

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

#117

Post by Ma8ee »

ravenstine wrote: post #21
revskill wrote: post #7

I use one rule: If it's easy to remove, then it's fine. Because only then, i don't fear refactoring later. So i'll get my goal: Easy refactoring for fun and profit. Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet anyone who actually values replaceability . I don't even mind some repetition of code so long as groups of code aren't tightly-coupled and parts of an application can be easily replaced with rewritten versions. I had a boss once who was dumbfounded that I actually wanted to refactor code. I guess a lot of people want to write things "perfect"…

The main problem with repetion of code is that someone always forgets to change in at least one place when the requirements change.

It's more about having only one place where the logic is defined than anything else.

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

#118

Post by arethuza »

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

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.

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

#119

Post by ArcMex »

FrankyHollywood wrote: post #85
onion2k wrote: post #79

Earlier quoted context omitted.

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…

"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?

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

#120

Post by lazyjones »

Ma8ee wrote: post #110
lazyjones wrote: post #98

Earlier quoted context omitted.

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

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

Kinda obvious what their actual mistake was then...

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

I see a pattern there.

> But of course you also have to be able to be nimble and move fast even after two years and five.

You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase.

I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.

Post reply on HN