-
I absolutely need tutorials for every-freaking-thing, especially if I intend to not retain any of the knowledge and/or wisdom I accidentally stumble upon while following the tutorial, which happens most often in domains where I have no intention of cultivating expertise.
Granted, those mostly happen to be tasks that require my hands to manoeuver something else than a keyboard, like “how do I sand a wooden floor”, or “how do I install a new wall socket without zapping myself dead”, or “how do I make bread”.
If I want to retain expertise, I’m going to seek out introductory material to the matter at hand. And I’m going to pay attention.
-
The article specifically covers the “making X application” kind of questions (and it says so in the opening), so a more appropriate analogy would be “how do I build a two-storey apartment with blue walls and disco ball lighting”.
Questions that you listed are way more specific and relevant. But when people ask “how do I build a X app”, what they are really after is how to get there, but they don’t realize they need the exact tutorial for that (nor there is one).
A tutorial on building an apartment, an article about caveats of two-storey ones, a video on painting the walls blue (or any color), and tips for sticking the disco ball to the ceiling would be separate, reusable pieces of content that could be used to answer “how do I build a two-storey apartment with blue walls and disco ball lighting”. Splitting a big problem into smaller chunks, and looking THESE up is where it’s at.
-
Until you can analyze and decompose a problem, you’ll remain a beginner because you’re unable to help yourself or ask meaningful questions that are respectful of other people’s time. This will also limit the size of what you can build. That is fine, you need to put the time in to advance and learn the physics of building software.
Additionally, I suspect the “making X app” tutorial requests have a “do the hard part for me and let me brand it as my own,” quality to them. I’m sure there are some legitimate requests there, too, but the hype of tech has brought in people who are work vampires and thirsty to Get Theirs: “All I need is a YouTube video on how to make my own social network, then I’ll compete with Facebook!”
-
work vampires
Saw the point you were making, scanned for the word vampire, wasn’t disappointed.
I’m trying to do something to encourage and enable programmers to be more independent with the Almanac, but it’s really only for intermediate-or-advanced Haskellers.
-
-
-
-
-
-
I think you slightly missed the target. I would propose you don’t need a tutorial for any-freaking-thing, if you are Doing It Right (which nearly no one is, ever, especially not me); and that your ‘tutorial’ is a class of behaviour which includes e.g. cutting and pasting from Stack Overflow.
Either you know how to use a tool or you don’t. If you don’t, you can read the fucking manual and gain that information, or take a shortcut that may allow you to get something done with less than complete information about how or why it works.
I think the actual situation is more complex than your analysis:
- Tools are incredibly complicated, and often have nuances and details that are hard to discover without R'ing a lot of TFM
- Because there are common use cases which can be labelled succinctly in English, and magical incantations (a combination of input to the Tool which does not need to be fully understood to work) which work reliably for these use cases, it has become a behavioural norm to search for the use case and just apply the incantation.
- Reading manuals, understanding the architecture of your tool properly is hard and long and boring and why would you do that when you want to get paid with minimum applied effort?
The result of this is that it is possible to use the tools without understanding how they work because the incantations are readily accessible, and that sucks because it allows people with very low levels of skill or knowledge to initially use the tools in a superficially similar way to people who understand them and/or RTFM.
Rendering a list? Well, it’s more about rendering arrays, and that is a solved problem. You can google “react render array” easily!
This isn’t solving the problem at all, you’ve just slightly shifted the point on which your lazy programmer is looking for an incantation. The proper direction to give them, if you care about them being a good programmer is that they should understand the tool they are using well, and in this case the only correct direction to give them is: if you don’t know how to do something with react, RTF react M.
-
I’m focusing specifically on the “making X application” class of the question, which is always an indication of not being able to split the problem into smaller parts and research on that… like when you need a specific app and want to be shown how to make it.
Tutorials for specific tools and libraries and ideas are still viable — but it doesn’t matter so much which specific app the tutorial happens to build, it’s circumstantial.
-
It took me several years (and many conversations) to realize that there are many different ways people learn things. Back in 96 (or maybe early 97; it was just a couple of years out of college) I was tasked with writing a meta search engine (a search engine that sent queries to other search engines) in a language I was not familiar with (Java) on a platform I’ve never programmed before (Windows 95). I didn’t cry over the lack of tutorials, I just dove in, but that’s how I work (growing up, I only had one other friend that had a computer and it wasn’t the same as mine—oh, and no Internet). It was odd to see just a few years later seeing requests for tutorials on writing meta search engines (it was thing back then).
-
Writing, lots of writing. Finished and published a JS generators piece over the weekend. I have 80 other blog ideas that I have to get around to writing…
Other than that… React day in, day out. Have my first client project in React Native coming up shortly and I’m pretty excited about it. The DX is absolutely paramount. “Learn once, write anywhere” holds true… mostly.
-
I’m Gosha Arinich. I taught myself to code when I was 10. When I was 15, I was surprised to make my first 3 hundred bucks with code. Since then, I’ve been consulting and helping businesses with code. MVP development among other things.
My bread and butter is web/mobile development with Ruby and React. I love software design and architecture, and I really dig functional programming.
Love helping others learn so I’ve recently started blogging about Rails and React, mostly focused on newcomers, although I’m still trying to find my voice & place: http://goshakkk.name/
A corollary for this is “you don’t need a library or gem for every freaking thing” (or, at least, you don’t need the library you think you need). A lot of less experienced developers I know, if they want to do something sufficiently complicated in, say JavaScript, will google for about 5 seconds and then choose the first jQuery plugin that comes remotely close to what they want to do, effectively copying and pasting some code into their app and then proceeding to hack the plugin to do what they want. I know this is a way to get going quickly, and if that’s important to you and you don’t have another option, then that’s what you have to do. But if you have the time, it’s better to take a step back, think about what you actually need, read about different approaches, and try to find a smaller piece that you can use more easily. Of course, it takes experience to know how make this kind of decision, but you also have to spend the time understanding the code you’re about to use and what problems it solves rather than throwing it into your app and seeing what happens.
Another common problem with less experienced developers and libraries is adding the libraries without experiencing the problems they solve.
I still see it often in the React community that people who are just getting started with React are trying to smash all sorts of things into the mix; state management (Redux, MobX, etc etc) is a super common one. Newcomers see mature projects using these and kind of assume they have to use these as well, without realizing what problem these solve. The end result is: people don’t know when one thing ends and the other begins, which only does them a huge disservice further down the line.
So there are two different classes of YAGNI here: reaching for a quick solution and trying to Stay Cool™. From where I stand, the latter seems even more prevalent in the React community.