[spidey1]

So how do you go about it?

I've only been in this field for about 18 months and I'm so overwhelmed by all these conflicting ideas and have no idea where to turn.

Do you have any advice for juniors on how to internalise good engineering principles and how to avoid dogma?

[olau]

My personal yardstick is that code should be as easy to understand and take over as possible.

Imagine a future co-worker coming in to fix a bug in your code - that person should ideally be able to say, aha, write a fix, and afterwards nobody can tell you didn't do it yourself.

If an abstraction makes things easier to understand, do it. If it doesn't, don't. Sometimes an extra test can make something easier to understand or modify, or handling more edge cases can make it the code more robust against future uses. But it's always a trade-off: less code is plainly easier to understand.

With that yardstick, lots of hyped tech just isn't good enough, advice given goes plainly against understandability or APIs that may look nice on paper result in hard-to-understand code full of accidental complexity. This applies to a lot of software method thinking too - does it result in me understanding the use cases better or in more understandable code? If not, don't waste time doing it.

By the way, writing code that's easy to understand and APIs that result in usage of said APIs being easy to understand is really hard. I spend a fair deal of my time rewriting code that I'm not comfortable with because it's too hard to understand. If you practice that, I think you might end up as an excellent programmer. Understandability extends to user interfaces and system design - a beautiful program that requires its users to jump through hoops to get everyday tasks done is an abomination in my book.

[PJDK]

Not the OP, but my advice would be:

Read the "classics" - Code Complete, Pragmatic Programmer, Clean Code etc. Google "best books about programming" and you'll find plenty.

When you're reading think about the why. You're job is dealing in complexity and there is no one true way. Understand as many of the different ways as possible.

If you think an idea is weak, try and figure out a question that exposes the weakness (how does this handle a date before 1970?). Expect that sometimes this question will reveal the idea isn't as weak as you initially expected.

Remember you only need to solve the problem that's in front of you. If that problem doesn't seem easy try to break it up into smaller problems.

Complicated solutions are often bad solutions.

Complicated solutions can be good solutions.

Write your code for people to understand.

Advice on good writing is often very applicable to code... See Orwell(1), particularly "Break any of these rules sooner than say anything outright barbarous" 1.https://www.writingclasses.com/toolbox/tips-masters/george-o...

[yakshaving_jgt]

- Become proficient in Vim or Emacs

- Get comfortable on the command line — it's almost a running joke now that modern tools are often outperformed by awk/sed/grep/cut/etc

- Go through the book 'Seven Languages in Seven Weeks' — You won't thoroughly learn those seven languages, but you will learn how to learn programming languages

- Get good at recognising hype and reducing marketing language to their core ideas. This seems especially applicable in the JavaScript world (though this may just be my confirmation bias speaking)

- Get good at accurately defining the problem you intend to solve. This would seem so fundamental that it isn't worth mentioning, but you'd be surprised how often people jump to "Ah! An excuse to play with shiny new framework/tool/languge/whatever" before knowing what it is they're solving

Most of these seem quite fundamental, but you go an awful long way in this industry on fundamentals.