Advice for new software devs who've read all those other advice essays • Hacker News Board

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

#51

Post by jstummbillig » Wed, Dec 20, 2023, 1:17 PM UTC

hef19898 wrote: post #27

jstummbillig wrote: post #25

Earlier quoted context omitted.

Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all…

How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…

The margins are infinitely expensive. "As much as possible" has no meaningful boundary, when working in a system that is too big to hold in your head.

Mastery is alluring - it's just not very effective and certainly really bad advice for new software devs, who are in the worst possible position to judge the margins and what is useful.

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

#52

Post by austin-cheney » Wed, Dec 20, 2023, 1:17 PM UTC

dudul wrote: post #8

preommr wrote: post #6

Earlier quoted context omitted.

> 1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. I feel like people exagerrate this idea to prove a point that, ultimately, sales is the gateway to money. Which is fair and important to keep in mind. But, worded like t…

Sales is the gateway to money. Parent never said it wasn't important to build a great product, they said that even if you have the most amazing product if it doesn't sell there is no money coming in. To your point, the goal of "trustworthiness" is to translate into more future sales.

Yes, product quality is important for two reasons:

1. A high quality product reduces the effort on the sales people. It’s nice when a product sales itself on quality alone and it’s also nice when sales can just bank on word of mouth marketing.

2. High quality products cost more to build but less to maintain, scale, extend. That results in predictability that is otherwise absent and expensive.

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

#53

Post by TheHumanist » Wed, Dec 20, 2023, 1:17 PM UTC

hef19898 wrote: post #44

ensocode wrote: post #34

Earlier quoted context omitted.

Work fragmented my brain so much as I am into so many things at one time and I am sure a lot of us feel like this. This comment makes me think on how to actually do that and how much time and efficiency this would cost. Nevertheless there is truth in it. How do you manage this?

Not OP, but that's how I do it (non-software stuff, but tech documentation is complex for any product, and if it is not there is no real problem): - get someone on the team to give an introduction to get some basic knowledge of the system in question, where to find things and what portion of the system affects you - read the documents relevant as per the previous point - read cited documents - start working, and look…

Right, but the original commenter is saying read all the docs, front to back. That's just nonsense.

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

#54

Post by hef19898 » Wed, Dec 20, 2023, 1:18 PM UTC

TheHumanist wrote: post #46

hef19898 wrote: post #27

Earlier quoted context omitted.

How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…

Is it laziness or is it the fact that brains are different and many people (me included) can't absorb that much material and then retain it as well with so many other things going on in our work/lives. I would struggle just to read the entire docs, front to back, of anything in a sitting. Then to retain all that? "lulz" -my brain

The point is not retaining it all so. The point is to remember where to look, and know exactly which parts of the documentation are relevant to you, and retain those. Added bonus if you know owns the stuff not relevant to you and if you understand how those parts are linked.

That is, honestly, something I expect from people in a professional environment.

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

#55

Post by mypetocean » Wed, Dec 20, 2023, 1:18 PM UTC

rcbdev wrote: post #11

austin-cheney wrote: post #3

1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. 2. The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bull…

> The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bullshit realize they have absolutely no idea what they are doing. This relates back to a course I took about software architecture. There's a guy called Johannes Siedersleben who separates software into three blood groups: A, T and 0. According to his m…

I'm struggling to find any information about this, either from Siedersleben or others, at least in English. Can you find any sources you can point me to?

Or, can you explain further? I'm not clear, for example, what you mean by "technical code."

And when you mention "the glue" are you talking mainly about APIs and protocols of all sorts (defined loosely)? This is where the edges of systems coincide and intended side effects reside.

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

#56

Post by TheHumanist » Wed, Dec 20, 2023, 1:18 PM UTC

thedanbob wrote: post #23

> 8. Take walks. I'm fortunate enough to have an office overlooking a small pond. When I'm frustrated I go to my window and stare at the pond for a while. When I'm really frustrated I walk down to the pond and stare at it for a while. I also walk to lunch as often as I can (i.e. when it's not freezing or boiling outside). Highly recommend.

Gotta throw like... two sticks in the pond... or a couple rocks... that will help.

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

#57

Post by lynx23 » Wed, Dec 20, 2023, 1:19 PM UTC

TheHumanist wrote: post #46

hef19898 wrote: post #27

Earlier quoted context omitted.

How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…

Is it laziness or is it the fact that brains are different and many people (me included) can't absorb that much material and then retain it as well with so many other things going on in our work/lives. I would struggle just to read the entire docs, front to back, of anything in a sitting. Then to retain all that? "lulz" -my brain

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, or which interest me greatly, were almost easy to learn. Reading a document about an interesting topic cover to cover is easy. Keep that in mind next time you think you have a hard time learning something.

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

#58

Post by TheHumanist » Wed, Dec 20, 2023, 1:20 PM UTC

lynx23 wrote: post #57

TheHumanist wrote: post #46

Earlier quoted context omitted.

Is it laziness or is it the fact that brains are different and many people (me included) can't absorb that much material and then retain it as well with so many other things going on in our work/lives. I would struggle just to read the entire docs, front to back, of anything in a sitting. Then to retain all that? "lulz" -my brain

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.

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

#59

Post by hef19898 » Wed, Dec 20, 2023, 1:20 PM UTC

TheHumanist wrote: post #53

hef19898 wrote: post #44

Earlier quoted context omitted.

Not OP, but that's how I do it (non-software stuff, but tech documentation is complex for any product, and if it is not there is no real problem): - get someone on the team to give an introduction to get some basic knowledge of the system in question, where to find things and what portion of the system affects you - read the documents relevant as per the previous point - read cited documents - start working, and look…

Right, but the original commenter is saying read all the docs, front to back. That's just nonsense.

Maybe hyperbole, because reading the docs front to end is what I do. Starting with the ones identified as immediately important and taking it from there. Nobody said this is to be done in one session so, it takes time (I am currently in month 6 of such an excersice and can't even tell what I didn't read yet, unkown unknowns and such).

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

#60

Post by SillyUsername » Wed, Dec 20, 2023, 1:22 PM UTC

Lip service is an important skill when dealing with toxic individuals.

If it's unimportant to the project, agree and move on. E.g. "your code is badly written, but we've a tight deadline so I'm letting it pass the review".

If it was a real issue it wouldn't pass, this is usually just stylistic criticism (unless of course you've ignored good practices like SOLID etc ;) ) and indicative of a new senior who still can't differentiate between functional and problematic code issues.