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

141–150 of 327 posts

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

#141

Post by hinkley »

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 on the fence. When I obsessed more about Flow State, I really did see dividends from spending spare cycles reading the docs (especially release notes) and keyboard shortcut mappings to find faster ways to do things I did often.

Maybe I hit the point of diminishing returns. Maybe it’s because I don’t Code Like Hell much anymore, but it’s a habit I got out of. I keep resolving to getting back to it, but the fact I don’t maybe telling me something. Like maybe I’ve filled that spare time with other things that are more valuable.

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

#142

Post by default-kramer »

hiatus wrote: post #136
avanai wrote: post #122

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

> 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. I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.

Of course this can vary wildly, but I've never felt afraid to defy management on that one. Half the time, they don't even need to know. And the other half of the time... what are they going to do? Fire me? Fine, then their project will be filled with nothing but wallpaper-patchers and I'll be somewhere else doing good work.

(And of course, sometimes just patching the wallpaper is the right course of action, but it's rare to find management capable of accurately assessing this trade-off.)

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

#143

Post by __turbobrew__ »

hiatus wrote: post #136
avanai wrote: post #122

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

> 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. I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.

Part of being senior is figuring out how to work in those constraints. In that situation I would push back my manager and tell them why root causing bugs will save us time in the long run and if they still don’t relent I would sandbag some of my time doing sprint tasks to root cause the bugs.

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

#144

Post by j45 »

trustno2 wrote: post #35
bobajeff wrote: post #32

Earlier quoted context omitted.

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.

Typing fast is an interesting metric.

Shipping the same code will happen sooner if you have tooling and typing setup to allow for quick iterations, and being quick in making those iterations. Selecting a language/framework that might take more work can slow you down too.

Typing faster does seem to look towards thinking faster, trouble shooting faster.

One place where it can get someone into trouble is typing too fast, faster than it might take to think through and not over look something which might invalidate what you're doing.

I have all hires do typeracer.com. Not for a high or a low score, but seeing the development of the score and understanding the importance of typing fast relating to thinking fast.

Typing code inherently is slower than writing sentences, so if you can type faster sentences in written communication, typing code will be faster, even if it's not at the full typing speed.

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

#146

Post by imhoguy »

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

These seem just as abstract as mine, if not more so, plus at least I provided examples where I could. Feels weird to criticize my post for general advice + examples, then come up with your own general advice without examples. Also this was just an analogy I know, but doctors definitely don’t hurt people for years while trying to save them, very different profession from ours, if anything doctors earlier in their care…

I think you both provide some kind of generational advice, like parent serving kid with life advice. Unfortunatelly, or fortunatelly, they will have to learn it by experiencing own failures first.

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

#147

Post by CM30 »

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'd definitely agree that reading others' code can be a good way of learning, especially if you take the time to disassemble it line by line and look up things like what language features and functions they're using, how it's structured, etc.

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

#148

Post by trashburger »

bloopernova wrote: post #118
myaccountonhn wrote: post #26

This is interesting. If I were to complement the list, these are some items I’d add that helped me: - learn functional programming. Doing that was how I finally “grokked” programming and could solve problems more easily. Before I was ready to give up. - learn CS history. I studied UX and what I learnt was mostly one side of how to think about computing where you spoon feed users and remove things. There are other way…

"learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result." I sometimes hold a "command line fundamentals" course for my teams. Just being able to understand the basics puts them above any team that doesn't. You have to know the ground you're building…

Could you please share an itinerary for this? I’d also like to hold a similar course but don’t know where to start.

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

#149

Post by tdumitrescu »

bobajeff wrote: post #32
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…

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.

I think everyone's got a different threshold for where returns start diminishing sharply. While I'm squarely in the "don't waste time micro-tweaking your editor" camp, there are some little bits of shortcuts and tooling that made me much more fluent at code-editing with very little investment. One example that stands out is the multi-cursor support that Sublime Text popularized (and which I use all the time in vscode now). It eliminates a good 80% of repetitive typing, or symbol refactoring that would have involved clunking through menus in old IDEs, and makes experimentation that much quicker. Feels fundamental, like copy/paste shortcuts which everyone knows now.

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

#150

Post by j45 »

farmeroy wrote: post #125
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…

I'm reasonably familiar with both and use them for different cases than each other. vscode at least is my text editor in the gui... but consistently growing :)

The time getting up to speed on something new shouldn't be used against something else that is already familiar.

Now if the new tool (ie., vscode) could import your neovim setup and get you an equivalent, that would be neat.

Comparing the sunk cost time for neovim vs vscode might be a more interesting comparison. Neovim definitely is a little more polished than vim out of the box so it's entirely plausible it's pretty close.

If a vim user wanted to learn something like vscode, they could just install a vim extension in vscode to navigate most of vscode in vim keys. Lots on youtube.

It's hard to use a web browser without a vim extension installed.

It's true if you have sunk the time to super customize a setup for you in anything (currently I'm working through my Aerospace setup), the part that I get caught by sometimes is that something I had to customize in neovim, might already be built into vscode, or something else, or vice versa.

Repetitions is about creating the muscle memory, similar to building the same keys with vim.

I'm lucky I was able to get to a place of comfort with vim when I had lots of free time.

It's great when I don't have my setup with me, but my setup with neovim was a step forward, but vscode still sometimes just ends up where I am, and I figure out how to get it behaving a little better.

Post reply on HN