programming is terrible

I would like to point out a possible problem with the generic advice "read books" "follow blogs etc."

=> technological bias

As you are from Node/Express and Mongodb background the biggest risk is trying to become only better in these technologies. So you will only know how to make faster horses, how to train them for the best, but you will never learn car exists.

More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper.

Try to challenge the status quo ? Why MongoDB? What kind of alternative do you have ? Same for Node + Express.

Doing so will force you to see where your tool shine and where it reach its limit. Doing so will permit you to know when you need to dig deeper on "how to use better this tool", and when to step back and "wait a minute, no amount of best-practices/knowledge will balance the fact that MongoDB is just no the right tool here"

So read a lot, but also from people that are not from your community (and to be honest HN is a good starter on getting different point of view)

The other important things is about perspective, it's not because a googler/guy from netflix wrote about how they needed to split the code in microservices, or needed to implement $design-pattern-with-a-very-cool-name that it does apply to you.

Especially looking to the size of your dev team, I think the worst things that could happen to…

> I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions.

They support my argument so I included them. I don't see a practical difference between a "random HN user" and a random blog post or anything else. A good idea is a good idea, regardless of the medium.

> I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell

Possibly, I threw it together pretty quickly, so it's not very thought-out.

> (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python).

It's not binary, but a spectrum. No language has just literally one way to express each concept. However, Python is definitely further towards the "one way to do it" end of the scale. Perhaps not as much these days as it used to, but still far more than for example Ruby or Perl.

> I feel like you missed my larger point. It's not terribly difficult to write code that you can understand line by line. It's incredibly hard to write a huge code base in a way that you can reason about many code paths simultaneously, however. That's where the abstractions start to make sense.

I thought I adressed that; everything I mentioned - explicit error returns, pure functions, no global state, and no metaprogramming - all show their true worth in large and/or unfamiliar codebases.

> I don't understand why people think…

I really agree with the quote, especially after spending some time in a huge enterprise codebase (1mil+ files). Writing reusable code usually means writing an abstraction layer. However, if you always write an abstraction layer, you will end up with a ton of abstract code with only one concrete implementation. Abstract code is harder to read and modify, so you do pay a cost when it comes to maintenance. Also depending on the language you may pay a runtime cost also. So if your goal is always to write reusable code from the start, you pay an investment cost that may never show any returns.

This idea pairs well with another Knuth quote regarding premature optimization being being evil [1]. Code reusability is a form of optimization of developer time. Writing reusable code with only one implementation is like optimizing a function that does not impact performance. You think you are doing something good because programmer dogma says its good, but in the end its not.

Here is another related article that does a great job talking about maintainable software, and some of the contradictory advice you will hear about it [2]. But the main point is that code is transient. We tend to write code with the idea that it may run in production undisturbed for decades, but that is not the case. Refactors are common, and most people will do a better job rewriting code from scratch than trying to modify your code. So do them a favor, and make it easily replaceable instead of easily modifiable,…

Sounds like a restatement of Postel's robustness principle[1]. Did it go out of style to "be conservative in what you send, be liberal in what you accept" and we need to relearn it again?

Well, perhaps it did. History has shown the dangers of not handling malformed input well. Postel's principle has received scrutiny[2] for reinforcing those mistakes by creating a mistaken belief in robustness. More recent recommendations have been to be stricter in handling of inputs[3].

But I think there is some confusion between robustness and defensiveness. "Be liberal in what you accept" may be confused with "don't sanitize your inputs" when not sanitizing is the less liberal action. Robustness means the program should not fail if it receives input it didn't expect. A program that crashes, hangs, executes unintended shell code, mangles the data, changes the thermostat, or other undefined behavior is not being robust. To prevent that from happening then data must be sanitized at input so that it can be processed without those side-effects. The examples of programs failing robustness have been because they were insufficiently defensive.

The bigger issue is that robustness doesn't scale easily. You may know how your bit of code will deal with malformed data, but what about every other library you use? Or other systems you communicate with? It becomes a backstage problem, where once someone has gained access to a restricted area it's assumed they are authorized to be there. The further…

This isn't a negative, self-worth thing, it's a perspective thing.

What the OP here is describing, is exactly the mentality that leads to this nonsense: http://programmingisterrible.com/post/50421878989/come-here-and-work-on-hard-problems-except-the-ones

A lot of people would agree that empathy is one of the large components of what makes us "human", and that's rather vague, but it does make evolutionary sense for why empathy is useful for societal progress. And guess what, perspective is crucial for empathy. If we assume for a minute that almost nobody really lacks empathy, then what could be the only possible factor that produces an outcome like the one described in that link above? I'm sure most of us tech people aren't narcissists/sociopaths, so the only thing that could explain it is a skewed perspective that makes it permissible to rationalize a lot of the nonsense around us as being 'okay', or 'not relevant' to us. Empathy is a function that takes perspective as an argument, and if we assume that our empathy functions are correct (no reason to think they aren't usually), shouldn't it be good when we realize it's giving us the 'wrong outputs', and then do something actionable about it like try changing our perspective (or input)? I've battled with a lot of self-criticism and depression myself, but I see nothing wrong with this. On the contrary, it seems like the healthiest thing we could do as we approach a possible 'bubble' scenario.

I think the problem is…

Assuming you mean in the computer realm, write code. Make it do things. Figure out how to debug it. Have fun.

I'm not being sarcastic. There's no particular point in trying to pick up particular skills. The specifics you pick aren't going to be marketable no matter what; what matters is the general skills you pick up and how quickly you can leverage them to learn later.

I'd recommend avoiding hyperspecialization; it's kinda easy for a 13-year-old to become something like a master expert with RPG Maker or something, but unless that's your end goal, that can kinda be a bit of a trap. (You end up with an understanding of computing too bent around local considerations and get too much time into learning hacks around them, and mistaking them for fundamentals. When Dijkstra was complaining about BASIC [1] this is the sort of thing he meant. If you spent too much time learning how to deal with the limitations of 1970s/1980s BASIC you came away with some really bent ideas of how to do good programming.)

Oh, and try to avoid putting any sort of dynamic website up on the internet if you can avoid it. Web security has gotten quite hard. If you want to build a website I recommend static site generators; you learn a lot of good stuff applicable to web development, but security is a near non-issue.

(And for the love of all you consider holy, stay away from cryptocurrency.)

[1]: https://programmingisterrible.com/post/40132515169/dijkstra-basic