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

231–240 of 327 posts

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

#231

Post by icedchai »

999900000999 wrote: post #229
icedchai wrote: post #227

Earlier quoted context omitted.

I'd tell them I am not shutting up and this is a major problem affecting the quality of the product. I would then speak to the boss's boss about it and start complaining about the boss doing a poor job, encouraging fake, meaningless metrics to game the system. Maybe they'll get get fed up and tell you to GTFO. Probably not though. The thing about broken organizations is that they take forever to fire anyone, so use t…

That seems like a whole lot of work, compared to just finding another job and walking out . I'm not trying to change the world, I'm trying to make money so I can save and retire preferably before I turn 50. If I've learned anything about life is that you need to pick what battles you want to fight. If option A is argue with numerous people and openly expose multiple layers of incompetence, to the point where my manag…

I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is.

And do you really care if some incompetent hates you? I hate working with incompetent people, so some mutual feelings are perfectly fine. It may even improve the situation, at least temporarily: They'll reduce their interactions with you to avoid conflict, since most people are rather conflict avoidant.

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

#232

Post by recursive »

icedchai wrote: post #231
999900000999 wrote: post #229

Earlier quoted context omitted.

That seems like a whole lot of work, compared to just finding another job and walking out . I'm not trying to change the world, I'm trying to make money so I can save and retire preferably before I turn 50. If I've learned anything about life is that you need to pick what battles you want to fight. If option A is argue with numerous people and openly expose multiple layers of incompetence, to the point where my manag…

I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. And do you really care if some incompetent hates you? I hate working with incompetent people, so some mutual feelings are perfectly fine. It may even improve the situation, at least temporarily: They'll reduce…

Bad impressions can be contagious. Some "incompetents" have political capital.

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

#233

Post by goosejuice »

babel_ wrote: post #119
goosejuice wrote: post #91

Earlier quoted context omitted.

Sure, we're human. There is no argument there. However, normalizing the loss of human life as part of the learning algorithm is psychopathic. There's a time and a place to make mistakes... In mission critical situations that's in training and everywhere else we should aspire for safeguards that prevent the loss of life due to mistakes. In medicine a lot of these deaths can be prevented through greater care. It's not…

I think you're misreading a singular opinion as occurring between two disparate points here. The initial phrase was > doctors hurt people for years while learning to save them It's then a separate reply from someone else about deaths from errors/malpractice. So, nobody seems to be expressing the mentality you are, correctly, lambasting (at least so far as I've read in the comments). But, as it is relevant to the less…

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

Is what I was originally replying to, which, at least to me does seem to imply preventative deaths are some kind of training tax during ones 'imposter stage'. Perhaps not the intention of the poster.

Thanks for your thoughtful reply.

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

#234

Post by klardotsh »

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

Could you expand a bit on what you mean by administration?

The paperwork matters far more than the actual work. Having your Jira tickets (or whatever) up to date and highly granular, and organized into all the taxonomies of sprints/epics/etc, and of course actually communicating status with teammates, tends to be significantly higher-valued than any actual code you're getting done, at least as far as winning brownie points and promotions are concerned.

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

#235

Post by j45 »

8n4vidtmkvmk wrote: post #189
j45 wrote: post #137

Earlier quoted context omitted.

'Addressing' can be ambiguous. Writing comments to explain why it's right and needs to be this way? Or changing the code without considering if they have enough knowledge of the rest of the codebase. There's also a chance it's not understood yet to easily explain it. A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.

Sometimes there's understanding, sometimes the person who did understand has left the team. This is why it's worth writing good commit messages and going back to read them when there's a funny piece of code. A lot of my commit messages are to the effect of "I did it this way to be backwards compatible with how it always worked. It still looks funny to me though" Then at least future person knows I don't have a good r…

Definitely agree with this.

Reading code is harder than writing it, and too many people don't have the patience for it.

Instead, in cases like these they'd rather invest the time re-learning the lessons of the past because they thought it should be a certain way, and if they can't instantly see a reason why it's done a certain way, then they behave (unintentionally or otherwise) as if understanding is not possible.

Especially where it's tricky it's worth including a larger pre-amble in the code itself, as well as source code control.

Often one or the other are suffering, and it's sometimes worth giving a description of how the components work together in detail, or are relied up on by more than one use case (therefore not a simple change or solution).

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

#236

Post by feoren »

hamasho wrote: post #11

Most of this advice has already clicked with me, but this part: > If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing That's a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don't think this stuff would've helped me much when I was a junior dev. A lot of them are just too nuanced.

Nobody could easily explain why early (1950s - 1970s) fusion reactors were so difficult. It must have been that everyone was stupid and creating their own problems.

No one can explain why the Collatz Conjecture is so hard to prove. It must be because everyone is so stupid and is adding incidental complexity to the problem. Why is everyone so stupid?

Or, maybe, possibly, that advice is utter bullshit nonsense and some problems are just hard for reasons that we don't fully understand. Go write a reliable reactive library that works how people expect. Oh, you can't? Better explain exactly why it's so hard then, or it's obviously all your fault.

That advice is so utterly at odds with actual reality that it makes it clear this author should be completely ignored.

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

#237

Post by j45 »

hinkley wrote: post #132

The trick is not in having advice to offer. It’s in having advice they will hear. Next month I’ll have been working in software for 30 years. Which means I would have a lot more common ground with me 15 years ago than most people will. that me with five years’ experience might not have understood at all. Me with five years’ experience suspected many things that were true but missed some important one. I’d probably ha…

Sharing advice others will be able to hear is one part, having an audience who wants to get where they are a little faster and easier is another.

There was a while where too many jr devs wanted to learn it all and go through the phases of learning everything themselves without considering if others have maybe gone through something similar.

Thinking one's self not qualified might mean you share a good thoughtful approach towards learning something.

Thinking one's self is qualified and if it's too soon might mean otherwise.

No matter the better I have gotten, having a healthy mistrust of one's work helps it become better in a lot of cases haha.

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

#238

Post by 999900000999 »

icedchai wrote: post #231
999900000999 wrote: post #229

Earlier quoted context omitted.

That seems like a whole lot of work, compared to just finding another job and walking out . I'm not trying to change the world, I'm trying to make money so I can save and retire preferably before I turn 50. If I've learned anything about life is that you need to pick what battles you want to fight. If option A is argue with numerous people and openly expose multiple layers of incompetence, to the point where my manag…

I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. And do you really care if some incompetent hates you? I hate working with incompetent people, so some mutual feelings are perfectly fine. It may even improve the situation, at least temporarily: They'll reduce…

>I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is.

Exactly!

I do not care about anything in regards to a job outside of my paycheck. I'm not trying to change the world. I have no expectation of anything I'm doing making a real difference.

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

#239

Post by t-writescode »

feoren wrote: post #236
hamasho wrote: post #11

Most of this advice has already clicked with me, but this part: > If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing That's a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don't think this stuff would've helped me much when I was a junior dev. A lot of them are just too nuanced.

Nobody could easily explain why early (1950s - 1970s) fusion reactors were so difficult. It must have been that everyone was stupid and creating their own problems. No one can explain why the Collatz Conjecture is so hard to prove. It must be because everyone is so stupid and is adding incidental complexity to the problem. Why is everyone so stupid? Or, maybe, possibly, that advice is utter bullshit nonsense and some…

A sign of a good educator is to - while it may take a lot of time and a lot of building up of base concepts - enlighten people through plain language the complexities of their topic.

Oftentimes, research papers and similar are written for an audience that is already deeply ingrained in their representative topic, such that those first principles aren't discussed anymore, so perhaps that's where you're coming from when you speak about how "no one can explain ..."; but I would argue that many people can, and have. It may just take a lot of speaking, paper, drawings and similar.

And even if / when there are obscenely difficult things to prove, the chances that the thing the proverbial "you" is working on is one of the incredibly difficult things is very unlikely.

There's a saying that a sign of actually understanding something is being able to describe it to a child. It's also why Thing Explainer and ELI5 exists.

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

#240

Post by james_marks »

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

Now I just open vscode with default settings and I am productive right away. I am right away distracted by a huge rectangle around cursor line, current word highlighting and general jumpiness of everything. Coding in vscode feels like writing a book in the middle of brazilian festival. And then it cannot do random simple things like proper indents or humane snippets. The amount of work required to unfuck vscode is re…

Same. I don't know why exactly, but VSCode feels like I'm programming inside an advertisement, and makes my skin crawl.
Post reply on HN