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

21–30 of 361 posts

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

#21

Post by random_kris »

throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

These two points (docs and looking at source code) Started working for me only few years into the career, when I had a really good grasp of foundations

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

#22

Post by itg »

billy99k wrote: post #18

A beautiful piece of code will always be outshined by something that works reliably and well.

When I was younger, I was obsessed with writing clever code to show off my programming knowledge. Over time I realized code that is easy to understand is much more valuable.

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

#23

Post by thedanbob »

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

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

#24

Post by aleph_minus_one »

codingdave wrote: post #10

The one I have a hard time explaining well enough for new folks to get is: "It is not your job to write code." We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop codi…

> We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out.

I am not sure whether this is a good advice - for a quite subtle reason: I do claim that most code (including most of the code that is written "for code's sake") does solve a problem, and most programmers at least unconsciously are aware of this fact - and that's why they write this "code for code's sake".

The issue rather is that other people (say, "the suits") want that the code solves a different problem than the one that the code solves.

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

#25

Post by jstummbillig »

throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

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 and your best bet is getting efficient at poking them to figure out what's going on.

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

#26

Post by cpursley »

throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

> encyclopedic knowledge

This only works for people with excellent long term memory. I constantly need to look things up in docs and even my own readmes.

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

#27

Post by hef19898 »

jstummbillig wrote: post #25
throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

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 from others without understanding the smallest thing about it. This is something LLMs excel at, for free. The former not so much.

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

#28

Post by hef19898 »

cpursley wrote: post #26
throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

> encyclopedic knowledge This only works for people with excellent long term memory. I constantly need to look things up in docs and even my own readmes.

But you know where to look it up, right?

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

#29

Post by gwervc »

throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.

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

#30

Post by hef19898 »

codingdave wrote: post #10

The one I have a hard time explaining well enough for new folks to get is: "It is not your job to write code." We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop codi…

That is the difference between real engineering (solving technical problems) and "engineering". Thanks for putting better than I ever managed!
Post reply on HN