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

91–100 of 361 posts

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

#91

Post by masfoobar »

Agree with many of the points raised in the link.

Mine are simple -

Leave your ego at the door.. especially if you are a new/young talented or "prodigy" programmer.

Take any criticism on the chin. Be open minded and learn from it. Chances are they are not being negative towards you or your coding solution. In this indistry, people are going to be direct with their choice of words.

Be honest. If you dont understand, ask for clarification. If you are writing code or using some library you have not used before - let it be known. You are not saying "you cannot do it" - imply you are excited to challenge and learn. Most young devs are generally like this.

Co-workers will come in all shapes and sizes, and range from social to anto-social, alongside introverts or somewhere on the spectrum. I always try to meet-in-the-middle with everyone in this field.

Feel free to raise concerns or ideas but at the end of the day respect the decisions being made even if you do not agree with it. People above you like seniors, leads, etc, have experience and may have got through past projects and know things. Of course, if you are "correct" in many ways, I am sure you will be recgonised (eventually) as you gain experience yourself.

All this said and done --- Always be patient and dont worry if you are not "making an impact" in your department. Good things come with age.

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

#92

Post by jerf »

anymouse123456 wrote: post #37
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…

There are some brains that do very well with this advice, but mine is not one of them. I only seem to learn by moving back and forth between solving a real problem and finding just enough information to move forward one step. After some period of this, I'm usually able to read (and understand) a book or two on the subject, but never before. Maybe I'm a tactile learner? Not sure what to call it, but if you're not sure…

This may seem like splitting hairs, but both to you and to anyone in a similar situation, consider instead "skimming" the documentation rather than "reading" it. A lot of times the value of that first "reading" is just in getting a sense of what can be done and an idea about where it is documented. Certainly not memorizing how to do it on a simple read. There's a very popular unexamined idea that people retain things by reading them once and then will forever after retain it, but that idea is obviously stupid once I drag it out into the sunlight and point you at it. That's not the goal of a first read, and it's not what the vast majority of us get out of a first read. (Anyone who can operate that way is invited to make their own plans and let us normies discuss how to deal with our normal reading retention levels.)

I probably "skim" the bash man page once every couple of years and I still find new things that I blipped over every other time.

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

#94

Post by sanderjd »

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…

An interesting corollary to this that first starts hitting hard at the early mid career level and never quits:

"It is not your job to write slack messages". (Or emails, depending on the company.)

It can really feel like it is! Very much like the code one, it often feels like, well, this is the work; answering questions, collaborating, influencing the direction of the team and organization.

And communication is indeed important. But again, much like code, it's a tool that is used to create useful things, it's not itself the useful thing.

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

#95

Post by rTX5CMRXIfFG »

mlinhares wrote: post #89
loloquwowndueo wrote: post #50

Earlier quoted context omitted.

I think an automatic code formatted actually makes one’s job easier, not more complicated.

That completely removes a whole slew of useless comments when people are reviewing code, it's such an amazing win, every single language should have it's styleguide published and a tool that forces it without any options.

The key to style guides is to not have so many rules. Agree on the number of spacing and where to put braces. Past that, it’s obsessing on form over function, which you cannot control simply by virtue of having many people work together on the same codebase.

You should worry more about how things are named, the number of abstractions used, and whether the code has any comments explaining the writer’s intent.

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

#96

Post by hasty_pudding »

wolframhempel wrote: post #31

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…

I think good software like good algorithms is made from simple patterns that do complex things.

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

#97

Post by Grimburger »

wolframhempel wrote: post #31

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…

> 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. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply!

Know plenty of people who call this job security

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

#98

Post by sjducb »

wolframhempel wrote: post #31

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.

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

#99

Post by strken »

hnfong wrote: post #83
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…

C++ 20 - Number of pages : 1853 ( https://www.iso.org/standard/79358.html ) Python language - Number of pages: ~206 ( https://docs.python.org/3/download.html ) Python standard library - Number of pages: ~2337 ( https://docs.python.org/3/download.html ) I don't know, but I have a suspicion you haven't read these cover to cover. Or maybe you have, for the latest version 10+ years ago. Is your advice to read the diffs w…

I've read the Go spec. It's short and sweet and doesn't include the standard library, though.

https://go.dev/ref/spec

Also the ecmascript-262 spec version 5.1, also known as es5.

https://262.ecma-international.org/5.1/

They were actually pretty interesting reads, and not too long. Maybe I should see if there's a PDF of the Node.js and Go standard libraries.

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

#100

Post by raincole »

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…

You probably severely underestimated how long documents are today.

Also reading something cover by cover is not enough to retain the information. Not even close.

Post reply on HN