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

151–160 of 361 posts

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

#151

Post by Double_a_92 »

danielbln wrote: post #43
anymouse123456 wrote: post #37

Earlier quoted context omitted.

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…

Same here. If I were to read docs cover to cover, not much would stick in my brain. I need top down research, start high level, and drill down where ever I touch base with practical applications. It's why I find interacting with LLMs so pleasant (ignoring their shortcomings), because I can learn exactly the way I want to and the way that works well for me.

The knowledge from reading all the docs won't be really "usable" but it gives you a vague, almost subconscious idea of all the things that exist and how they interact with eachother.

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

#152

Post by HumblyTossed »

liampulles wrote: post #108

If you think that you've potentially fucked up big, seek help and own up immediately. Phone the person if they are not responding to messages. Everyone expects juniors to make mistakes, you'll earn respect if people know they don't have to worry about you delaying or trying to hide issues. Also, ask questions! Again everyone expects juniors to lack knowledge, and yet something about our schooling makes us embarrassed…

> If you think that you've potentially fucked up big, seek help and own up immediately.

Also, if you think you might fuck up big, partner with someone else first.

"If you're going to go down, bring people with you."

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

#153

Post by roland35 »

mightybyte wrote: post #65
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…

> Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. I think there are times when this works and there are times when it will be a huge waste of time. In general, I think it's often very hard to tell which approach will be more efficient for you. As some sibling comments have mentioned, I think the way each person's individual brain works is a significant factor, bu…

I think a better approach is to be prepared to read the documentation a few times.

For me, the first time I mostly glance through and see the entire scope of things. I normally need to work with things at least a little bit first to really be ready for a more indepth read later.

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

#154

Post by Jensson »

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…

In general it is almost always better to learn using multiple styles instead of just one, if you prefer to do A then don't just do A but also try to do some B to improve your learning. Learning based on solving specific problems is good to get experience, but it is not good to get an overview of a field, you really want to get good at both the overview and the nitty gritty.

Also the purpose of reading a book isn't to become a master at implementing details, it is to get a good overview of the subject. You still have to practice implementations afterwards, but by having seen everything before your mind will now slot all problems much better and be more confident as you work through those implementations instead of looking up random advice on the internet.

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

#155

Post by thfuran »

zaptheimpaler wrote: post #120
rTX5CMRXIfFG wrote: post #95

Earlier quoted context omitted.

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.

This is broadly what reasonable people believe, but there are crazy people who WILL obsess over form and nitpick your whitespaces or other trivial bullshit if given a chance. An authoritative style guide shuts down many such detours.

It's not even just about obsessive nitpicking. There are people who, for example, prefer code with spaces around the parens for conditions and people who don't. If there's no enforced style guide and one from each camp end up touching the same code, you're likely to get a bunch of pointless noise in the diffs. Even if no one is going to hold up a diff arguing over it, it makes it harder to review changes.

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

#156

Post by Double_a_92 »

gglitch wrote: post #85
anymouse123456 wrote: post #37

Earlier quoted context omitted.

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…

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.

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

#157

Post by bvirb »

sjducb wrote: post #98
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.

We came up with a rule “no single use abstractions” so any abstraction with a single caller gets absorbed by its caller. We eventually had to say except across MVC boundaries (the project is MVC organized) or else we got some weird code organizations (controllers consume everything). It works pretty well though, in some cases we have some long methods, but really killed the premature abstraction “this will be useful in the future” discussions that eat a lot of time and energy. I think having a simple rule for everyone makes it easier to follow.

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

#158

Post by lolinder »

sjducb wrote: post #98
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.

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

Schools teach OOP as though adding new types of objects is the norm—like every type of software construct is actually a GUI widget in disguise and we're going to be adding new interoperable subclasses every other week, so we may as well get the infrastructure set up to make that easy.

In most real world applications, the only type of object that behaves that way is, well, GUI widgets. Nearly every other type of construct in a typical system will have at most one implementation at a time (possibly two during a gradual transition). Factories, builders, and the whole design pattern menagerie aren't particularly useful when for the bulk of a system's life they're all just proxies to a single constructor.

I don't know if there's a good way to teach this out of someone besides just letting them experience it, but that's the insight that he needs—different types of code have different maintenance characteristics, and the tools he's been given were developed for a very specific type of code and don't apply here.

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

#159

Post by Jensson »

jackphilson wrote: post #127
danielbln wrote: post #45

Earlier quoted context omitted.

Because mental capacity is finite, and knowing as much as possible doesn't work for everyone, especially if it's disconnected from actual problem solving. Reading a book cover to cover and have everything in there stick in the mind is great if it works for you, but there are plenty where it does not.

The problem isn't that mental capacity is finite, it's not (or the limit is too high to be relevant). The problem is that by spending time learning esoteric knowledge, you're only displacing time for more applicable knowledge.

It saves you time, reading is quick, debugging without a good understanding is extremely slow.

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

#160

Post by yakshaving_jgt »

max_sendfeld wrote: post #62
loloquwowndueo wrote: post #50

Earlier quoted context omitted.

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

Absolutely! I'm grateful that I don't have to worry about code formatting any more. But I remember in one of my earliest job the company used style checkers as a pre-commit hook that rejected your commit if they found trailing whitespace. That was before code formatting was part of your IDE. (Especially for us front end devs who used Notepad++ rather than an IDE at the time). And notepad++ had no easy way of showing…

What's stopping you from configuring your editor to automatically strip trailing whitespace on save?
Post reply on HN