Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bunch of programming advice I'd give to myself 15 years ago

mbuffett.com

Post reply on HN
Print view View original

61–70 of 327 posts

Re: A bunch of programming advice I'd give to myself 15 years ago

#61

Post by megamalloc »

Mostly pretty sound advice here, but oh, this rankles! --

"In situations where bugs aren’t mission critical (ex. 99% of web apps), you’re going to get further with shipping fast and fixing bugs fast, than taking the time to make sure you’re shipping pristine features on your first try."

In 99% of web apps, your end users have no possible way of telling you that you shipped a bug, and your bug will remain there forever, frustrating users and losing your client money as they abandon your site. Telemetry won't help you either becuase you'll misunderstand the observations it provides.

Re: A bunch of programming advice I'd give to myself 15 years ago

#62

Post by BiteCode_dev »

jameshart wrote: post #38
ponector wrote: post #34

Earlier quoted context omitted.

A recent Johns Hopkins study claims more than 250,000 people in the U.S. die every year from medical errors. It is ok to be an imposter.

Is it your impression that the medical profession thinks that’s ok ?

Show me a hospital, and I'll show you overworked, under slept young doctors that have to deal with paper work, and are swimming in a field with heavy lobbying.

But even without this, the thing is, when you don't know, you will make mistakes.

And when your job is to take care of people, mistakes hurt them.

It's the nature of things.

Last year I had 3 medical errors, one that almost got me killed, by very well-meaning professionals.

Closing your eyes and pretending it doesn't happen is naive at best.

But people have to start somewhere. They can't stay in theory forever. And no amount of preparation will save you from making terrible mistakes.

Since we can't put an experienced doctor behind every intern 24/7, there is no real solution to this for now.

Same for programming.

Re: A bunch of programming advice I'd give to myself 15 years ago

#63

Post by theideaofcoffee »

> If you (or your team) are shooting yourselves in the foot constantly, fix the gun

This is a reasonable step to take if you're working in a reasonable company with reasonable "management". If you're unlucky enough to be working under a manager that refuses to recognize there is a problem, even with compelling data, prepare for pain. In that case nothing is allowed to be done because "well, that's how we've always done it and doing something about it might upset someone". It's really time to quit and find something new at that point because there is generally no hope of turning that around.

> If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing

See above. "That's how we've always done it, and someone is used to that work flow, so we can't change it." Sometimes this will lead to a legitimate Chesterton's Fence situation, in which case you'd want to regroup and rethink it. Otherwise, the batshit insane is the default. Target the latter.

> Try to solve bugs one layer deeper

"There is no time to do that! We have so many other projects!" While being blind to the fact (or better yet, burying their head in the sand and trying to ignore) that it's all self-induced.

> Don’t underestimate the value of digging into history to investigate some bugs

"We can't change that because one of our people close to management made that decision and it might drive them away." Good, get them out, that's the only way to really fix it. Ideally if the management that hired them is pushed out too.

> When working on a team, you should usually ask the question

"Who are you to question our wisdom? Who are you to suggest something else, it's working in production."

These are great things to start conversations, but you have to start them in an organization that is willing to change and be willing to take your advice to heart. Don't waste your precious life trying to change what can't be change, no matter how much you want to see it change.

Re: A bunch of programming advice I'd give to myself 15 years ago

#64

Post by northrup »

BiteCode_dev wrote: post #56
penteract wrote: post #19

Earlier quoted context omitted.

> There is no substitute for doing. Less tutorials, more coding. This may be good advice for yourself in the past, and for many people at lots of times, but I'd hesitate to give it as general advice. Reading code others have written should not be understated as way to learn valuable things from fundamental patterns and algorithms to language features and idioms. If you have a job in a team, this may happen anyway, bu…

Indeed it's not general advice, it's to me specifically, who used to procrastinate a lot under the guise of learning.

Same. I would fall into the same trap. One more article, another tutorial, another chapter of a book… juuust to make sure I understood the concepts; and what actually helped? Just coding, getting it wrong, fixing it, getting it wrong, fixing it, etc.

Re: A bunch of programming advice I'd give to myself 15 years ago

#65

Post by BiteCode_dev »

FLT8 wrote: post #21
graypegg wrote: post #4

Earlier quoted context omitted.

A bit snarky, but I would add - don’t read opinions from a list and take it as gospel. Adapt to the jobs you’re in, and you’ll develop your own opinions, but now with experience to explain why. Opinions are formed by getting repeatedly hit with the consequences of your (and other’s) decisions, and everyone just has to take enough hits till the pattern seeking area of your brain takes over.

Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it…

Skin in the game is important.

I have a terrible programmer friend.

He is better at creating actual products than most people I met because his livelihood is on the line: he makes money only from websites.

So he is not living in the abstract idea of best practices, he had to make it profitable for the last two decades, with little resources to go by on top of that.

And he does.

After 10 years, he is still asking me how to write git commands. And I'm still learning from him to shed a lot of BS from my practices.

Re: A bunch of programming advice I'd give to myself 15 years ago

#66

Post by Zenzero »

BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

> It's ok, doctors hurt people for years while learning to save them.

Modern medical education doesn't work this way.

Re: A bunch of programming advice I'd give to myself 15 years ago

#68

Post by PartiallyTyped »

penteract wrote: post #19
BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

> There is no substitute for doing. Less tutorials, more coding. This may be good advice for yourself in the past, and for many people at lots of times, but I'd hesitate to give it as general advice. Reading code others have written should not be understated as way to learn valuable things from fundamental patterns and algorithms to language features and idioms. If you have a job in a team, this may happen anyway, bu…

I think reading code to understand because you forked a project and want to continue it is very different to following tutorials.

Re: A bunch of programming advice I'd give to myself 15 years ago

#69

Post by goosejuice »

ponector wrote: post #34
jameshart wrote: post #24

Earlier quoted context omitted.

> You have imposter syndrome because you are an imposter. You are really bad. It's ok, doctors hurt people for years while learning to save them What in the medical malpractice?

A recent Johns Hopkins study claims more than 250,000 people in the U.S. die every year from medical errors. It is ok to be an imposter.

Yeah let's go build some shoddy bridges and crash some planes while we're at it.

Individuals can be new to a practice and feel like imposters but we shouldn't be pointing to statistics like this as an example of why it's ok.

I can't believe people think like this.

Re: A bunch of programming advice I'd give to myself 15 years ago

#70

Post by photochemsyn »

> "It’s really easy to write terrible code. But it’s also really easy to write code that follows absolutely every best practice, with 100% test coverage, and has been fuzz-tested and mutation-tested for good measure – your startup will just run out of money before you finish. So a lot of programming is figuring out the balance."

The situation appears to be changing rapidly. 15 years ago there were no advanced code-generating LLMs, and while relying on them for the core logic without having a good understanding of the language and system is still a bit iffy, it does seem that they're pretty good for generating tests and spotting deviations from whatever your group has decided are best practices.

Post reply on HN