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

51–60 of 327 posts

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

#51

Post by patrick451 »

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 ?

They obviously do. Just look at the way they run residency programs. They work those poor kids to the bone under minimal supervision. Only the most disingenuous can pretend it's an accident when something goes wrong. The system is clearly designed to harm people.

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

#53

Post by goosejuice »

trustno2 wrote: post #13

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

I'm grateful that I started learning vim and C at the same time in undergrad. Sure vscode is good enough, but a lot of value is gained tweaking your own tools beyond the tool itself.

Producing something doesn't always need to be the goal. Exploration has value.

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

#54

Post by DavidWoof »

trustno2 wrote: post #13

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

I don't think this point is about configuring your editor/environment as much as just knowing it. There's certain features that come up all the time: find file, find class, go to implementation, find references, rename var, etc.

It stuns me how many devs do this stuff manually, when virtually all editors/ides have ways of doing these things.

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

#55

Post by graypegg »

bazoom42 wrote: post #33
bdw5204 wrote: post #18

Earlier quoted context omitted.

To the extent users do care about the tech, they care about performance not how "clean" the code is or whether you're using the newest framework. Users hate when software is slow or uses an exorbitant amount of memory.

Most users have no idea how much memory a piece of software uses. They care about user experience though which means they will care if the UI hangs or is unresponsive.

Bingo. I’d go further and say they don’t care about your application at all. They just want to do something, and your application’s quality is measured by how little it stands in the way of accomplishing that.

The sad fact is this encapsulates features (ease of development, a framework probably does help you ship faster), adaptability (clean abstractions that are easy to work with), and performance.

Finding that balance is always going to be hard but they’re all important!

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

#56

Post by BiteCode_dev »

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…

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

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

#57

Post by ffsm8 »

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…

But you're not going to realize which way it's better unless you've written the bad code before.

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

#58

Post by scott_w »

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…

I wholeheartedly agree with this advice and have for over a decade now. I think there’s something in the fact that you know you caused that that helps the lesson stick. Potentially you will understand the assumptions you had then vs now that allows you to clearly see the underlying lesson to take.

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

#59

Post by supriyo-biswas »

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…

Although, I should point out that reading code is not the same as reading tutorials. Reading code occurs with a kind of intent and focus that is missing when you don’t know much, and thus you may end up falling into the trap of studying multiple tutorials without really trying out much yourself.
Post reply on HN