Live data from Hacker News

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

mbuffett.com

271–280 of 327 posts

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

#271
post #209
post #164

Earlier quoted context omitted.

Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. Much fewer devs can just jump ship at will than between 2003 - 2022.

The market is not in a free fall. Or rather, it's only a free fall for junior fresh-out-of-college developers. If you are skilled and senior, don't believe this nonsense and have confidence in yourself. This is just an extension of the imposter syndrome that I see often in many people.

This is exactly it.

The entry level market is getting more and more over saturated. It is bleeding upwards to mid level slowly. But if you are a skilled senior you are still in high demand. If not your resume probably sucks or you are not as skilled as most seniors.

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

#272
post #248

The one piece of advice I would give myself 15 years ago: In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity/tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from th…

I really hate that attitude. It's so self-defeating. The only way to ever advance your career is by becoming a worthless little middle-manager parasite? I'd rather quit. I know that's the common belief: just program long enough that you never have to do it again and then you get a cushy job telling other people what to do and spending hours in worthless meetings coming up with short-sighted "initiatives" to pump up y…

It doesn’t match my experience. I developed features faster than the rest of my team and implemented a bunch of practices that are not known in the industry. As a result we delivered more and I got promoted.

Also be vary of someone saying that just because things aren’t measured it is just an opinion. Most important decisions you make won’t be measurable (a lot will though), that does not mean there aren’t good and bad decisions.

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

#274

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…

Learning vim teaches you new ways to think about code editing and is useful if you ssh into machines. I think learning in itself has value, and I think even if you go back to vscode it might have taught you how to better navigate, maybe you realized for example that file trees aren’t so efficient and it’s best to navigate via the fuzzy search.

Then there is also the collective argument that letting Microsoft have editor monopoly can be really disastrous.

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

#275

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…

> But maybe just vim sucks and I should have been playing with emacs all along, I don't know.

Honestly, yes, I think this is it. Ok, vim doesn't suck as a text editor, but it sucks if what you really wanted was VS Code. Emacs, however, doesn't suck. I spend very little time tweaking my Emacs config these days, but when I do it's to fix things VS Code users just have to put up with. I've watched over their shoulders. They put up with a lot.

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

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

I recently encountered this in a hardware context. To “fix” a bug, instead of understanding the root cause, the designer’s patch just hid the first symptom. In a domain where bugs are remarkably expensive, this approach was terrifying to see.

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

#277
> update our subscription layer to call subscribers on the main thread instead

I often do this, but have been doing it less frequently, lately, because I don't want to force a thread switch, unless I know that I'll be calling UIKit functions (not always things that affect UI. Many "background" UIKit functions also require main thread). Instead, I clearly mention the thread state, in the API headerdoc description ("- parameter handler: A simple, no-parameter, tail completion. May be called in any thread.").

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

#278

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

> If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away .

IMO, one of the biggest reasons for this, is coders that know that they won't be around to have to clean up their messes.

Sort of a "chicken and egg" scenario.

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

#279

Earlier quoted context omitted.

Not necessarily. You can escalate things to your boss. Or then their boss. They talk to the coworker about it. It doesn't have to (and shouldn't be) a public inquisition. Maybe you do some one-on-one sessions / mentoring to try to help them. Maybe you're not patient enough to try this. It's certainly easier to leave most of the time. The code aspect is all shades of gray. I've seen code that "functions" but has such…

I didn't have that experience, I was basically told that I should shut up and get used to working with code that doesn't functionally do anything . Then when I complain later my manager was like, even though the code doesn't do anything it makes our metrics look better. Imagine seeing function1(){ ApiCall("1") } function2(){ ApiCall("2) } Over and over again.

Write a test case and file a bug.

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

#280

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 always slightly sad when software developers are confident that software can't possibly make them more productive.
Post reply on HN