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

191–200 of 327 posts

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

#191

Post by roughly »

pessimizer wrote: post #184
roughly wrote: post #180

Earlier quoted context omitted.

Related, the computer doesn’t care about you and isn’t judging you when it throws an error. Your code has the bug, not you. Stop feeling shitty about yourself and go fix it.

I find it helpful to blame all my bugs on the stupid computer not knowing how to listen, then comb through to code to find what the computer was too dumb to understand. When I find it, I realize that in my haste I had accidentally misspoken to the computer who was doing the best it could to please me, I correct it and promise to explain myself better next time, then apologize. I find it therapeutic to externalize to…

Sounds like you’re ready for management!

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

#192

Post by Throw_Away_1049 »

largelady97 wrote: post #188
austin-cheney wrote: post #169

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…

[flagged]

You’re right but OP is right too. If you can politic well, you can surpass a 10x programmer due to increased leverage. So, work on both I guess.

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

#194

Post by wrycoder »

tdumitrescu wrote: post #159
Chris_Newton wrote: post #112

Earlier quoted context omitted.

Possibly my all-time favourite XKCD, Is it worth the time?¹ , demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years…

> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well w…

It may not be worth the time to automate those, but I always take the time to document them, usually in Obsidian, where I can easily find them later.

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

#195

Post by icedchai »

999900000999 wrote: post #158

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…

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway, you may as well try to change things for the better first.

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

#196

Post by icedchai »

mostlysimilar wrote: post #187
oblio wrote: 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.

> 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. Citation needed. Good developers are just as in demand now as they have ever been.

It's supply and demand. Demand is lower (less jobs.) Supply is higher (more layoffs, people looking for work.) Even if you are "good", there's a lot of other "good" people looking, too. Some even may be better than you! Or at least better at marketing themselves.

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

#197

Post by glouwbug »

999900000999 wrote: post #158

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…

Do what is asked and go home to your family

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

#199

Post by josephg »

icedchai wrote: post #195
999900000999 wrote: post #158

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…

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway , you may as well try to change things for the better first.

Yep. I’ve heard this talked about as Voice and Exit. They’re two strategies you almost always have available: essentially, speak up or leave.

If all the people who care about a problem leave, it becomes harder for the organisation to solve the problem. This is one form of organisational rot.

Most of us are good at one and bad at the other. Eg, my instinctive response has been to quit my job when I’m not enjoying it. And that’s fine, but some of the situations were almost certainly salvageable. And I could have helped. Some people try to fix a workplace indefinitely, even to their own detriment, and even when the situation is probably impossible to fix and they should just get out of there.

I think it’s really important to learn both skills. And remind myself when I’m stressed that they’re both options.

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

#200

Post by Spivak »

alberth wrote: post #198

> If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing That’s how I feel about git.

It's a product of its time dealing with requirements and limitations that aren't much relevant anymore. As far as multiplayer save goes we have much more powerful tooling than we had back then.

But I think git became so ubiquitous that even new solutions unburdened by needing to mimic git's data model end up bringing that complexity forward because of familiarity.

Post reply on HN