Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

buttondown.email

Post reply on HN
Print view View original

311–320 of 361 posts

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

#311

Post by anymouse123456 »

Double_a_92 wrote: post #156
gglitch wrote: post #85

Earlier quoted context omitted.

I think of this as bottom-up vs top-down learning. I get frustrated working bottom-up one bite at a time; I need a map, I need to know the lay of the land and where I'm going. The older I get, the more I sense that bottom-up learners have an advantage, some sort of worse-is-better just-get-started kind of thing.

> I need a map, I need to know the lay of the land and where I'm going. My visual image is a tree. I first need a rough shape of the trunk and branches, before I can start adding smaller branches and leaves. Bottom-up then feels like having a bag of random leaves, instead of a tree.

This is what I mean when I talk about different kinds of brains.

Some of us need a certain amount of clarity and structure before we can feel good. This a great! Especially if we're aware of what we need and figure out how to get it.

Others of us have trouble building from the roots, and we're more effective probing around in dimly lit fog with occasional bits of moonlight illuminating leaves.

Eventually, we may both find ourselves in a well-lit forest, but we approach from different starting points.

The important thing (for me, at least), is to know which path I need at a given point in time and for a given context.

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

#312

Post by asimpletune »

9029 wrote: post #283
asimpletune wrote: post #82

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?

Usually, the best code to read is something that you already need to understand. So, if there's a library you use at work, for example.

Also, for every language there's a really important project written in that language, like SQLite if you want to learn C, or finagle if you want to learn Scala.

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

#313

Post by juped »

cole-k wrote: post #281
juped wrote: post #255

Earlier quoted context omitted.

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 th…

No, I meant that part to be a little mean, and I wouldn't be upset if the other poster had taken offense at that; it's a tradeoff.

I'm offended that they emitted actual word salad at me followed by a random (and actually wildly offensive! or it would be if it made any sense) accusation that was unrelated to anything even close to anything I said.

That's what I mean by "bad faith".

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

#314

Post by wcarss »

cole-k wrote: post #281
juped wrote: post #255

Earlier quoted context omitted.

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 th…

I really respect the effort you've made here to communicate with some empathy and to try to be a help.

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

#315

Post by corethree »

Retric wrote: post #301
corethree wrote: post #285

Earlier quoted context omitted.

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.

I understood what your post was saying, but they they aren’t fuzzy equivalents. The basic premise is just false. Further the quote wasn’t suggesting equivalency. Rather intelligence as one bound on debugging, which is clearly true as can’t get a flatworm to do it. When trying to debug really clever code the easiest solution can be giving up and starting from scratch.

Wrong. A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug. Time and intelligence are both a factor here. Sometimes one more than the other.

Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence. A harder bug often needs more time to solve. This is common sense.

You're just sinking with the ship now.

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

#316

Post by corethree »

hef19898 wrote: post #142
corethree wrote: post #135

Earlier quoted context omitted.

Probably not? So your advice is wrong. You are obviously picking and choosing your documentation based on how easy it is to read. So your advice isnt universal. Clearly you don't fully follow it. There's a lot of contrarian opinions here due entirely to the fact that people won't read certain documents for the same reason you avoid reading the c++ spec.

I don't need to read C++ docs, I am not concerned with it. If C++ is part of your, what's it called, stack, read the part of it that matters for your use case and read those parts directly related to your part of C++ or whatever other language you are using. Do that for every other language in your stack. I never said anything else, did I? How deep and broad your understanding has to be depends on: - your team, nobod…

>your specific use case, I cannot help you with that

I don't need your help. You need it. I'm helping you realize your statement is wrong.

First you make a statement saying one should read all the docs. Now you say devs should read the relevant docs. Devs do the later anyway. Your argument just evolved into the point you're arguing against.

Clearly you didn't mean to do that. You just meant to read more docs then you normally would on topics a little further from the relevancy at hand. But people are responding to you based not off what you meant but what you said.

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

#317

Post by Retric »

corethree wrote: post #315
Retric wrote: post #301

Earlier quoted context omitted.

I understood what your post was saying, but they they aren’t fuzzy equivalents. The basic premise is just false. Further the quote wasn’t suggesting equivalency. Rather intelligence as one bound on debugging, which is clearly true as can’t get a flatworm to do it. When trying to debug really clever code the easiest solution can be giving up and starting from scratch.

Wrong. A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug. Time and intelligence are both a factor here. Sometimes one more than the other. Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence. A harder bug often needs more time to solve. This is common sense. You're just sinking with the ship now…

> A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug.

This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty.

>Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence.

False, you clearly missed me stating it intelligence was “one” limitation not the only limitation. Poor tooling can be a massive pain among many other things. Again though this is talking about debugging a very specific kind of unnecessarily complex code.

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

#318

Post by lynx23 »

TheHumanist wrote: post #58
lynx23 wrote: post #57

Earlier quoted context omitted.

The ability to retain information is mostly fueled by your interest towards the topic, and not by your inherent ability to retain in general. This is what neuroscience has figured out. And it confirms very much my own observations during my life time. Inherently uninteresting topics or things I was forced to learn but which never resonated with me were always difficult to impossible to remember. Things I care about,…

It isn't as much learning as maintaining focus. I struggle badly with that regardless of my interest in a topic.

I submit maintaining focus is also easier if the topic is inherently interesting. However, you sound like yu are describing something like ADHD, which probably needs a more specific approach.

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

#319

Post by wnolens »

Moru wrote: post #289
csallen wrote: post #173

Earlier quoted context omitted.

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.

Decent analogy.

A carpenter solves problems with wood. Sure, they communicate with customers, measure and draw, sometimes say "it can't be safely done"... But if you remove the part where they make a product out of wood, I don't think they are carpenter. They are.. a home solution specialist, something?

If my job was directing others to open source tools and removing dead code, I'm not a developer.

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

#320

Post by hef19898 »

corethree wrote: post #316
hef19898 wrote: post #142

Earlier quoted context omitted.

I don't need to read C++ docs, I am not concerned with it. If C++ is part of your, what's it called, stack, read the part of it that matters for your use case and read those parts directly related to your part of C++ or whatever other language you are using. Do that for every other language in your stack. I never said anything else, did I? How deep and broad your understanding has to be depends on: - your team, nobod…

>your specific use case, I cannot help you with that I don't need your help. You need it. I'm helping you realize your statement is wrong. First you make a statement saying one should read all the docs. Now you say devs should read the relevant docs. Devs do the later anyway. Your argument just evolved into the point you're arguing against. Clearly you didn't mean to do that. You just meant to read more docs then you…

All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it?

Not every statement has to be taken literally, it seems so that on HN, more often than not, one has to be incredibly specific in ones comments. That is like talking to genie or something, really frustrating. I kind of assumed, and without going through all my comments I think I also mentioned it, that by "all the docs" the meaning was all the relevant docs, I even specified that explicitly later on, didn't I?

So, ehy exactly do you think that reading jib and task relevant documentation is not necessary, or even the comoletely wrong approach? Seriously curious, because I run into such people ever so often at work and usually fail to explain to them why they actually have to read that stuff if they want to be a usefull member of the team. Understanding why they have that opinion would really be helpful.

Post reply on HN