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.
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.
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.
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.
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.
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. :)
[+] [-] ak39|10 years ago|reply
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.
[+] [-] tomjen3|10 years ago|reply
[+] [-] sdrothrock|10 years ago|reply
[+] [-] forthefuture|10 years ago|reply
[+] [-] acconrad|10 years ago|reply
[+] [-] kluck|10 years ago|reply
Choose what works.
[+] [-] lefnire|10 years ago|reply
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).
[+] [-] crymer|10 years ago|reply
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....
[+] [-] jbergens|10 years ago|reply
[+] [-] robodale|10 years ago|reply
I've got presales, and none of those customers give a shit about the platform.
[+] [-] fredsted|10 years ago|reply
[+] [-] meddlepal|10 years ago|reply
[+] [-] beefsack|10 years ago|reply
[+] [-] ExpiredLink|10 years ago|reply
[+] [-] sgift|10 years ago|reply
[+] [-] necrodawg|10 years ago|reply
[+] [-] monsterix|10 years ago|reply
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. :)