Live data from Hacker News

Advice for new software devs who've read all those other advice essays

buttondown.email

281–290 of 361 posts

Re: Advice for new software devs who've read all those other advice essays

#281
post #255
post #240

Earlier quoted context omitted.

| You sound like you saw the phrase "Right Way Guy", felt it sounded pejorative I'm not sure what it sounded like, but I'm pretty sure I didn't feel that way. | decided it must mean That Type Of Guy I Don't Like. ... huh. That escalated kind of quickly. | I have no idea how the Primer anecdote relates to anything at all. Well, I had hoped the paragraph following the anecdote explained that, but I guess I can't win th…

I'm sorry I replied; I thought you were confusedly misinterpreting the article by reading something about cargo-cult practices into it, but I now think you're just sort of emitting nonsense, and so it turned out to have been pointless. edit: Actually, on reflection, >THEN one of the comments looks suspiciously like it's chiding my social disharmonious actions. I consider this extremely aggressive, rude, and to bear n…

> I don't understand what causes people to talk in bad faith like that.

Okay I guess I'll take the bait and assume you are legitimately confused and that your original comment was in good faith.

When you say something like

> You sound like you saw the phrase "Right Way Guy", felt it sounded pejorative (it's more gently poking fun at a common thing), and decided it must mean That Type Of Guy I Don't Like.

you might think that no one should get offended by this because you are being objective about your thoughts. But it doesn't matter that you're "just" sharing your thoughts. These thoughts are hurtful to the parent as evidenced by their reactions. They're hurtful because people don't like being wrong nor do they like being told that they're upset. If this isn't clear to you, then you have my deepest condolences because I expect you often unintentionally offend others.

If I may offer unsolicited advice, you can avoid this kinds of unpleasant reactions by mincing your words. I know a few people who speak like you did and they all are so confused when I tell them this because they think readers would be offended that they are padding their message with unnecessary formality and fluff. But without it, their message is often curt.

I see this interaction play out all the time on HN (including my response), so I hope my response is not in vain...

Re: Advice for new software devs who've read all those other advice essays

#282

Earlier quoted context omitted.

Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better , but being able to inspect the run…

> but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer. That's kind of the problem and why it's a crutch. If you get better at reading code and reasoning about it without needing to use a debugger, it'll make you even more productive for when you actually do need to reach for it. The opposite is not true. Being able to read code deeply in the setting of c…

I don't think it's possible to put too fine a point on this because it seems to be a weirdly and stupefyingly common point of view among programmers:

This perspective makes absolutely no sense.

This is like saying that the exercises in mathematical textbooks are a crutch because you'll never be able to read formulas if you interact with the ones in the book via the exercises given. This is the exact opposite of the case! The exercises are there to force you to "step through" the technical details in the text, to actively build intuition for the dynamics. If there were a way to spin up a math debugger to literally step through the details as you work through the exercises, that would be amazing. Educators would kill for that capability! And we already have it, essentially for free. But then out of some kind of misplaced sense of purity, tons of people have concluded that it's bad to use this incredible capability.

This is just bad pedagogy.

Edit to add: I feel like I didn't state this plainly enough: The way to learn things from textbooks is not to just read a bunch of different text, it is to interact with the concepts covered by texts. That's why textbooks all have exercises, and why educational institutions always ask students to do those exercises (and more). The advice to "read a lot of code" is like saying "read a lot of textbooks". But that's not good enough. You need to run the code, ask questions of it, test assumptions out; this is just like doing exercises in a textbook, and a debugger is a superpower for doing that active interrogation, while reading the text.

Re: Advice for new software devs who've read all those other advice essays

#283

Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more code. If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much. This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new cod…

Where to find really good code? Open source projects that have stood the test of time?

Re: Advice for new software devs who've read all those other advice essays

#285
post #140

Earlier quoted context omitted.

Not an intelligent quotation. Hardness can be defined as how long it takes to accomplish a task. Following this definition everything can be debugged. It just takes twice as long. This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.

Your premise is false, time to completion and difficulty are not equivalent. Believing such implies it’s more difficult to ride in an aircraft craft around the world than legitimately beat Magnus Carlsen in a rapid chess game. The reverse is frequently the case where running a marathon faster is more difficult than doing so slower.

It's as "false" as his premise of relating difficulty to intelligence. My point is the existence of an alternative statement that is equally and fuzzily true shows that this quote is not really that intelligent.

Reread my post. I literally said neither definition is absolutely true.

Re: Advice for new software devs who've read all those other advice essays

#286
"what advice would you give to xxx"

Other than a means to gain advice, I've found this question a good gauge for collaboration compatibility.

I often ask it in interviews on both sides to give me insight into what someone currently values.

It's sort of like asking someone to define "better" be that in skill, or happiness or avoidance of pain.

My main interpretation of the post would be a high value placed on pragmatism, gained via a journey of experimentation. Put crudely there is no silver bullet but try a few for a while

I think point 10 is highly underrated in my opinion

Re: Advice for new software devs who've read all those other advice essays

#287
post #98

My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!" Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. E…

This is so hard in practice. I just had a junior dev rewrite some of my code so that: a builder calls a constructor which instantiates a builder factory which builds a builder then that second builder creates the object. This whole system only builds one type of object. He thinks that his solution is better because it’s more extensible. I can’t make him see why it’s bad.

Show him this discussion

Re: Advice for new software devs who've read all those other advice essays

#288
post #162

Earlier quoted context omitted.

In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they…

I over-analyze everything and if I actually explained all the reasons the screwdriver should be put away, you would be bored, possibly to death. If you persist in arguing you might hear half of it. And yet my toolbox is still full of things I do because someone I respect did them, or someone I disrespect didn’t, and the outcomes were dramatic. I know the expected outcomes, I have half an idea how they actually work,…

I call this effect “sand in the gears”. Some things are low friction and effortless, others less so. Too much friction and the “machine” seizes.

Psychological aspects are a big part of this.

My pet peeve is overzealous security trolls making IT staff use four layers of VPNs and remote access solutions with multiple glacially slow MFA authentication prompts.

I watched one guy typing into a console with a two second lag on each key press. That’s the round trip time to the Moon and back!

I felt bad every time I had to ask him to do something for me, because his shoulders would slump and he’d have this depressed look on his face as he forced himself to jump through the hoops… again.

Re: Advice for new software devs who've read all those other advice essays

#289

Earlier quoted context omitted.

It often IS your job to write code though, so saying it's not is false. The code has to be the right code however. More generally, "you are solving business problems by applying software systems" That's how I describe this to junior folks. The goal is to make them focus on the business need, then they can sub critical thinking for MBAs/managers/PMs and do the right thing.

I don't mind the way codingdave put it, though. Sometimes it isn't your job to write code. In fact sometimes it's the opposite, and your job is to talk to people and explain to them why code doesn't need to be written. Saying, "It's not your job to write code," might seem technically false, but in terms of getting the message across, I think it's striking and it works well. And getting the message across is the goal…

Agreed. Just like it's not a carpenters job to hammer nails. It can be the job sometimes but other times it's not needed to build something.

Just like solving the problem might be to remove code. Or to inform the user of tools that already exist but haven't been documented enough for the user to know about them.

Re: Advice for new software devs who've read all those other advice essays

#290
post #195
post #162

Earlier quoted context omitted.

In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they…

Had a conversation with a friend yesterday about a case [1] where students at Oxford spent 500 years swearing irreconciliation with a guy from the 1200s as a part of their graduation vows. When it was reviewed in the 1600s, someone suggested removing the clause, but it was turned down. Rules and traditions have reasons, but it is interesting to think about how many we follow all the time without really understanding…

https://en.m.wikipedia.org/wiki/Ivy_League_nude_posture_phot...

Insanity.

Post reply on HN