Hacker News Reader

Comment by jrs95 | Hacker News Reader

As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”...

But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect

View on HN

> But we’ll see if I’m actually following my own advice 15 years from now.

The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months.

I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS.

I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this.

My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.

Ironically, you've just provided an excellent illustration of some real good practices: find tools that are good enough to do the job, only depend on things that are built to last, and concentrate on actually doing that job. The web development world's obsession with constantly moving to the next thing that does essentially the same job as the last thing but maybe 5% better (or maybe not) is a huge productivity sink and best avoided as much as possible. Getting something shipped that's working is far more important than exactly how you made it, and it always has been. If "best practices" aren't helping with that, are they really best practices at all?

While this is generally true, the situation with SPAs is a bit more complicated. Each popular approach early on had a lot of serious issues and pitfalls. IMO React was the first thing to really break through this and while it’s not perfect it addressed the biggest issues Angular and Ember had quite well.

However, at this point, once you’ve adopted React, NG2, Ember 2.x, or Vue, there’s not much to be gained by switching between them. They’ve all sort of gotten past the initial immaturities of the SPA approach.

This is really something you ought to carefully evaluate once and be done with it.

It sounds like your leadership is morons, but you blamed JavaScript?

Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading.

Good luck out there.

Yeah but as a result you could easily write no code at all and not learn from your mistakes.

The trouble is that web development is such a young field and moves so fast (or at least appears to) that the whole idea of "best practices" is fallacious. In many areas, we barely have enough experience to distinguish good practices from bad ones. Even then, most of the good practices that will stand the test of time are about much more fundamental things than which framework or build tool you're using.

It’s definitely not about frameworks or build tools. It’s just about applying whatever you’re using well. It certainly doesn’t have to be perfect, but it should at least be clear that an effort was made.

would work with. don't care if you use them, but at least learn them!

Reply on news.ycombinator.com