A bunch of programming advice I'd give to myself 15 years ago • Hacker News Board

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

#71

Post by darby_nine » Sat, Jun 29, 2024, 2:05 PM UTC

DavidWoof wrote: post #54

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.

In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their intention.

In my experience, lisp also has this issue of being very difficult to tool in a general sense, as did aspects of writing c/c++ years ago (maybe recognizing stuff like macro-generated symbols has improved by now).

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

#72

Post by thfuran » Sat, Jun 29, 2024, 2:06 PM UTC

4RealFreedom wrote: post #49

jameshart wrote: post #38

Earlier quoted context omitted.

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

Yes. Nothing is perfect. The remedy they've chosen is to rely on insurance. There is a reason we call doctor's offices 'practices'.

There is, but it's not what you're implying.

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

#73

Post by vitus » Sat, Jun 29, 2024, 2:06 PM UTC

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question".

Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an answer in 5 minutes. Sometimes, I didn't even know who the right person to ask was, but if I had just asked my tech lead, he would have been able to point me in the right direction.

Claiming that it reduces your overall time from several hours to < 5 minutes is maybe a bit exaggerated, since it also takes time to figure out what question you want to ask in the first place. But it's still worthwhile even if you end up investigating for 30 minutes instead of 3 hours.

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

#74

Post by BiteCode_dev » Sat, Jun 29, 2024, 2:07 PM UTC

ffsm8 wrote: post #57

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…

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

Tangential, but I think that's the problem with trying to learn from design patterns.

I read about them and tried to apply them.

That's backward and didn't produce anything good.

I started to understand them by doing it the other way around:

- Coding, solving problems.

- Reading other people's sources.

- Then reinventing half a terrible design pattern.

- Later on, looking at a book: "ohhh, that's what I tried to do" or "ohhh, hence the snippet in that source".

- Now I can discuss with people about the pattern and name my code entities according to that.

Design patterns are a communication tool.

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

#75

Post by penteract » Sat, Jun 29, 2024, 2:07 PM UTC

supriyo-biswas wrote: post #59

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…

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.

Tutorials include some code which is intended to be exemplary and simple enough for a new programmer to make sense of, so I wouldn't discount it as a part of reading code. Practical code does not always have those properties, although you'd certainly be missing a lot if you only read code from tutorials.

I completely agree with the claim "There is no substitute for doing", and I might even say that code you read without running and tweaking it doesn't count.

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

#76

Post by mrits » Sat, Jun 29, 2024, 2:10 PM UTC

I spent a ridiculous amount of hours tweaking my vim config over the last two decades. I've used vscode the last few years and rarely jump to vim to do some text manipulation (that I usually could do with a raw install)

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

#77

Post by switch007 » Sat, Jun 29, 2024, 2:12 PM UTC

4RealFreedom wrote: post #49

jameshart wrote: post #38

Earlier quoted context omitted.

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

Yes. Nothing is perfect. The remedy they've chosen is to rely on insurance. There is a reason we call doctor's offices 'practices'.

You think they're called practices because of the less common usage of the term to mean an amateur learning something, to imply they're inexperienced/without training?

Rather than it being the place where a practitioner works? ("someone whose regular work has involved a lot of training")

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

#78

Post by BiteCode_dev » Sat, Jun 29, 2024, 2:13 PM UTC

goosejuice wrote: post #69

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.

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.

Planes and bridges are problems where the quality control can be centralized and you can therefore put a lot of redundancy.

Even then, the Boeing scandal shows it's not bulletproof.

It's not the same for medicine. There are way more doctors than you can put safety nets. Also, when a plane crashes, it's on the news, it costs money and PR. Much less so with doctors.

The plane industry is not inherently more moral, just more liable. Responsibility in the health industry is way more diluted.

It's not that we WANT to pay the price of people learning. I wish I would not have had the wrong meds given to me last year.

It's just that the system is not currently set up to do it otherwise.

So you can feel guilty and stop moving, and you will not learn. You will not grow. And you will actually hurt people for a longer period because you will still make mistakes.

Or you can own it and accept the inevitable: doing things means having actual consequences on the world.

If you want, you can dedicate your life to change the whole system and make it better. But I don't think anybody in this thread is doing that right now.

I did see a lot of people on their high horses, but doing nothing though, paralyzed because they were looking for a way to never break anything.

Me, for example. For years.

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

#79

Post by TheRoque » Sat, Jun 29, 2024, 2:18 PM UTC

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…

I never really got the "it's ok to be an imposter", "it's ok to be bad" part... And the internet is full of people saying things like "I am a developer and I have no idea what I'm doing haha".

Seriously, you might be inexperienced or not know everything, but you should clearly not be an imposter and you should be confident in your ability to improve and understand what you don't understand yet.

Take responsabilities and ownership in what you do, don't get behind the easy excuse that it's too complicated. You are the professional and you are getting paid for this.

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

#80

Post by DrBazza » Sat, Jun 29, 2024, 2:18 PM UTC

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…

From 30+ years of dev work:

> - There is no substitute for doing. Less tutorials, more coding.

I'd rephrase that as "just write something!"

Many times I find myself being the classic example of 'perfect is the enemy of good' - I'll think about the perfect solution, rather than write something *now*, that works, and refactor towards perfect. TDD and all that.

Other things:

- Beware the beta and the boss. If it works, it will invariably get shipped if your manager sees it. Many managers cannot put a value on the future cost of maintaining something that's barely good enough.

- Classic Confucius: "I hear and I forget. I see and I remember. I do and I understand." If you're interested enough to read about some tech/language/framework, write something (again!).

- Learn at least one other language and ecosystem in addition to your main one. Even if it is syntactically similar (C++, Java, C#, for example).