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

191–200 of 223 posts

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

#191

Post by ravenstine »

Wildgoose wrote: post #140
ravenstine wrote: post #21

Earlier quoted context omitted.

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.

I love that. :)

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

#192

Post by owenversteeg »

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 was going to comment on $15k being pretty far off, but apparently for a mediocre programmer in Brazil it's not that uncommon. Decent ones, though, can get far better salaries from what I've found. I've always thought of starting an outsourcing agency hiring programmers from underpaid countries, but the reality is that the good ones aren't as underpaid as you'd think, and the whole process is incredibly complicated, even if you have substantial ties+citizenship+connections in both the US and the country you're outsourcing to.

Also, if he gets a 10% raise every year, he'll be making 73x as much (21x as much with 3% inflation) at the end of a 45 year career. If he starts out at $15k, he'll end up at $1.1MM/year, $315k in 2019 dollars assuming a hefty 3% inflation. Not half bad for someone who doesn't care about doing his work well and can't google a sorting algorithm!

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

#193

Post by jayjader »

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?

> How often can a junior approach you before you grow tired of them constantly asking you for help/guidance?

Personally, it would depend on if they're learning from my guidance or not: if they keep coming back with the same problems I'd get frustrated that they (seemingly) weren't attempting to learn or improve. On the other hand, it they usually come to me with new problems they've encountered and gotten stuck on, I don't expect it would bother me nearly as much.

Of course, IRL it'll probably be somewhere in between.

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

#194

Post by Bekwnn »

externalreality wrote: post #46
osrec wrote: post #41

Earlier quoted context omitted.

OOP attempts to map to real objects, (and sometimes not so real objects). I know it's hated by functional purists, but it really does make it easier to think through problems. I personally don't hate it.

Functional purists are the only one's who hate it. OOP by its very nature encourages developers to make bold abstractions prematurely (where prematurely is interchangeable with unnecessarily) and subjectively. Mean while the procedural programmer (Golang) has already finished the segment of the program having written one big function. If a piece of that big function is needed elsewhere she factors it out. Most of her…

I'm more in the data oriented design camp where you use objects all the time, but also hate what seems to be flagrant abuse of OOP by many programmers.

Casey Muratori had a good quote with regards to it (paraphrased): "Having objects in your code is fine, it's natural. We've been doing it since before OOP was a thing. It's the whole phrase 'object-oriented' that's the problem. You're orienting your thinking around objects, not functions. It's the orientation that's bad about it, not whether you wind up with an object."

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

#195

Post by Ntrails »

remeq wrote: post #188
Ntrails wrote: post #187

Earlier quoted context omitted.

> meaning - correct, performant, maintainable, understandable, clever and so on My favourite part of this is how often these criteria are essentially at odds. - Understandable *and* performant? - Clever *and* maintainable? But, you know, I'm also bad at all this so maybe it's just me :p

Yeah, I didn't really mean everything at once, I just wanted to make clear that "the beautiful" can be disaggregated into some engineering qualities.

Yeah, it was more a comment on the natural compromises that come about from trying to be all of the best things in your code. Perfect being enemy of good etc.

Agree entirely that they're all things that contribute to "good"

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

#196

Post by bbbobbb »

kragen wrote: 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…

> Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.

Could you elaborate on that? Maybe with an example of something that would fall into this "hack together in an afternoon" category?

I am still a beginner with less than 5 years of professional experience, but usually there seem to be rather large overhead to putting together new projects/services and getting everything up an running.

I can imagine being faster to proof of concepts in some environments (like a very involved framework - RoR/Django..), but not in others..

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

#197

Post by passivepinetree »

jondubois wrote: post #66

I've been coding intensively for more than half of my life from a young age - I'm approaching 16 years of experience now. Also, I've been doing it quite intensively (I was writing games when I was still in school before studying software engineering at university, then I worked for 14 different companies; some startups and some corporations in about 10 different industries. I've completed projects in at least 7 diffe…

Can you elaborate on your opinions about frameworks? What are some tech stacks that are mediocre, and why are they mediocre? What makes an alternative better?

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

#198

Post by lazyjones »

lm28469 wrote: post #144
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…

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line. How many times have I seen developers push some "good enough" code that they didn't discuss with anyone because it looks good to have XXX…

> People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line.

Wildly exaggerated, but I'll bite: it's still better to save 5 hours while you are bleeding money (before your product works) and spend 1 week to improve the "beauty" of your code while it's already paying your salary.

> “Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth

That's a fine attitude for someone who wants to teach CS or explore programming as a hobby. For professionals, programs need to execute correctly and go into production ASAP. Emotional and mental cost to the programmer is of less importance.

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

#199

Post by gumby »

This is why programming (as a profession) is engineering and is different computer science (as it is today -- when I was a student 40 years ago it was still turning into a "science"). Engineering as a discipline is at its heart balancing tradeoffs of factors like time, cost, weight, strength, efficiency etc. There is no single pole on any of these axes that can dominate, even though for illustrative purposes it's generally useful to do so when writing an essay.

(Also three years is a really short time, though the author seems to be using that time well in order to learn and meta-learn).

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

#200

Post by scriptkiddy »

remeq wrote: post #153
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…

> meaning - correct, performant, maintainable, understandable, clever and so on

The only little nit-pick I have here is the use of the word "clever". Maybe you and I define clever differently in a software engineering context, but to me, "clever" is a dirty word in programming.

For me, "clever" means undefined behavior, one-off hack, difficult to parse, shortcut, etc. The difference between "clever" code and "bad" code is that "clever" code is written by someone with a lot of knowledge and experience. Their knowledge and experience has allowed them to work with the undefined/undocumented behavior of languages, libs, etc in order to come up with a solution that has the least lines of code/uses the least memory, etc. Not to say that those things are unworthy metrics, but "clever" code doesn't seem to consider maintainability or stability.

I think a better descriptor to strive for is "elegant", defined in my opinion by code that is beautiful in it's own simplicity, succinctness, reliability, and correctness.

Post reply on HN