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

211–220 of 223 posts

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

#211

Post by jodrellblank »

Mirioron wrote: post #97
jodrellblank wrote: post #83

Earlier quoted context omitted.

This is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-... but it's a counter to the popular idea that "more work" is what it takes to become better at something. Two people in the same group will find that the one who tries more will get better results, but training for more time won't get them to a better group. Instead, qualitative changes are needed - probably many of them - people to…

I think it does apply to programming, but quantitative increases in programming also come from the adoption of new tools, programming paradigms, programming languages etc.

I think you're using "quantitative increase" to mean "measurable improvement in output", but in the article sense it means simply "more quantity of practise" without changing the kind of practice.

Quantitative would be "I write more lines of code", "I solve more challenge problems", "I write and release more programs", "I code for more minutes each day, more days each week, more weeks in a year", "I suffer and endure more". This might get you further up in your friend group or class ranking, but won't take you to a new level (so claimed).

Quantitative changes would be things you suggest, like "I use different tools", "I approach problem solving in a new way", "I lean towards hard problems instead of retrying easy things", "I work with different people to learn new ideas", "I use languages which let me do more with less code", etc. (so claimed) those can take you to better output, even if your quantity of practice overall decreases.

We always say "practice makes perfect", but "do what winning people do" seems better advice than "do more of what you are doing, when you aren't winning". Phrased like that it's almost tautological - training longer with bad form, won't give you good form.

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

#212

Post by cheez »

mac01021 wrote: post #176
cheez wrote: post #28

Earlier quoted context omitted.

Indeed. I love it when the amount of money I make is tied to the quality of my code somehow. Easy to modify, easy to repurpose, easy to replace. These often make it possible to serve customers better -> more $$$ It's why I can't really take a regular job. There is no relationship between the quality of my work and what I get paid.

What nonregular job do you do? What kind of code do you deal with, for what kinds of customers? If you're a freelancer or consultant, how often do you end up revisiting code that you write a year or more later?

I sell my own software.

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

#213

Post by franciscop »

hhs wrote: post #204
franciscop wrote: post #103

Earlier quoted context omitted.

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…

Interesting view. In your experience, how did you learn about the best practices - and, then, consider asking when that practice is not valid? It looks like you add purposeful breaks, experiment, and then see what happens. I wonder if you also talk with your colleagues, self-reflect, think about the big picture rather than just the task at hand when you're doing this?

I started coding for fun because I wanted to build things, so when I had a problem I searched how to fix it. At some point, I started noticing "larger" problems that have to do with code structure and data flows.

Since I am self-taught and everyone was talking about "best practices", I started to learn and follow those around 1-2 years into coding. I built beautiful abstract glass houses that didn't get me any closer to my objectives! So I was curious why these best practices were slowing me down and started digging deeper to be able to know how, when and why to apply them. Lots of conflicting info online, so had to start thinking about those by myself and not just follow random articles. I even started searching conflicting info to see the two sides.

But yeah, you are totally right, devs get stuck into that pixel and forget about the larger picture. I switched my thinking to a purely "ROI" for the business, and I am convinced it's been a strong win-win. But you have to learn about the real, implicit and explicit, business objective, which is something 99% of devs do not really care (or need to, in this market). I also started realizing how code was many times not taking me closer to my objectives, but that's a topic for another day.

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

#214

Post by innocentoldguy »

djmips wrote: post #65
innocentoldguy wrote: post #37

> Three years later, I am still very much the apprentice. I used to think I’d get to the point where I could just sit down and breathe out perfect code, but that doesn’t happen. As I’ve thought about the reasons why, I came up with the following reasons: 1. Writing code is an act of inventing. If what I’m trying to build already existed, I could just go buy it and save myself a lot of time and money. It doesn’t exist…

Sometimes I wished I was a baker or a carpenter.

I do too, until payday.

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

#215

Post by muzani »

owenversteeg wrote: post #192
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 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,…

$15k is the norm where I live. It's usually around 5-10 years experience, not quite "senior". The 10% does cap at some point, lol.

If you do want to make an outsourcing agency, the good ones in a developing country make about $60k, which is enough to live in the top 10%. Companies like Accenture specialize in it, but they're not known for good treatment.

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

#216

Post by averros »

bitblit87 wrote: post #137
averros wrote: post #112

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.

Methodology shmethodology. No management fad can replace thinking. Boeing 737 MAX is what you get when scrum masters get to boss around engineers.

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

#217

Post by tinus_hn »

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…

War is peace.

Freedom is slavery.

Worse is better.

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

#218

Post by goatlover »

segmondy wrote: post #171
fourseventy wrote: post #24

Earlier quoted context omitted.

Programming is no different than any other discipline. You aren't going to be an expert in anything in only 3 years. Expert physician? Wont even be out of residency yet. Expert car mechanic? No way. Expert troll on hacker news? Maybe.

Expert car mechanic doesn't take 3 yrs. I went from knowing nothing about cars to building my first race car in 2 years in my late teen years and that's without the wealth of knowledge I can find online today. ... and not just jamming a bigger v8 engine, but slamming a turbo on a 4 banger and not blowing up the engine and shaving almost 3 seconds off the stock 1/4 mile times, with limited budget too. Something I see…

> Being an expert in 3 years is possible in most fields, all you need is dedication and deliberate practice.

Do you have anything other than a personal anecdote to back that up?

> But once they sort it out, they will move 10x faster than most of us old timers ever did.

So instead of 36 months, youngsters today can become experts in most fields in 3.6 months? That sounds preposterous. I assume you think that because of the internet and modern tech enabling much faster learning. But then old timers have access to the same tech and knowledge. So why can't they move just as fast?

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

#219

Post by hhs »

franciscop wrote: post #213
hhs wrote: post #204

Earlier quoted context omitted.

Interesting view. In your experience, how did you learn about the best practices - and, then, consider asking when that practice is not valid? It looks like you add purposeful breaks, experiment, and then see what happens. I wonder if you also talk with your colleagues, self-reflect, think about the big picture rather than just the task at hand when you're doing this?

I started coding for fun because I wanted to build things, so when I had a problem I searched how to fix it. At some point, I started noticing "larger" problems that have to do with code structure and data flows. Since I am self-taught and everyone was talking about "best practices", I started to learn and follow those around 1-2 years into coding. I built beautiful abstract glass houses that didn't get me any closer…

This is very useful. I also agree that it's tough to capture insights because of the conflicting info in many places, from online to even in books and videos. Actively seeking out conflicting info and studying the sides is a good strategy.

Also like your view: "I switched my thinking to a purely "ROI" for the business, and I am convinced it's been a strong win-win. But you have to learn about the real, implicit and explicit, business objective, which is something 99% of devs do not really care (or need to, in this market)." I find this increasingly important, too, thank you.

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

#220

Post by bbbobbb »

kragen wrote: post #206
bbbobbb wrote: post #196

Earlier quoted context omitted.

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

Well, one night in 2007 I wrote a 3-D rendering engine in JS http://canonical.org/~kragen/sw/torus and one Friday night in 2013 I wrote a raytracer in C http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra... . It took me until almost 4 AM, at which point I had reflection, color, and Lambertian shading from a tabular ASCII scene file format; a few days later I added procedural textures, a K-V-pair scene file…

Well, those are indeed impressive given the time you spent on them. I'll get back to you in 20 years to check if I got there.
Post reply on HN