Live data from Hacker News

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

mbuffett.com

31–40 of 327 posts

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

#31
post #25

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 just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.

And it's fine. Do what works for you. I just don't think playing with editor endlessly is a well spent time. It makes you feel like you do actual work when you don't. In my opinion.

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

#32

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…

Same here. I don't spend most of my time typing but rather thinking. So getting good at vim or getting faster at typing will not make me any better. That's not to say that I'm not in favor of being good at typing. I know my keyboard well enough to touch type also I know some keyboard short cuts specific to vscode but they are intuitive and have a GUI alternative if I don't feel like using them.

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

#33
post #18
post #5

Earlier quoted context omitted.

* This * - The users don't care about the tech. They care about the result.

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.

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

#34

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…

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

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

#35

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…

Same here. I don't spend most of my time typing but rather thinking. So getting good at vim or getting faster at typing will not make me any better. That's not to say that I'm not in favor of being good at typing. I know my keyboard well enough to touch type also I know some keyboard short cuts specific to vscode but they are intuitive and have a GUI alternative if I don't feel like using them.

One of my colleagues was using dvorak and arguing that because he types faster with it, he's a better programmer.

i never thought typing speed is all that important when you code. But he DID write crazy fast.

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

#36

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…

A way to rephrase your point about complexity is this wonderful quote "Developers are drawn to complexity like moths to a flame, often with the same outcome" (Neal Ford)

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

#37
This was great. I particularly enjoyed the "Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code" section, I'd never thought about how spending time writing "perfect" code means you don't get to figure out which aspects of that code actually matter.

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

#38

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.

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

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

#39
I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn.

The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From the caveats and examples, I think the author is trying to say something rather different; something like “don’t obsess over completeness” or other concepts of ideal software - especially, I might add, dogmatic concepts of this nature.

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

#40
post #18
post #5

Earlier quoted context omitted.

* This * - The users don't care about the tech. They care about the result.

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.

Yeah, I totally agree. Those other factors are internal optimizations. What gets me is when a team wants to switch horses to new tech and do a forklift upgrade just to implement something using the new hotness.
Post reply on HN