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

131–140 of 361 posts

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

#131

Post by JTbane »

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.

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

#132

Post by dgritsko »

strken wrote: post #99
hnfong wrote: post #83

Earlier quoted context omitted.

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.

Looks like this might be what you want at least for Node.js: https://nodejs.org/docs/latest-v17.x/api/all.html

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

#133

Post by corethree »

Bjartr wrote: post #106
throwawaaarrgh wrote: post #14

Earlier quoted context omitted.

Excellence is a trap. It leads to hubris. An excellent programmer can be really annoying, and excellent code is unnecessary. Instead of excellence, strive for "working code", collaboration, quality, velocity, improvement, shipping the right thing at the right time. Use debt wisely and move forward.

Excellence is a trap ... Proceeds to describe characteristics of an excellent developer

Right he's talking about a developer who is caught in the trap.

A better way to put it, is a developer about thinks he's excellent. What someone thinks is, the majority of the time, not inline with what he actually is. Especially for developers who think they are excellent. Looking at you Brian Camacho.

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

#134

Post by zaptheimpaler »

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a project that maybe 10 people would use. These are only half the requirements for the "0.3" release with much more over engineering planned for the future. I have stopped working on that project :)

It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.

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

#135

Post by corethree »

hef19898 wrote: post #124
corethree wrote: post #116

Earlier quoted context omitted.

You should try this for C++ and Linux. Read the spec of each cover to cover.

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.

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

#136

Post by williamcotton »

sgarland wrote: post #128
brudgers wrote: post #81

Earlier quoted context omitted.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan

Yes, but (not trying to in any way discredit half of K&R here) it can be useful to write clever code – ideally for personal projects – to both see what the language is capable of, and to learn first-hand why this quote is evergreen.

Clever code should be wrapped up in a parser and you should approach the process problem from a meta perspective, such as Mr. Kernighan did with his help in writing AWK.

Recursive descent, flex/bison, parser combinators… these are the tools to manage complexity. This is why lispers go so nuts once it fully dawns on them the power of manipulating the AST along with any other data structures in the program… it’s just a shame about all those parens!

We’re not writing machine code, most are not writing assembly or even C or Rust. Most hit the memory managed languages and it seems our abstraction has stalled, with endless language features applied to our current layer of abstraction. Its like goto programming before better abstractions were discovered.

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

#137

Post by zaptheimpaler »

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.

Every abstraction for extensible code implicitly assumes certain kinds of extensions and makes other kinds harder. Make him extend it in one of the harder directions :D

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

#138

Post by wsc981 »

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.

Experience will make him see this.

Experience did the same for me.

It just takes some time.

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

#139

Post by mgkimsal »

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.

Or... get them to maintain their own code 14 years in the future. Hard to do in practice, but once you've done it, you get a new perspective.

I got a call from a guy saying "hey, this broke". I had not touched this system in 13 years. I had to re-remember a bunch of stuff. Some of the code was still a joy to work with. The parts that were hard were... obvious, and even then, I remember cutting corners, not documenting stuff, and overcomplicating things "just in case" (which mostly never happened).

There's little amount of someone 'telling' me ahead of time how much difficulty I was leaving for the next person (or even myself). It really seems like the only way to get this experience is with time. That doesn't mean you can't follow some best practices that turn out to be beneficial. But until you've experienced the downsides, you won't really be able to internalize the why regarding something being good or bad.

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

#140

Post by Retric »

corethree wrote: post #112
brudgers wrote: post #81

Earlier quoted context omitted.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan

Not an intelligent quotation. Hardness can be defined as how long it takes to accomplish a task. Following this definition everything can be debugged. It just takes twice as long. This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.

Your premise is false, time to completion and difficulty are not equivalent.

Believing such implies it’s more difficult to ride in an aircraft craft around the world than legitimately beat Magnus Carlsen in a rapid chess game.

The reverse is frequently the case where running a marathon faster is more difficult than doing so slower.

Post reply on HN