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

211–220 of 327 posts

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

#211

Post by icedchai »

lolinder wrote: post #207
icedchai wrote: post #195

Earlier quoted context omitted.

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.

It really depends on the context. The important thing to realize is that bad developers who are kept around tend to survive because they're well liked by people who make the decisions. If you raise concerns about their performance then you're picking a fight that you can very quickly lose. I've seen people get hung out to dry when they escalate concerns about people like that, and even if they were right it still lea…

I agree it is context dependent, but I was trying to show that it's not a binary choice between escalating or leaving. You can do both. If you lose the battle, at least you tried. I've left some jobs too early and regretted it. I could've done more and I should have done more. Probably, I would've failed anyway. Corporate politics and company culture is such a strong force.

The reality is many direct managers have little visibility into their reports day-to-day work because they are not hands-on enough. They should be checking the work product. Example: They should at least be looking at PRs and even participating in code reviews themselves. If you proposed this to some "engineering managers" I am familiar with, they would say this is not their job and you are crazy for even mentioning it. (I'd tell them I disagree about that, too.) This is why coworkers need to escalate performance problems: because many of the people making decisions do not know what is going on.

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

#212

Post by atribecalledqst »

> Don’t underestimate the value of digging into history to investigate some bugs

I'm one of about 2 people at my company who goes on archaeological expeditions to understand when and why a bug was introduced. A nonzero number of times, I have found that the behavior was introduced on purpose over a decade ago, and sometimes it's addressing an edge case I didn't think about. History is valuable!

(unfortunately the most common usage for me though is as a 'smell test' where I learn who wrote the code from the history and then decide based on my existing assessment of their skills, how suspicious I should be of that code)

e; oh yeah one more story that's kinda funny. Just this week I saw some behavior that I didn't like and went to look at the code's history. I was the one who wrote the code I didn't like. But I had left a good enough comment on it that I realized there actually was no issue at all and my expectations were incorrect.

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

#213

Post by 999900000999 »

icedchai wrote: post #206
999900000999 wrote: post #204

Earlier quoted context omitted.

Or. Hear me out. You're going to then publicly embarrass another co worker. Not a good idea. I need to clarify though, there's a difference between functional code that could have been written better, and code which does nothing at all . I was at a company where three or four people literally were writing code that did nothing but was appearing to function correctly. Imagine an API that checks the status of another s…

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.

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

#214

Post by standardUser »

> You’re going to be renaming things, going to type definitions, finding references, etc a lot; you should be fast at this. You should know all the major shortcuts in your editor.

Programmers love to think this matters. If you're doing anything more than the most rudimentary work, the time 'saved' by maximizing keyboard shortcuts is completely irrelevant. You're spending most of your time reading code, thinking about that code and thinking of what code you're going to write.

When any programmer emphasizes how fast they are at completing these rudimentary tasks, my assumption is they are less adapt at the actual work of programming and instead try to 'git gud' at the keyboard wizard bullshit.

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

#215

Post by austin-cheney »

largelady97 wrote: post #190
austin-cheney wrote: post #176

Earlier quoted context omitted.

Writing ample clear documentation, precision of communication, dutifully fulfilling all timesheets, logging of work performed, attending all requested meetings, and always delivering work on time.

[flagged]

Absolutely. The problem with trying too hard to be a great craftsman is that you become emotionally invested. Most of your peers will not have this and will not understand it.

Someone else mentioned becoming a 10x developer and yet being surpassed in your career. That is absolutely very real.

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

#216

Post by vitus »

pavel_lishin wrote: post #83
vitus wrote: post #73

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question". Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an a…

On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking. One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general. Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're gett…

Agreed, now that I'm the person getting these questions, it's hard to reconcile "it would have saved me a ton of time when I was new to this codebase" with "why can't you do even a basic amount of due diligence to even figure out what you're trying to do". (As I mentioned -- it's still important to figure out what the right question is!)

It's hard to find the right balance, and I agree with the author's framing of it as a spectrum, but I also agree that I at least (and most junior engineers, in my experience) leaned way too far on the side of being, um, self-motivated.

I certainly do notice myself getting frustrated by people asking questions when IMO they should know better, and I'm never sure whether I should be more lenient there or if I should tell them off for not putting in that tiny bit of effort.

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

#217

Post by wiseowise »

largelady97 wrote: post #190
austin-cheney wrote: post #176

Earlier quoted context omitted.

Writing ample clear documentation, precision of communication, dutifully fulfilling all timesheets, logging of work performed, attending all requested meetings, and always delivering work on time.

[flagged]

> Your advice for being valuable is basically to slave away and follow your masters orders at daily scrum, not leave your box one minute outside of your allocated time , attend all bending over sessions and be pleasant as you take it , say what they want you to say with precision and always be whatever they want you to be i.e a massive people pleasing cuck with no principles that nobody can ever really trust or respect.

What the hell did I just read?

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

#218

Post by dan-robertson »

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…

It’s funny, this comment went in a totally different direction from what I expected based on the start.

When you wrote ‘don’t take things personally at work’, I was expecting you to say things things about various kinds of humility – trying to make requested changes in code review instead of pushing back, not feeling wronged if someone rewrites something you wrote, etc – and seeing the bigger picture – the code exists to serve business purposes and sometimes priorities there don’t align with your more narrowly focused desires for the direction the code should be changed in.

I would say that the rest of you comment gives examples of taking things quite personally – feeling such strong ownership over the code that you’ll quit when you can’t control it as well as you’d like. To be clear, I’m arguing that the beginning does not match the rest of the comment, but not really about the overall message, which to me feels to be more something like ‘you are not required to be loyal’ than ‘don’t take it personally’.

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

#219

Post by smdyc1 »

tdumitrescu wrote: post #149
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.

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…

Yes, I tend on the side of only tweaking things when I realise I'm repetitively using the same context menus. That's the only point I learn the keyboard shortcuts, or map one, these days. I really haven't had to learn too many shortcuts. The best ones are multi-cursor editing like you've mentioned.

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

#220

Post by wiseowise »

standardUser wrote: post #214

> You’re going to be renaming things, going to type definitions, finding references, etc a lot; you should be fast at this. You should know all the major shortcuts in your editor. Programmers love to think this matters. If you're doing anything more than the most rudimentary work, the time 'saved' by maximizing keyboard shortcuts is completely irrelevant. You're spending most of your time reading code, thinking about…

> my assumption is they are less adapt at the actual work of programming and instead try to 'git gud' at the keyboard wizard bullshit.

Whatever lets you sleep at night.

Post reply on HN