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'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.
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.
From my own 4 years' experience, I echo what zenpaul said, and would add:
* Understand who your client is, and stop and check in if they change. I once had a manager at a client company change mid-project, and the politics (and sense of trust) completely reversed -- in retrospect, I should have insisted that we start the relationship over, clarify expectations, etc.
* It's not always a good idea to agree to disagree. I estimated one sub-project would take 3 weeks, and a client insisted it should take more like one; we decided to proceed, it took 3 weeks, and the client was unhappy. Looking back, I think we should have more seriously considered dropping the project if we couldn't agree on expectations. This can be proposed gently and respectfully: if you don't think that plan is worth it, I'm happy to do my best to help you find someone else.
Thanks, it's very helpful to hear about your experience!
Out of interest, is your site up? It would be interesting to take a look.
Glad to hear you had a decent experience doing virtual DOM yourself.
Not super surprised to hear about the CPU usage issue, but that's a helpful reminder that one of the things we leverage when we use libraries developed for high-availability applications like FB/Google Docs is all of the developer time focused on optimization.
From many people I have seen succeed and fail at being quants (in the high frequency trading realm, which is different in many ways than the derivatives analysis world), you don't really need any Financial background, besides being a thoughtful and reflective thinker who has naturally wondered and thought about how Finance works on the national, business, and personal level.
In fact, I don't think you necessarily need to have background knowledge of anything in particular. What you do need, absolutely, is the ability and interest to learn complex concepts and areas of expertise in a diligent and meaningfully insightful way. That is, you need to be something of a Feynman-type thinker, learning statistics and programming and the math of data analysis and algorithmic analysis truly from the inside out, so that if you taught any of it to other people you would be a phenomenal teacher.
If you're not quite sure what that means, consider teaching a statistics class by having the students work their way chapter by chapter through a statistics textbook. Now say that you randomly insert 10 errors in to the textbook: you switch one word for another, you misuse Bayes' theorem in an example, you forget to adjust sample standard deviation to student sample standard deviation, you leave out a crucial paragraph of explanation in a lecture, etcetera. And you don't tell students to anticipate this and point it out.
How many students at a place like Stanford would catch most of these errors or omissions and speak up about their confusion? How many students would already be putting in the consistent, focused, diligent effort so that they could be reasonably confident the problem wasn't just in their laziness or inattention? How many would care so much more about understanding the material than about potentially embarrassing themselves to interrupt you in class?
If you taught that class 10 semesters in a row, in all that time I doubt there would be more than a handful of students who met that standard. If you took those students, with no particular background in finance, math, computer science, or statistics, and put them to work as a quant, it's highly likely they would succeed.
Whereas if you took students who never would have raised a question about any of those errors or omissions and gave them years of experience in all those areas, it's highly likely they would not succeed as a quant.
(Background: I worked as an algorithm developer at a major high frequency trading company for 6 years. Some of the most valuable employees, who generated tens of millions of dollars of value for the company, started with only spotty knowledge of finance, statistics or computer science.)
Honestly; Evernote. Or any tagged note taking system. Web development has a near infinity of branching Technologies, languages comic conventions, and domain specific languages. A lot of the work of web development is building up your own documentation that's organized the way you think, so it's easy for you to find your way back to good explanations of core patterns and problems, walkthroughs for setting up different kinds of applications and libraries, etcetera
I'm not ready to call BS on this, but I'm deeply skeptical of the general language they're using. They might have iteratively gotten particular recognition to do what they say, but I don't think they've gotten recognition in general.
Strong disagree with Svip. Training doesn't make good drivers. Who is going to ensure the trainers are good? Who is going to test that the training is being effective? More restrictive licensing, with more consistent requirements, might make a difference, but is politically nearly impossible. As long as many people will be inattentive and unreflective humans, there will be bad drivers. Unless you're going to support a policy of refusing to allow a large percentage of the population to drive (like, say, how we restrict most people from performing surgery), you'll have bad drivers.
Bez's proposed solutions have the benefit of being politically palatable, and aligning actual driver behavior with public safety.
I'm constantly surprised by the poor contextual quality of speech recognition. I think the basic audio recognition does well, but when there is ambiguity, it seems like systems that are popularly considered high-performing degrade drastically. For instance, I'm using Dragon NaturallySpeaking to dictate this right now, but if I say a certain punctuation mark at the end of a sentence, half the time it's going to say excavation mark!
Ditto with Google's Google Now assistant, or whatever the heck it's called these days. I have a Pixel 2 phone (Dragon heard "pixel to phone" -- it doesn't have up-to-date context on proper nouns in the news), but when I tried to create a calendar event using "Create calendar event... meet Bruno for pizza", it heard "MIT pronoun for pizza". It has hundreds of samples of my voice, and it already knew I was creating an event! "Meet" has to be one of the most common first words used in events.
It seems to me like there is pretty low hanging fruit, and that we need more focus on flexibility and resourcefulness rather than acting as though we're moving from 99.5% accuracy to 99.6%.
You're pointing to an important difference: between being uninformed but trying to get towards being informed, and being uninformed but fiercely protective of your certainty.
What Would Feynman Do?
In this case, I'm imagining he'd say these are some of the things we think might explain bodies' keeping or losing atmosphere, but we have to remember that almost everything we think we know about planets and moons comes from looking at the light that bounces off of them and making guesses about the underlying rules, but we still don't know do much about the underlying rules of physics, so there's probably more that we don't know than what we do know about atmosphere retention.
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.