The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness": http://paulgraham.com/schlep.html
The problem runs deeper than that even. Even if you like doing stuff that requires more effort, it's shockingly difficult to find places/people who want to invest/hire you to work on such technology. You have essentially a choice between academia (which is, well, sometimes very academic) and large corpos which have their own share of problems and not everyone fits.
And even in big corps, 95% of all IT is usually plumbing and hectically applying band-aids for past issues that should not have been there in the first place.
To me, the fact that IT is currently seen as rapidly progressing is laughable. It is rapidly changing, true, but for the most part we're solving old problems with new tools that work only marginally better than the old tools (because, like the article says, the underlying mentality is the same). Very often they change fast enough to keep everyone always "learning" at the expense of the users, so the marginal benefits are cancelled out.
(Seriously, I know people who made the same excuse for bad quality for the last decade. "Oh, I'm just learning [over-hyped tool]. Everyone makes mistakes at first." Learning tools is a fake kind of learning. Real advances happen when your conceptual basis is improved, so you get better at doing something with whatever tool. That's real learning. )
---
Also, sometimes we're using new tools that work significantly worse than some old tools.... because at some point conceptual development branched and "our" branch is at the same level of development as another branch was in, say, 60s or 70s. Sometimes I read about old tech and it just blows my mind. "What? They've been doing this three decades ago? How come this is marketed as awesome new thing right now?"
There is another option: work for a salary, live frugally, and stockpile savings. Then later (maybe 5-10 years later), work on the tech you really want to work on that has no obvious & immediate business need. The upside is that because no one invested or hired you to work on it, you own 100% of that work.
Also, make sure you are (a). young (< 30yrs) (b). have little to no responsibilities (family, kids) (c). have great healthcare or health insurance and (d). lucky as a little green leprechaun!
Yea, if you have met all those conditions, then that approach may work for you.
I think many people confuse "ship it" culture with just doing crap work. I've seen too many ship it projects die because the biggest feedback from the customers was "This thing doesn't actually seem to work" or "This is useless". Ship it can apply to hard problems as much as easy ones, it's more about not doing extra work before you know what your customers want. But if you MVP it to the point where it barely works and has no real functionality then customers will often view it as trivial and useless and you'll likely confuse missing product market fit with under delivering.
Perhaps ship-it-now is the right answer for the times. With so many rapid changes in technology there should be 1) a lot of low-hanging fruit (i.e., quick, high-value solutions), making short-term project more valuable and 2) a shorter shelf-life for any solution (i.e., a new tech will make it obsolete), making long-term projects less valuable.
I wonder if ship-it-now isn't more a reflection of the times, rather than the right answer.
"Pick off the low-hanging fruit" works for a shop looking to turn some mad profit without having to do a lot of deep thinking. And that's certainly fine. But if that's the culture of the industry, we'd be sacrificing progress and innovation for a quick and ephemeral dollar.
There's a quiet theme that runs through the community here, and tech in general, that suggests everything that's new is often just old-again. A lot of these "rapid changes" really do feel like reinvention and change for its own sake, and seems plagued with the same issue as above -- building new iterations on existing ideas, picking off low-hanging fruit but not really going anywhere.
edit:
The problem is that these technologies, being so beginner-friendly and aggressively marketed, rapidly pick up steam and become the “cool” things to use, regardless of actual merit or lack thereof.
This line hit it on the head for me. I've been in the business for a while but have only been programming directly for a fraction of that -- I can readily admit, a lot of the newer JS libraries and frameworks made me feel like a superhero with almost no proper training or understanding of computer science.
The problem with that proposal is that we're currently waiting until all of the low hanging fruit got picked. I'm no masochist - if there are nice fruit on the bottom branches, I'm going to pick those. The problem is that the low hanging branches have been picked of all their nice fruit, just leaving the sour, the rotten, and the immature. We could start putting in the effort and climbing the tree for the nice, ripe fruits at the top, but we're being lazy and waiting until we've picked every last worm-filled mush at the bottom.
To further the analogy.. as soon as the fruit on the low hanging branches becomes bad enough to justify the additional effort of climbing the tree for the better fruit, people will do it.
Your argument makes it sound like you're saying no hard problems are being worked on currently, which is simply not true.
To continue the analogy even further - ... not if people instead invent ways to paint the crappy fruits so that customer buys them anyways. Happens all the time in every sector. As industries mature, products get crappier.
On this tree called "life", new low-hanging fruit grows every day. It's a reason we see such churn in the sorts of tech that keeps solving the same easy problems in different ways.
The only reason why there is low-hanging fruit is because you need to reimplement solution in the tech du juor to problems that were solved 30 and 40 years ago.
technologies change quickly because everybody wants to ship fast and put out something just good enough to be better than the last half baked solution that was shipped because technologies change quickly.
Maybe that depends on who's uttering the phrase and what it means to them. Some points in the space:
- "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere).
- "Devops" as "oh look, we can hire less people and just get some 'devops' to do it all."
The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".
Devops can definitely be used as a very expensive bandaid around poor engineering practices.
But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?
When implementing a failure-tolerant system, one has to remember that "crash" can often be parlayed into "exploit" or at least "denial of service", and thus not become too tolerant of failure.
But isn't that what all systems engineering is all about? Feedback loops with resiliency. Why is it that the software folks think they have discovered something new?
DevOps is an integral part of Continuous Deployment. I am not sure why methods used to make deployment of software more frequent and less error prone should raise anyone's hackles. I guess it is not understanding what DevOps is and what it is trying to achieve.
You pretty much answered yourself right there in your comment. See how you capitalize "Continous Deployment" and "DevOps"? That's because they're recently invented feel-good buzzwords.
That's the one. That's basically short hand for "you don't need to do anything really well, you just need to do everything barely good enough to ship it now".
The sad bit is that many full-stack developers are actually better that specialized developers in respective skills. (unless of course they are JS/Node.js types)
Which really means "OUR stack developer, being a subset of the full-stack in our particular narrow domain, going as high as we go, and as low as we go".
I agree and that's exactly what job adverts should say. Spell out the stack and the amount of experience required. None of the nonsense with vague phrases like "full-stack developer".
