Choose Shipping Over Using the Latest Shiny Framework | Hacker News Reader

Choose Shipping Over Using the Latest Shiny Framework

shoganai.io

42 pointsshgnio20 comments

Here's a confession: I'm afraid to ship. I'm afraid of being rejected and of being dismissed, and of being seen as a failure. So I bullshit myself that "doing the thing" in the latest and greatest new framework, new language will at least mean that I "learnt something". Failure sounds less irredeemable when you count the dividends of new frameworks learnt!

It has taken me decades to confront this thinking in myself and even now, at times, I run into this logic. It's automatic thinking.

I like the article. You have to be 100% crystal clear that you are interested in the delivery of the finished concept and not the tools you used to build it.

Just remember that that is common and that all businesses are held together with strings and chewing gum, but you can only see yours. The rest are not as polished as they look.

It's really weird seeing advice on getting things done from a domain that's essentially a resigned "oh well."

I'm just worried other people will start catching on that Japanese words make amazing domain names.

If your rent depends on it, I agree. Otherwise, without the exploration, it will bring stagnation. Sometimes it's okay to choose the latest framework.

> Sometimes it's okay to choose the latest framework.

Choose what works.

Agreed, but it can be balanced. Dedicate 1h/d to learning, no more. Balance that 1h w/ new vs current tech. Some technologies really _are_ a major investment; while others are smaller improvements than is worth sacrificing your expertise, as you pointed out.

I've had "1h learning" as a daily task for many years now, it's how I transitioned from PHP to Node. Shiny and hot, yes, but more importantly it's one language across all the work I do, and that saves me _tremendous_ amounts of time from when I was on PHP. That was a worth-while investment. Now I'm using Angular while React is getting hot. I'm not convinced that'll boost my productivity substantially, but I have that 1h/d to learn so why not? If it turns out to slow down my productivity compared to my Angular expertise, then I'll veer that 1h/d towards something else instead (VR + Unity is sounding super interesting, or maybe I'll explore this functional programming stuff everyone's raving about).

Yup. Developers writing about small performance differences between JavaScript frameworks, or the antics of this language over that one. It's gotten to the point where people are actually choosing friends and enemies over what framework they use, what programming language they prefer, or what tools they like.

It's becoming a bit counterproductive. I wrote a post about this because of how often I've come across it that's worth reading: http://room4debate.com/debate/tech-stacks-frameworks-languag....

I think you should have a timeframe. It's ok to try a new framework or language after a couple of years, otherwise you will be stuck on something old. That doesn't mean you must use the newest js framework at all times (probably impossible). You might also start a project where your current framework+langauge is a bad match and then it might be time to try something new. Just budget a lot of learning time for it.

I'm (proudly) launching my SaaS offering using ASP.NET webforms. "Deprecated", "clunky", "not ideal", "at least switch to .NET MVC" are the usual responses I hear from other programmers.

I've got presales, and none of those customers give a shit about the platform.

Nothing is absolute. For new, small projects, choose a new unknown. For a big, important one you obviously don't just jump into something brand new.

Why would you choose an unknown though when there are tons of battle tested frameworks out there? The only reason I can think you would do this is if the framework offered something totally unique or revolutionary, but I really haven't seen that in many frameworks for a long time now.

Then why aren't you using Cobol (I assume you're not) :-)

Seriously it is probably a good idea to look a little at new things and possibly try one out and later switch every few years. I could be after 5 years or after 10 years but you can probably find things that helps a lot with some projects. Regarding the unknown one might want to differentieate between things you don't know and things almost no one knows about (ie very new things), the latter aren't really battle tested yet but the former might be.

Perhaps to learn and be ready if that new and untested framework is ideal for a larger project in the future?

But don't let this line of thinking make you blasé about technology choices.

Oh yeah! False dichotomy and praise of the duct-tape programmer ("The most important thing is shipping"). There is no progress in software engineering, just continuous adaption to broken processes.

So, using a shiny framework, which probably will not work (again!) is "progress"? And using proven methods to ship is what "duct-tape programmers" do? I see a false dichotomy here, but not in the article.

"Shipping" vs. "Using the Latest Shiny Framework" is a false dichotomy whichever way you look at it.

Fuck it, ship it.

Agree! Like they say: You're probably going to be the only one bleeding on the bleeding edge.

Choose whatever takes you to MVP the quickest. Avoid the #beliebers in the echochamber[like this one!]. Choose something that you're familiar with, and probably aren't immersed deep enough yet. So that there is still ground to cover. Usually there is always much to learn.

Focus must be on the MVP and not on the quality of the framework or the hipness of stack. Those things are unimportant until you're ready to hire. Once a bit more stable then play around. Contribute into the system. Push it forward. Avoid stagnation. Have beer. :)

Reply on news.ycombinator.com