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

141–150 of 361 posts

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

#141

Post by rsanek »

JTbane wrote: post #131
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…

This. People don't RTFM, I make wikis that are intended to be used by the team and new hires, I make them as short as humanly possible, even suspending grammar and using sentence fragments. Yet no one reads them.

this might be a discoverability problem. my wiki readers went way up when I linked to it from code as well as relevant internal admin surfaces.

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

#142

Post by hef19898 »

corethree wrote: post #135
hef19898 wrote: post #124

Earlier quoted context omitted.

Of the language? Propably not. The documentation for the piece of software written in C++ you are working on? Absolutely yes. Edit: Regarding Linux, you are propably not touching every function or component of Linux neither. The less you are concerned, the less important it is for you. And less you uave to read it. That being said, a fulltime Linux OS dev propably should have a solid understanding of the complete OS…

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, nobody can know everything alone, it is a team sport

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

- complexity of your use case

- your role, if you are responsible for graphics under Linux, sure as hell you read that part of the Linux documentation, front to end, multiple times and master it

- and, as always, know your system, stack, tools and documentation well enough to realize when you have to look stuff up and where

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

#143

Post by fizzynut »

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…

If ever you work at a place where the software does not make money or is treated as such then you should consider leaving. You will be treated like a cleaner, i.e. it doesn't matter how well you can clean the office if it has zero impact on revenue, they just want the cheapest.

Everywhere else, your worth is the value you generated multiplied by the number of people it interacts with.

The closer or more direct the path is from the work you do to the value generated, the more you will be valued in that company. This is why Sales can be valued so highly, but if you implement X to win contract Y worth Z where Z is a very big number, your worth is quite clear and it's obvious you should move on if you're treated as a cost in such cases.

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

#144

Post by asimpletune »

sanderjd wrote: post #107
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…

Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better , but being able to inspect the run…

It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.

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

#145

Post by ziml77 »

AnimalMuppet wrote: post #111
sjducb wrote: post #98

Earlier quoted context omitted.

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.

Make him maintain one that someone else wrote.

That or make him try to maintain his own code a year later when it may as well have been written by someone else. This is really the only way to properly understand the problem with making all those abstractions. It all makes sense when you have the whole structure in your head but it's very hard to build that mental model back up later.

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

#146

Post by marpstar »

wsc981 wrote: post #138
sjducb wrote: post #98

Earlier quoted context omitted.

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.

Experience will make him see this. Experience did the same for me. It just takes some time.

Agreed. It's "fun" to start breaking your code down into small bits; more interchangeable "pieces" -- until you have to maintain it for 10 years (or worse yet, explain it to a new junior dev) and the extensibility you envisioned never came to fruition and now it's just a liability spread across 8 source files.

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

#147

Post by epgui »

My two cents as a professional engineer coming from biochem:

While computer science / programming is very young and light on the science side, it has solid foundations in mathematics, and the mathematics that are true today will always be true.

So I argue (without providing any proof) that it is almost certainly a good idea to “follow the maths” in your learning journey. I think this is as true for numerical algorithms as it is for functional programming and type theory.

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

#148

Post by HumblyTossed »

Before anything else, learn how to solve problems on your own. I know, we have this huge thing called the internet where everyone else has already solved every problem, but you really need to develop your own problem solving skills and looking up how other people did stuff won't help you do that.

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

#149

Post by cpursley »

raincole wrote: post #103
cpursley wrote: post #26

Earlier quoted context omitted.

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

About once in a month, I google something and find a StackOverflow question about the exact thing... which is asked by myself years ago.

Ha, same. And sometimes I come across a friends issue on github or SO. Always amusing.

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

#150

Post by morbicer »

digitalsushi wrote: post #75
SillyUsername wrote: post #60

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…

The wink emoji is leaving me with the sensation I am out in the dark on something everyone else knows.

I am not sure what the wink is, I think SOLID is mostly solid but my advice is be wary of anyone who is a zealot follower of Uncle Bob :)
Post reply on HN