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

81–90 of 361 posts

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

#81

Post by brudgers »

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…

  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

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

#82

Post by asimpletune »

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

Also, if you become good at reading code, then you don't need documentation.

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

#83

Post by hnfong »

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 when they update?

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

#84

Post by williamcotton »

The upshot of this is that a lot of the X you hear about have very small Y and will never get wide adoption, but it won't seem that way from how you hear about it. That's why it makes sense to be conservative.

This kind of digital signal amplification is distorting any and all knowledge about our world! These will be known as the Digital Dark Ages to our great grandchildren. What, you say, with access to all this information how could it be? Are we not information technologists? Isn’t the answer obvious? Signal to noise. What’s the point of the information if the message is too distorted by the transfer medium to be coherent?

The trick is then being skeptical without becoming cynical, not to withdraw but to balance. Probably to slow down. Like described by the last word in the quote, to be conservative. Chesterton’s Fence was shattered by an electric truck going 0-60 in 3 seconds, and as wood and stone splintered off of stainless steel and bulletproof glass, we all celebrated the global democratization of politics, labor and information. How do the Arab Spring, Lyft, and Google look 12 years after the party peaked?

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

#85

Post by gglitch »

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…

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.

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

#86

Post by amadeuspagel »

> People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. The same is true of pretty much everybody you'll read.

This is so important and so general. Even writers who make a lot of their real world experience like Nassim Taleb are still read because they are good writers. No one reads Jeff Bezos' letters to his shareholders, because he's not a good writer.

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

#87

Post by myaccountonhn »

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…

While I am not this extreme, I do think that there is value to having a set of tools that you really know and have read the manual for (for me it's git, common unix commands, Postgres and your "main" programming language). If anything, it gives you an appreciation for programming languages that are not only simple to write but also simple to reason about.

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

#88

Post by strken »

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…

I think it's better to read the docs for software you have to touch or are especially interested in rather than everything everywhere in your stack, and this is especially true if you are a beginner. Reading about what you touch makes you a better programmer, while reading about what you like makes you a happier one because your future work will often be in your area of expertise.

If you read at random it tends to send you down rabbit holes, unless you're grounded by applying your knowledge or you have the gist of the subject already. Rabbit holes are delightful if you're interested in them, not so much if you're going down them out of duty.

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

#89

Post by mlinhares »

loloquwowndueo wrote: post #50
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 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.

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

#90

Post by adverbly »

andai wrote: post #70
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…

True. On the other hand, don't try to make things simpler than they are. https://en.wikipedia.org/wiki/Waterbed_theory

True. On the other hand, the reason things are not simple is probably that your requirements are dumb.

https://youtu.be/hhuaVsOAMFc?t=12

Post reply on HN