Live data from Hacker News

Programming: Doing it more vs. doing it better

kevinmartinjose.com

131–140 of 223 posts

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

#131
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…

Technical debt isn't an all or nothing thing. It can just slow you down _a bit_. But if you accumulate enough now things that should take an hour take 2 hours. or 4 hours. Or 3 days!

The non-refutable answer is you should spend an adequate amount of time thinking about stuff before doing them. Anecdotally I've found that people are not very good at thinking well while simultaneously coding, so thinking a bit before opening the code browser works pretty well

Being able to distinguish avoidable technical debt and reasonable tradeoffs at the time can save you a hell of a lot of time. And yeah working in messy codebases suck! But more importantly it can cause people to lose time they could spend working on more features and shipping stuff

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

#132
post #110

Earlier quoted context omitted.

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

I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess.

Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.

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

#133

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

Any paradigm can be formalized to the point of perversion. I think that's what the OP meant when they said that the hallmark of that group is how they obsess about standards and processes. The existence of cowboy-style code such as the project you're currently dealing with does not necessarily mean that the "process-over-results" people are in the right. There are many factors to consider, including the structure of the organization you're writing the code for. I don't think it's naive advice to suggest that people spend less time listening to vain role models, instead of actively working on their own skills in order to make better judgements in the future, which brings us back to the point put forward in the article: the way to mastery is through practice.

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

#134
post #8

Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…

While 3 years isn't much from a whole career perspective, I do believe those may be the three most important years, where you learn the most etc; I'm at about 10 years now, and don't feel like my level has significantly improved since then. I mean sure, I'm more experienced now and know more languages etc etc, but it's not like I'm 10x more productive or smart or better than I was 10 years ago.

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

#135

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…

[deleted]

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

#136

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 dislike this way of thinking. Programmer shouldn't be described like:

ability_to_beautiful_code ---V------------ ability_to_deliver

Programmer should be described more like:

ability_to_beautiful_code: 0%---V-----------100%

ability_to_deliver: 0%----------V----100%

And both metrics should have certain threshold for you.

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

#137

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, somethin…

I think labelling a development methodology and macho or not engineering is disingenuous. Any methodology practiced without an engineering mindset looks like that. Agile methodologies practiced by engineers looks like good engineering.

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

#138

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

I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on.

How I take the article, and what I think most in this entire comment thread agree with, are the following principles:

[1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base is to requests for additional features/changes, and how easy it is for new hires to grok it / for you to grok it after a few months have passed working on something else and you've lost familiarity.

[2] Whilst it is important, it is not the only concern. In fact, a shipping product is MORE important. That's not to say that code quality isn't important. Any project that has deplorable code quality even if it ships is in trouble.

[3] So far the most effective strategy for producing code with high quality, is experience (that's subjective; my opinion. But I bet you share it). The best way to get experience is to write lots of code. In fact, writing code of LOW code quality should help MORE: The 8th feature request that comes in that initially sounds like a job of a few hours that turns into a weeklong exercise in frustration with stapled onto the end of that process another week or two chasing bugs - and maybe you learn something about where you went wrong in your code that powered the initial shipping product. This sounds like a much better way to learn these lessons than reading a bunch of blogs and listening to a bunch of presentations theorising about what 'beautiful code' means.

[4] extremes are bad. This more or less is already concluded by #1-#3, though. However, the 'beauty' extremists tend to present, blog, and in general act like they hold all the answers, more than the cowboy extremists do. That's entirely subjective opinion, of course. It's just my experience, and yours may well be different. But _IF_ it is indeed true that you're far more likely to run into a beauty extremist than a cowboy extremist, then it stands to reason programmers who are irritated by extremists of any colour will tend to exaggerate somewhat more on the _other side_ of the beauty extremists.

In the end it's a pendulum, isn't it? A presentation or blog post that comes across as authored by a beauty extremist probably was a capable, 'well adjusted' (in the sense that they would agree that shipping code is at least as important, and experience is very important) – but decided to exaggerate a tad on the beauty side to address some perceived notion that the audience's balance was too far towards the cowboy end of the spectrum.

Enough of those kinds of presentations, and a few are bound to perceive that the pendulum has now swung too far out towards the beauty end, and start exaggerating the value of the cowboy end.

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

#139

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…

Write beautiful code, build productive and correct software, live long and prosper :V

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

#140
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"…

I usually state it as "Optimise Code for Deletion" - the best code is code that can be removed completely because that means it can be rewritten cleanly.
Post reply on HN