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

#121

Post by password4321 » Sat, Jun 29, 2024, 3:56 PM UTC

jerf wrote: post #102

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…

"Those are way too abstract advice when you start programming." I have come to the conclusion that the use of these sorts of posts is not that the reader, young or otherwise, will instantly and correctly apply all the lessons to their lives. It's more about sensitizing people to problems they may not currently see, and solutions they may not currently be aware of. It's about shortening the learning curve, rather than…

Yes, countering "you don't know what you don't know"

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

#122

Post by avanai » Sat, Jun 29, 2024, 3:59 PM UTC

> Try to solve bugs one layer deeper

This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code.

It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level.

You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.

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

#123

Post by TillE » Sat, Jun 29, 2024, 4:01 PM UTC

bregma wrote: post #25

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

The VS Code launch settings crap is a mess. But like as an editor, it's an editor. You can just use it like that. It works well and has good defaults, you can open a terminal with a hotkey, etc.

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

#124

Post by sethammons » Sat, Jun 29, 2024, 4:17 PM UTC

posix86 wrote: post #42

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…

VSCode can also be used more or less effectively though. There are quite a few shortcuts & tricks that can make you 10x more productive, even if maybe it's not as much as vim.

Multi-cursor on ten lines, sure. You get 10x for some seconds or maybe minutes. I'd expect practically zero people have gotten 3x more productive over a two week period for having advanced knowledge of tips and tricks in their editor. Saying 10x seems a wild exaggeration

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

#125

Post by farmeroy » Sat, Jun 29, 2024, 4:18 PM UTC

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've been using neovim pretty much since I began programming. I had some initial setup and have tweaked it once or twice, but it's by no means been a source of sunk time for me. I recently had to switch to VSCode and had a lot of issues learning all the out of the box key bindings and not having the telescope and fuzzy find windows I was used to was a huge productivity loss for me. When I able to jump back to neovim it was such a huge relief.

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

#126

Post by Anduia » Sat, Jun 29, 2024, 4:25 PM UTC

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else?

What does people use that is faster to process both for devs and the PM?

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

#127

Post by yowlingcat » Sat, Jun 29, 2024, 4:28 PM UTC

Agree with sibling comment saying these are too abstract. Here are mine:

Fundamentals:

- Ecosystem beats language and syntax

- Use boring, battle tested technologies

- Use the relational database to do the heavy lifting

- Avoid caching unless you have a great reason

- Code cleanliness comes from simplicity, not elegance

- There's higher leverage from improved code reading ability over writing ability

Professional:

- You grow faster building in good industries over interesting codebases

- There's higher leverage from improving the business over improving the code

- There's higher leverage in finding mentorship over being an autodidact

- Make T-shaped buy vs build calls: build the secret sauce, try to buy the rest

Probably leaving a bunch out.

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

#128

Post by skydhash » Sat, Jun 29, 2024, 4:29 PM UTC

darby_nine wrote: post #71

DavidWoof wrote: post #54

Earlier quoted context omitted.

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…

> lisp also has this issue of being very difficult to tool in a general sense

Most of the common lisp tooling is already present in the language itself. Things like inspect, trace, describe and apropos already gives you the equivalent of most IDEs. I agree with you for some dynamic language and magic methods. It can be hard to trace back the exact function that are being called. But you can always design some tooling for it as long as the code follows the ecosystem convention (Laravel plugin in PhpStorm).

The nice thing about Vim (and other configurable editors) is how easy to mesh existing tooling with the editor itself, without requiring for that extension to be a whole project unto itself.

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

#129

Post by sethammons » Sat, Jun 29, 2024, 4:32 PM UTC

supriyo-biswas wrote: post #84

I wish more articles talked about the usefulness of integration tests over unit tests. Personally, I feel that unit tests are overrated and rarely give the required confidence to inform the team whether something is ship ready, whereas integration tests on the common workflows means that even when a bug is introduced, very few users are affected.

So much this. I have been at a few shops now that feel their integration tests are ok and their unit tests are proving >90% coverage and yet they break the login or auth flow weekly. An absolute aversion to e2e tests. As soon as I can make a test log in and create and read one record, and bake that into the release process (preferably gating merge to main and after deployment artifact generation) then the site no longer breaks every week. Customer pain and hours of dev work saved.

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

#130

Post by trashburger » Sat, Jun 29, 2024, 4:33 PM UTC

mannykannot wrote: post #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 t…

I think you got the wrong idea from that sentence; the author is talking more about the feedback you get from your end-users and/or customers, rather than development feedback a la debug info.