A book I think is crucial is Creativity, Inc. (the Pixar book). The most important piece of its perspective, I think, is the idea that managers can screw things up in a bajillion ways, and that it takes consistent work and focus to create an environment where people WANT to bring up problems, WANT to bring in ideas, and WANT to do their best work.
Another valuable book is Moral Mazes -- it's a tough read, but the takeaway is that managers are almost universally insecure, like INSANELY insecure, because they don't really produce something tangible, they produce the feeling of stability and predictably and (most important) loyalty in THEIR managers, and how the heck do you measure that? They're always one misunderstanding or failure to anticipate a problem or to quell some fussing away from being fired, or shut out of promotion. They exist in a terrifying state of status uncertainty. If they're not careful -- like REALLY, REALLY, affirmatively, pro-actively careful -- they'll create an environment where the people under them, who have front-line knowledge to bring, will suppress problems and avoid difficult conversations because they'll know how upset their manager will get. This can be incredibly costly. A good manager has to be brave, not just for themselves, but for those under them who need bravery to speak up. And that manager needs to go to bat every single time someone under them is right -- even if it costs the manager their job.
Of course, few managers understand this advice or have the slightest spine to stand up for what they (internally think they) believe in. It's much more common to find managers who deal with "the wrong person" under them having a good point (and feeling embarassed, or worried that a superior will feel embarassed) by covering for it by getting angry.
I really liked this -- it's so true about my road to programming (pseudo-) expertise. Almost everything I've been paid to do, I first did on a hobby level, just messing around with my own projects and ideas.
The "what do we do after Scratch" question is tricky! There's no super clear answer (and a big market opportunity!)
It is important for people getting deeper into programming to learn a text-based language. But I do want to say that you don't need to stop using Scratch -- lots of adults use it, and it's really great for many things... e.g., this memory portrait of my mother sewing when I was young https://scratch.mit.edu/projects/646805603
Several comments here have hit on the visual UI as an element of Scratch that other languages don't have as readily.
Another element is the sharable context: you can make a Scratch project with others' enjoyment in mind; your project doesn't have to have another purpose besides being fun to play with.
So for moving on to other programming languages, I think the key is to identify compelling projects and to find (or build) small communities which will use those projects.
E.g.:
* sites like replit and Glitch and Github Pages and val.town where the whole idea is to make a small program (or piece of a program), publish it instantly, share it with others and remix others' programs
* making a choose your own adventure-style or Zork-style text game
* Advent of Code https://adventofcode.com provides a massive multiplayer experience where you know you're solving the same project as thousands of other people
I've seen some children move onto Unity for the 3D graphics. Physical computing can sometimes give an incentive for Python when its the only lanaguage available. We've done some stuff with Minecraft Pi at code clubs I've been involved with. although it's such an early version of Minecraft. My elder son likes maths, so we've done some mathematical things in Python, which are easier in that, although probably wouldn't be impossible in Scratch.
etoys for squeak has the ability to switch between blocks and code, as a way to learn about the code that the blocks generate.
it would be interesting to have a programming language that is essentially a text form of scratch and that can drive the same animations so that you could learn the text syntax and continue creating the same games, or even translate from one to the other.
I'm a dedicated Evernote user. I add just about everything I generate or want to record to Evernote, in one big "notebook", and then I extensively use tagging to make sure everything is findable. I try to use every tag I might ever search for, for which this note would be relevant.
Sometimes I add content to existing notes, if they are relevant and include the same family of concepts. I often merge notes; e.g., I save all my tweets to Evernote via IFTTT, and then merge all of them for each given month.
I often add notes with no tagging at all, and I have a shortcut to search for notes with no tags, as a sort of inbox.
The ability to search everything at once is the key: I can search "movies" or "startup" or "medicine" and find everything with those tags, or those words in the title or text, or even in PDFs. (I use a Fuji ScanSnap to scan documents into Evernote, with fully searchable text.)
The biggest feature I wish for is transcription of voice notes or audio files, so the content would be searchable.
Evernote's Mac app is notoriously slow, but it's gotten better over the years. I still don't understand why they can't make it as fast as the web app.
I'm a huge skeptic of no-code among my friends and colleagues.
But seeing how pretty much everyone else here is also expressing skepticism, let me play devil's advocate.
I recognize that the utopian promise of no-code is nonsense. There will always be feature demands that violate the "on-rails" nature of the environment, and either require supplementary code, or require waiting for the platform's coders to code up support, or require rebuilding the application from the ground-up.
That said, there are all sorts of applications that really are so narrow that an existing GUI can accommodate them. Other posters here have called out Excel/Sheets as an example; Wordpress, Squarespace and WYSIWYG web page editors are another. As a coder, I always feel frustrated by WYSIWYG interfaces' side effects, limitations, and inevitable bugs, but people do use them all the time, productively.
Of course, both web editors and spreadsheets do involve the ability to write code! It's just that the code's role is very narrow and limited to a small expressive range (CSS, say, or various SUMs and HLOOKUPs).
When the domain is relatively narrow and its boundaries are pretty clear, no-code can be wonderful. The real question, right now, is whether applications that are innovative can be built using "no-code" tools that necessarily assume all sorts of limitations.
I have seen some clever and impressive uses of, say, Airtable + Zapier + Typeform. That sort of "API-weaving" seems to me the most promising direction for no-code. I'm more skeptical of the projects, like bubble.io, which try to be a sort of Photoshop-for-building-applications.
Let me add to this. My viewpoint is similar to yours, and I have some anecdotal info to support this devil's advocate.
My wife was able to setup a WordPress site that sold fundraiser raffle tickets for her Rotary Club. The event was on local TV and handled a spike in traffic – thousands of ticket sales in a few hours – with no problem. This whole thing cost her less than $300, which would only get a few hours if she had to hire a dev.
I kept on telling her I was on standby and could help out, but she didn't need it once. She built the entire thing with WYSIWYG and WordPress plugins.
No-one is saying you build your tech startup with no-code WYSIWYG. But imagine if my wife's no-code skills (in her place, WordPress) became as common place as knowing Microsoft Office.
I’m skeptical of no-code solutions because every once in a while, a user does
something really problematic without knowing that they do — this isn’t a criticism
of the user; how can they be expected to understand, let’s say, security, if they
don’t have a rudimentary understand of cryptography or client/server models?
A more physical analogy is that I do DIY — including internal wiring of the house. I’m
comfortable doing that because I’ve read through the whole of the regulations and have
a degree-level education in Physics and understand the risks. If a stranger asked
me whether they could wire their house through Youtube videos I still wouldn’t
happily say yes — even though theoretically there’s enough good information out
there to wire a house.
The security example is a really interesting one because what you describe as a weakness of no-code viewed another way is a huge strength.
That is, an approach of the user not understanding these things and so deliberately going for a black box, just-works-in-exactly-this-way solution that's centrally tested, audited and maintained across the no-code platform is actually pretty great for security.
Having an understanding of how these things work, even a really good one, does not preclude mistakes if you want to do things customly - on the contrary this only ever increases the surface area for mistakes.
You might argue, and it often is argued in engineering (use the auth provided by your framework, well-trusted ecosystem libraries, etc), that it's better to just rely on known good solutions even when you do have a great understanding of the principles for this reason.
I think your counterpoint is a good one — but I would argue that it has
the implicit assumption that such users will and can delegate to authority.
In my own experience this hasn’t been the case — the alternative of the user not understanding
a problem is not going with an authoritative approach, but simply not to think or care
about the problem.
Even when relying on ‘good’ solutions you need the requisite knowledge to
judge what is good — otherwise people, engineer’s included tend to view such
solutions as unnecessary. In your example, an authorization framework will
have a selection of different protocols from OAuth, Basic, LDAP and so on — all
of which are ‘good’. Without understand authorization and authentication
could you really select between them?
The other problem with "no code" is that code is more than just text on the screen. It's a way of thinking. A very formal and precise way of thinking, which is what you need to have to be able to make a computer do what you want, and not do the things you don't want it to do.
To build complex things with "no code" tools, you need to adopt the coding mindset anyway. You end up discovering concepts like modularization, abstraction, you end up internalizing what the "no code" building blocks actually do, vs. what they advertise to be doing. But by then, what you're doing is just writing code in an extremely inefficient, unergonomic and probably visual way, and you'd be better off having learned a programming language.
I totally agree, and look at the success that Salesforce.com has had. I have seen numerous examples where a reasonably tech savvy person on a sales or support team has been able to put together a totally acceptable workflow to manage their team without having to deal with any product managers, qa, developers, or IT personnel. It can save a tremendous amount in both development and opportunity costs.
It's not always perfect. As adoption and complexity increases, teams often find themselves bumping up against the limits of the tool eventually, and need to bring in specialists to help. But even then, it seems much better than the alternative of trying to code your own CRM system from scratch.
I have used excel a lot in my career, but I don't think I have ever created or even seen VBA in any spreadsheets. I think it probably varies a lot by domain, but if I were to guess I would probably say that far less than 1% of Excel spreadsheets use VBA. And a lot of spreadsheets that do are probably good candidates to be rewritten in some other tool.
In my opinion, the reason that Excel has such a commanding lead in that space is more due to familiarity, compatibility, and that Excel is still just one of the nicest spreadsheet apps to use.
I largely disagree with this article, but it is informative and decently reasoned. I think the author is haphazard and inconsistent with where they apply their imagination: fantastically generously when it comes to the police who killed George Floyd, and not at all when it comes to appreciating how much of a difference there may be between how police treat those they value vs. those they don't.
"Conservatism consists of exactly one proposition, to wit: There must be in-groups whom the law protects but does not bind, alongside out-groups whom the law binds but does not protect." --Frank Wilhoit
Another valuable book is Moral Mazes -- it's a tough read, but the takeaway is that managers are almost universally insecure, like INSANELY insecure, because they don't really produce something tangible, they produce the feeling of stability and predictably and (most important) loyalty in THEIR managers, and how the heck do you measure that? They're always one misunderstanding or failure to anticipate a problem or to quell some fussing away from being fired, or shut out of promotion. They exist in a terrifying state of status uncertainty. If they're not careful -- like REALLY, REALLY, affirmatively, pro-actively careful -- they'll create an environment where the people under them, who have front-line knowledge to bring, will suppress problems and avoid difficult conversations because they'll know how upset their manager will get. This can be incredibly costly. A good manager has to be brave, not just for themselves, but for those under them who need bravery to speak up. And that manager needs to go to bat every single time someone under them is right -- even if it costs the manager their job.
Of course, few managers understand this advice or have the slightest spine to stand up for what they (internally think they) believe in. It's much more common to find managers who deal with "the wrong person" under them having a good point (and feeling embarassed, or worried that a superior will feel embarassed) by covering for it by getting angry.