My approach is to employ folks with enthusiasm. If they're teachable, they'll figure out whatever pile of tools they get thrown into on the first task. Then they'll have some skills and the next task will seem less daunting.
Of course some mentoring is useful. But just the stuff that's pertinent to the task at hand; concrete help that gets them moving forward. Because, somebody is paying for results. And because producing results has a very positive effect on confidence.
I just offered work yesterday to a young person helping me at a big box store. I mentioned I was buying a device to test an Android build, and they got excited and started making cogent comments about the tool chain and devices available. I game them my card, and when they graduate in 3 months (from a local community college) I'll find them work on a client's contract.
The first project will cost me more than I earn from subcontracting them (because it takes me away from my high-rate work I would otherwise be billing). Maybe break even by the 2nd. But it's a sort of enlightenened-self-interest thing. If young people get into the field, everybody benefits.
And of course as an old guy with resources, I can afford to take some risks. Because it's everybody's job to look out for the other guy.
Have you actually been through this before ?
I ask because my experience wasn't the same so I'm interested in other perspectives.
One experience that jumps to mind right away - a few years back I was in charge of mentoring a group of interns. The thinkering/enthusiastic guy was smart and reminded me of myself at that stage - but I was a terrible employee at that point and it took a lot of failing to get productive, and this guy had all the same faults - overcomplicated things, didn't focus at task at hand, wasn't paying attention to requirement details... all this made him unreliable and a pain to work with.
There was one guy in the group who was average capability/enthusiasm but was hard working and focused. Wasn't the fastest to figure things out but if I left him with a problem I could see he put effort and tried to pay attention.
I've done this dozens of times. Somebody needs a break, and I have an opportunity. It's not a zero-sum game. That's the realization I made very early in my career.
Reminds me of myself too. Very enthusiastic, loved to code and built over complicated stuff (I can only hope I've stopped or do so less).
But I do still most enjoy working with enthusiastic people as long as they've totally failed a few times, to know their own weakness.
It sounds a bit like you got things the wrong way around. The guy who reminded you of yourself needed more mentoring, and the other guy was doing just fine.
I think the issue is that if you're smart and haven't failed yet it's hard to internalise such feedback/criticism in a constructive manner (when you're usually right it's easy to assume you're always right). Giving someone the opportunity in which they are likely going to fail over some who's just going to do what's necessary is hard.
...isn't that what they said?
Enthusiasm is perhaps the easiest thing to fake in an interview, and something many of us fake automatically, as smiling and seeming engaged is something a lot of us learn to do when meeting new people.
I doubt it correlates with productivity outside of something like a sales role. Most of the world's work seems to get done by people who don't appear particularly enthused.
> Most of the world's work seems to get done by people who don't appear particularly enthused.
Interesting! Can you share some sources to get deeper here? Until now, I thought apathy wasn't a sign of productivity.
Consult your own memory? Not being enthused doesn't imply you're totally apathetic. We all do plenty of things we don't enjoy, and aren't interested in, because it needs to get done.
I wish there were more people out there like you. You sound like a great mentor / boss
> My approach is to employ folks with enthusiasm
this approach is useless for when your actual goal is to spark enthusiasm, such as in... teaching
(Disclosure: I do corporate training (Python and Data Science) for a living.)
I generally don't teach coding to newbies, so a lot of the coding I teach is correcting poor mental models and teaching features (somewhat) unique (or different) in Python.
My best Pandas courses have been when the client opts to use their data for the course (instead of my canned data). The students are already subject matter experts with the data and when they learn some of the tricks to slice and dice, summarize, and visualize, they are off to the races. They dig right in.
Teaching as the article suggests is very difficult because examples that appeal to some or boring or confusing to others. I'm not saying it won't work, but there are cons as well. When I'm teaching with my "canned data", I try to mix in a few different datasets from different areas so students can see that the ideas are generally adaptable.
I always thought the best way to learn programming is to find a program you want to create, and then figure out how to make that happen.
This is still how i learn (most effectively) today. If i want to learn a new language or something, i write something that i always wanted to write in it anyways. That way it doesn't get boring.
I think what you're describing might be similar in that canned-data is not interesting.
This is true. You do have to watch for the "adult piano beginner" syndrome, though.
I'll explain: many piano teachers won't take adult beginners, purely because they have unrealistic ideas of how good they're going to be. They want to play a Chopin Etude or the Goldberg Variations or a Brahms Intermezzo, and don't want to spend time struggling with Clementi.
Well, sorry. You won't be that good for a long, long time, if ever. It could be that some beginning programmers also have wild ideas of doing a game as good as GTA, all by themselves.
I find the comparison really odd as someone in the opposite position - I had formal classical piano training from 8 years old until I gave it up during college, and later learned how to code entirely through copying other people's code and Stackoverflow in my mid 20s. Piano to me feels much more like a sport, in that there's a very visceral, physical aspect to playing, and in turn a ton of effort goes into optimizing everything from where your fingers should be placed to how hard or soft one is striking a key. Practicing is effectively comparable to training for some sort of non-team sport much more than anything else. I don't have perfect pitch, but learning how to read music is a very small part of the whole experience, and I would think that as an adult someone learning piano will find the physical aspect, particularly the finer motor elements, to be the primary hinderance to being really great. Writing code is entirely different in that it feels much more like learning a subject matter, and there's neither something akin to the apotheosis of the particular thing you're working on that you aim to emulate, nor hard boundaries as to determine your proficiency through performance. It's cool if your code doesn't work when you test it, you can fix that. It just feels like apples and oranges in the experience.
If you're picking up basketball at age 30, I hope you know that you're never going to be anywhere nearly as good as Curry, or Lebron. But you can definitely pick up a subject matter and become an expert later in life. Heinrich Schliemann essentially began his archeological career at age 36 and yes, basically excavated Troy in the worst way possible, but managed to actually excavate Troy. That's the difference between an adult piano learner and an adult code learner, I think.
That's how I stop myself every time a desire to buy a guitar shows up. I'd like to play some solos from Ten Years After, Iron Maiden, or Dire Straits, but then I realize that this will take forever to learn, and my middle age issues wouldn't help with that either.
But you need some concept of what kinds of problems are solvable with a computer before you could really be inspired to program one.
And more than that, you need to have a concept of the difficulty of a given problem for a beginner or expert. Obviously a beginner will be wildly off, but probably needs some concept of the level of difficulty.
For example, lots of people have motivation to write a game. But few have the level of obsession to follow through with it. Maybe they should do a basic iPhone convenience app or something first instead.
> you need to have a concept of the difficulty of a given problem for a beginner or expert
I thought writing a C++ compiler would be just some new keywords and member functions, and would take 3 months.
10 years later...
> But few have the level of obsession to follow through with it.
If the goal is to release a complete product, then you're right that that's a problem. However, if the goal is learning, half a game is a great way to learn about a variety of systems and how to program for them!
It's a matter of scope and expectations. Leave your epic space opera in your dreams and take baby steps using easier tools and concepts. Once you find some fun try product-izing it.
I used to teach from the "program you want to create" angle, because that's how I learned programming. (JS/MEAN bootcamp)
The problem was that about 95% of my students didn't have a program they wanted to create. Some just wanted a hobby. Some wanted a better job. Some wanted to do a startup and manage a team, but they didn't really know what kind of startup to do. One guy joined because he made discord bots and thought node.js was cool, but learning loops started to get boring for him.
Yes, learning is much easier if you have motivation. How do you motivate kids, if they rather play games rather than coding (and they even ignore in-game scripted coding such ad Minecraft or Roblox coding)?
Heck, I'm employed to write code and I'd still rather play games. Just I get paid for the code, and not for playing the games.
But you will do better teaching-wise if you do find something that has intrinsic motivation, not turning it into a chore.
It just might not be the right time! They've basically got until they are 18-20ish to decide to get into it. The programming books my parents gave me after 8th grade never interested me. The 11th grade programming class didn't either. The junior year of college tangentially-related course where I was like "oh I could write a program to help with this homework!" That did the trick for me.
So just keep trying, see if you can find programming-related aspects of other hobbies. And just try to focus on them learning things around those hobbies or obsessions, even if it doesn't seem to have a practical application. Get in the habit of going deep on subjects and practicing learning.
Try a game like Factorio or Satisfactory. Even just Minecraft can be good enough to train their problem solving and critical thinking skills.
They don't need to start with redstone to learn to code. They should play the game and naturally realize that redstone is a way to solve their problem (like making an automatic sliding 2x2 door) and then solve it.
I feel like those skills will take you much further in life because now you have an extra tool to solve problem no matter what field you end up going into. And since programming is so powerful, it's often one of the best tools for the job so kids will naturally pick it up.
My feeling, from ~eight years as a mostly-highschool math and science teacher plus parenting as my main work these last few years, is that this motivation to learn is best established very early on, hence my support for universal birth-to-three support (I’m in the USA) in the interest of minimizing adverse childhood experiences (ACEs/trauma) and teaching parents how to cultivate a growth mindset. Intrinsic motivation is powerful. I was not a beneficiary of such care, and have done a lot of re-learning, especially around what I’m feeling, and being okay with not doing “perfect”.
> How do you motivate kids, if they rather play games rather than coding (and they even ignore in-game scripted coding such ad Minecraft or Roblox coding)?
Do such kids need to start with regular programming languages? Wouldn't visual languages be a simpler starting point for them to get motivated?
I have pretty strong opinions on the "best way" to learn as well. My posts discusses the pros/cons of do it yourself projects.
One way I've found is to dig into C/C++ extensions to Python. The Python C API reference is very helpful: https://docs.python.org/3/c-api/index.html
It can be quite fun to implement a simple data structure (tree, queue, etc.). in C and bind it to Python.
Otherwise, you can get a lot of dirty details by reading the source to complicated/magical libraries (e.g. pickle).
I can confirm this works.
I was struggling to find why does a = [1, 2, 3] a = b b = b +  return a different value as compared to b += 
Looking into the source code, everything became clear. The + operator returns a pointer to a new list np containing all the elements from a and b, while += merely appends and returns a pointer to the original list
> Having a good mental model of a language seems like one of the fastest ways to be more productive in that language.
True, but teaching s programming language is different than teaching programming.
Diving into a new language is something you do if you already understand how computers work and how to turn requirements into code. But to first acquire that understanding as a beginner, it's not enough to be introduced to the specifics of any particular language, which is what the article is talking about; you need to clarify what is the role of a programmer in understanding a problem and finding ways to model it as a group of data structures and functions that live in the computer.
Have you tried Fluent Python? It really helped to level up my knowledge of the language.
(Disclosure: This is my content).
Why thanks for asking yes I do: I recommend my book, Illustrated Guide to Python 3 .
Yes, I teach "professional" Python programmers who lack a lot of the fundamentals. It is so easy to get my with Stack Overflow style of programming these days. (Plus a lot of my students don't want to be "programmers" they use Python as tool to get some job done.)
Feel this mental model approach is part of the appeal of Scheme and SICP as you start with simple replace model but near the end (still exploring chapters 4,5) you get shown how to build an interpreter which forces you to know how it all works because otherwise it doesn't.
Feel that's sentiment get more now - it's *not* magic but the fact that everything works given it's all illusions is magical
There is a truly excellent series of lectures on YouTube from a college course on the Python interpreter internals. But I can't for the life of me find it. One resource I can recommend though is pythontutor.com. It's a tool that will step through your code snippet and show how the code maps onto the internal representation.
Any teaching, training, has to hook with the experience of students. Otherwise, it will lead to cramming, etc; that's what we see in grade-driven teaching. You are doing a great service by using the client data to solve "mini-problems" of your students.
> grade-driven teaching
I've never understood the modern theory that one can master a subject yet not be able to answer questions about it.
/watches straw man fall over without putting up a fight.
Would you rather work with someone who added a major subsystem to one of your compilers for fun or someone who had never coded but could recite the ISO standard by heart? Who believes the former person “would not be able to answer questions about [the subject]”?
If measurements tend to become targets over time then the goal of “develop expertise” measured by “pass a test” shifts to a goal of “pass the test”, and the test is limited to what you can ask hundreds of students in a couple of hours, and they’ve seen practise papers and last year’s papers and you can’t talk to them, and you can’t see them work or the results of their work.
Is that then a good way, to develop and validate their expertise? Is it the best available way?
I think you've got that backward. I think parent poster is complaining about teaching methods where the belief is that "answering questions" -> "mastery." "Grade-driven teaching" here refers more to the "all we're gonna do is give you homework and a test." It's like industrialization of teaching - no mentoring or individual conversation, just tests and reading material. When you've got 1 teacher and 20-40 kids, it's about all you can do.
Lots of passing of tests from short-term memorization that's then promptly forgotten.
Yep, a lot of mini-problems that are generally relevant. I also show "real-world" code for every concept. Then they can see how this is applied in the Standard Library or other popular Python libraries.
I have always struggled with how to advise my friends & family on this path of learning. It seems like everyone wants to be a WFH developer these days, but I don't know how to enable them to succeed on that path. "Go build something you want to build!" is something I keep reiterating (as does this article). But most don't seem to be interested in that for whatever reason (presumably because its fucking hard).
Maybe I should just leave it at that - I am getting to a point where if someone doesn't have the willpower to go burn a whole weekend on a pile of bullshit that won't even compile (i.e. because they really want to solve some problem), then maybe they won't have the necessary pain tolerance required to truly master the skillset.
I have never met a programmer I respected skill-wise that wouldn't randomly spend a weekend locked in a room solving an esoteric problem they felt they had to solve (for no reason). Over the Christmas holidays everyone at my company writes PoCs or hobby projects, being glad to have some free time away from paid programming in order to enjoy recreational programming.
What I'm trying to get at is software engineering is an easy career if you're literally obsessed with it, and most software engineers are, or at least were at some point (it goes in cycles).
If you're not gonna do that, you simply can't assimilate the huge amount of knowledge needed to truly excel in even one facet of programming.
When non-tech folks ask me how to learn programming because they want "jump on the money train", I ask them if they ever take the initiative to solve a problem with programming. You don't have to work in tech to do this. For example:
Work in an office writing documents and making spreadsheets? Have you ever simplified your job by writing a Word or Excel Macro?
Own a smart TV? Have you dug into its features until you know them backwards and forwards and can program it to (metaphorically) sing and dance on command?
Have you connected multiple things in your house together so you can control them from your phone, just because you could?
These are all examples of taking the initiative AND having the curiosity to dig into technical problems, and implement solutions. If you are like this, you will likely do well in tech and really enjoy it. If you DON'T have the tendency to do these sorts of things, you are probably going to have a bad time.
> learn programming because they want "jump on the money train"
I think this is the best predictor of poor outcome in the field. The devs I've seen that chose the field for the money typically didn't last long and did everything they could to get into a non-technical position (often management). And then, unsurprisingly, fared poorly there as well.
I often see STEM pitched as a way to make money... And really the only people making money out of it are the institution cashing the first-year tuitions checks before they drop out. And that’s not even touching the predatory ISA that bootcamps offer…
Jm2c but I'm a great developer (I think) but I'm a terrible tech consumer. I have issues with smartphones most of my peers do not and I hate doing smart things at home.
I would also suggest that it's a matter of having an engineeristis attitude (analyzing problems and finding solutions) more than the topic itself.
>or at least were at some point (it goes in cycles)
Indeed. And the periods in which I can be obsessed seem to be increasingly less common as I get older, but every now and then I get bitten and just have to bang it out.
You can be a great engineer and not need to do any recreational programming.
The thought that some devs are more respectable skill-wise because they hack in their free time is short sighted.
You literally have 8 hours a day to experiment and try all you want, everyday you have the opportunity to learn, hone your skills and experiment and good companies actually have days dedicated to experimenting.
Obviously you can't get great at this job if you don't bang your head on problems for days, but I fail to see that's a quality of recreational programming.
This “you gotta program all day every day or else you are unfit for it”-attitude is incredibly toxic and harmful. No other profession has this. No dentist gets told he gotta setup a practice in his garden shed to practice pulling teeth, or else hell be a horrible dentist. No, doing job for 40 hours a week is enough to be one.
I agree on this, but I believe the comment was aimed more at the "Tinker-Attitude" that many STEM-People have. And I believe many other professions have this to an extend: I'd imagine that many journalists and authors enjoy reading in their spare time. Every mechanic I know has a cellar full of half-finished machines he fiddles with in the evening.
I don't have the energy to code on private projects for eight hours after eight hours of coding at work (besides occasionally enjoying not sitting in front of a monitor...). But every once in a while it bites me to blow 10 hours of tinkering on some strange useless problem, like simulating Logic-Gates with basic arithmetic.
That was not prescriptive but descriptive. I don't program every day after work either, but I do sometimes get terribly addicted to a problem and work on it a great deal. I haven't met a good programmer that didn't have it, much like you don't mean someone who's properly good at anything they don't practice a great deal.
> No dentist gets told he gotta setup a practice in his garden shed to practice pulling teeth
This is a weird argument to me, the medical field has an even more unhealthy work/life balance than our field. They absolutely "practice at home" (obviously not through home surgery, but reading and so). Dentists have an easier time than most other medical professions, but every dentist I've met regardless had extremely good work ethic and frequently obsessed over his work.
You can absolutely work 40hrs a week and be a good engineer business-wise. However, most people who are remembered for their contributions to a field (and weren't just in the right place at the right time) dedicated a large part of their life to it. That includes writers, poets, musicians, doctors, anything.. to quote old Onion videos: are tests biased against students who just don't give a shit?
> No other profession has this
It is very common for professional athletes and for anyone who wants to live off their art (painters, musicians, writers, etc). Most academic types I know are like that too.
There are plenty of programming jobs where 40hs a week is enough and you get paid a good salary.
Now, if you want to join a FAANG, that's a different story. But no one wins a Grammy by playing exclusively in weddings either.
They're not stating a moral judgment.
You can show people the door, but they have to walk through it. I learned programming, and a bunch of other stuff later in life (now 39). They all have the same process - you decide you want to do it, and you start doing it. You will absolutely fail hard and regularly at it. You'll pick the wrong course or book or language or whatever, but that's all part of the process. If people see you doing the work and are able, they'll help you out (ideally, not IME).
In a way its kind of nice to get started with something new, because you don't need a plan at first. You just start kind of doing it, and then when you take breaks, you figure out the plan. Its amazing how quickly you can pick things up once you get into the habit of doing it very regularly. That initial hump is always, ALWAYS a huge pain, but there's no escaping it. Failing and flailing for that initial period is how you learn, not how you fail.
I feel like I have a reasonably good track record of helping people get into tech (and was myself helped) and I'd note two things I've found very helpful:
1. It is very useful to let people know that the first ~500 hours of programming are the worst (not unusual for hard skills). I've seen now successful developers reduced to scream crying by the feelings lack of agency and overwhelming complexity during this period. Knowing it gets better can help them push through this phase.
2. Many people capable of being good developers respond badly to "Go build something you want to build!" because they don't actually want to build things, or the things they want to build are too outside their skill range and they feel disempowered. Giving someone a list of projects to do and textbooks to work through can be much more effective for certain people (like myself!).
Another way to handle 1.) is to let people modify the work of a master and build on their sholders to do fun stuff. I'd already "learned" a few languages (commodore basic, c, pre 98c++, and x86asm) well enough to do toy problems, but when my folks bought me quake I found it had a compiler and all the game logic in quakeC. I played the game a good bit but quickly it became about creating weird modifications, odd weapons shoggoths as pets etc. That exposed me to idiomatic code written by professionals, John Carmack presumably among them, while letting me skip everything between toy program or interrupt handler and using a game engine.
Code spells, a game on steam has some of that benefit, but nothing I jave seen since has been quite as accessible as quakeC
That's what made "101 Basic Computer Games" so successful. Type in the game code, often just a few lines, and you've got a working game!
> reduced to scream crying
Wow, I have never seen this.
That pain tolerance bit...
There's a blog post that I really like titled "Find The Hard Work You're Willing To Do" - http://www.cs.uni.edu/%7Ewallingf/blog/archives/monthly/2018... (HN post w/ 76 comments https://news.ycombinator.com/item?id=26209541 )
The article concludes with...
> But I had enjoyed working on the hard projects I'd encountered in my programing class back in high school. They were challenges I wanted to overcome. I changed my major and dove into college CS courses, which were full of hard problems -- but hard problems that I wanted to solve. I didn't mind being frustrated for an entire semester one year, working in assembly language and JCL, because I wanted to solve the puzzles.
> Maybe this is what people mean when they tell us to "find our passion", but that phrase seems pretty abstract to me. Maybe instead we should encourage people to find the hard problems they like to work on. Which problems do you want to keep working on, even when they turn out to be harder than you expected? Which kinds of frustration do you enjoy, or at least are willing to endure while you figure things out? Answers to these very practical questions might help you find a place where you can build an interesting and rewarding life.
> I realize that "Find your passion" makes for a more compelling motivational poster than "What hard problems do you enjoy working on?" (and even that's a lot better than "What kind of pain are you willing to endure?"), but it might give some people a more realistic way to approach finding their life's work.
A lot of people don't have the pain tolerance for the "this isn't fun" part of software development that is necessary to get past certain plateaus of skill.
It's like exercise. Everyone wants to be fit, but very few are willing to put out the sustained effort to get fit. There are no shortcuts, either. You can't pretend to be fit, you can't buy it.
That's exactly how I feel too.
Reddit has a bunch of posts where people will document their path to become a developer. Rarely do I see them go directly to building something they want to build.
It’s mostly people taking online courses and building the projects in those courses. They’ll do a few different courses and build up maybe 10-15 smaller projects before tackling something they want to build.
I've attempted to teach multiple family members/friends over the years "how to code", and they give up almost immediately. They "just don't get it", and I'd argue one needs to seriously find enjoyment in building things, and knowing how long things can take, to get started.
I'm not trying to level this against your friends and family, just an observation that I've been meaning to share, spurred by "just don't get it":
When I was in community college I had to take "Critical Thinking" as a pre-req for Symbolic Logic.
We spent the first 1/3 of the class, 8 weeks, analyzing truth statements, basically and, or and not. I was bored to tears, but attendance was mandatory, so I got to see how people absolutely struggled with this, and "just didn't get it". The average score on the mid-term covering that was a low D after 8 weeks of (excruciating for me) examples. I finished in <15 minutes and got 100%.
When you are in a bubble of people who work in engineering fields, especially in tech where logic is fundamental, I think it's easy to think that logic comes naturally to everybody, but it's far from ubiquitous and reading on here it sometimes feels like some people just don't realize this, especially those deep in tech.
Sometimes it's hard for engineers. In college, I majored in Computer Science, and for an elective, I took Electronics for non-EE majors. The first half of the course was analog electronics which I struggled with, but everyone else appeared to be following along fine. It was the second half of the class, with digital electronics, where things flipped. Students would struggle with "5V is a 1? 5V isn't 1V! What's going on?" while for me it was, "yeah, yeah, I know this already ... "
That's like most hobbies/careers.
People want to learn the guitar|piano|violin, until they realize the amount of work it takes.
People want to get fit and jacked, until they realize the amount of work it takes.
People want to be a lawyer/doctor/engineer, until they realize the amount of work it takes.
Or they realize that they just don't really like it.
Programming isn't any different. One needs a particular mindset, and a level of patience to deal with debugging. It's not for everyone, and that's fine.
E'ybody wants to be a bodybuilder, but don't nobody want to lift no heavy-ass weights.
Only caveat is, and this is where I feel bad, if the person hasn't learned something new in a very long time, they forget what it feels like to change, or even become convinced that they can't. It can be hard to convince someone that no, you don't need to have aptitude or be any good at it after a few days, weeks, even months. You just need to keep doing it. As long as the goal is realistic, you'll succeed. Whether you are more or less "talented" than someone else affects the timeline (a little) but you are going to the same place (again, realistic goals).
Applies to learning foreign languages too. I've spoken to many people that want to "learn Spanish" without having a clue that it's a huge grind to get to basic competency.
> one needs to seriously find enjoyment in building things
I would say you have to also be happy with/enjoy confusion and frustration.
> I have always struggled with how to advise my friends & family on this path of learning. It seems like everyone wants to be a WFH developer these days, but I don't know how to enable them to succeed on that path.
The best advice is to get a proper CS or Engineering degree honnestly.
I have opinions™, but mostly agree with this article. Most intro coding classes and course materials read more like a glossary than a lesson. This contributes (rather directly) to the failure to retain a diverse student base in intro CS program. We've gotten a lot better at recruiting CS students from underrepresented groups (women and BIPOC chiefly), but numbers drop off quickly.
Studies in math education have shown that the way material is presented/courses are run has a huge impact on reducing disparities. This is especially important in CS especially when boys are encouraged from a young age to do "techy" and "geeky" things in ways that girls usually aren't. Students arrive in intro CS courses, are sat next to students who have been coding since they were 10, and are rightfully intimidated even though they could succeed in the course.
While I was at the University of Michigan, I helped a professor develop "Joy of Coding," a mini-course for high school students that focuses on sparking desire ("joy") rather than teaching CS first principles. By the end of the first lesson, students are manipulating images with code – a real "WOW!" moment. It's built on Pathbird, a platform that I built (in conjunction with UMich faculty) to run more engaging and accessible courses in computer science and computational subjects. (Shameless plug: if you're interested in Pathbird, or even just to chat, drop me a line at firstname.lastname@example.org).
 https://cse-climate.engin.umich.edu/wp-content/uploads/sites... (see page 8)  https://www.colorado.edu/eer/sites/default/files/attached-fi...  https://continuum.engin.umich.edu/programs/jumpstart-coding/
> This is especially important in CS especially when boys are encouraged from a young age to do "techy" and "geeky" things in ways that girls usually aren't.
Just be aware that this is not everyones experience.
Many places boys are held back and girls are pushed forward.
And then afterwards boys gets told they are somehow "privileged" and would never be were they are if it wasn't for "male privilege".
Obviously this goes both ways, but there is at least some focus on it when it hurts girls.
If you try to mention the problems young innocent boys have, be prepared to get laughed out.
(I'm halfway expecting that even on HN too.)
This seems entirely created out of thin air.
I think that was neither nice nor fair from you.
This is experience.
If you had a cushy life, good for you. But don't tell others their experiences aren't real.
Meanwhile my sister's first programming course at university involved making a game using an existing bespoke framework. It mostly involved adding graphics and a few methods & some properties to objects (which already had physics etc. implemented) in an otherwise more or less done project base. I don't know about retaining or intimidation but I feel like it was way too much "just fill in the gaps, look you have a character on the screen now" and that they really failed to teach the basics of programming and I got the vibe that students finished the course not really having any clue how the whole thing works at all. The next course was object oriented programming at the deep end.
I feel like she's still struggling with the basics and doesn't have much self confidence at all. And she's not dumb.
> Meanwhile my sister's first programming course at university involved making a game using an existing bespoke framework.
I had exactly the same exercise on my first day on uni, we had to take some robot maze pathfinder game and adjust the algorithm a bit.
As someone who had been writing code for over a decade at that point (but who was unfamiliar with Java), I still remember it was intimidating.
I cannot imagine how it must have felt for people without prior coding experience.
In hindsight, the quality of teaching actual coding at my uni was pretty poor. But coding in general is pretty hard to teach well in that setting.
This comment covered several hot topics.
1. Girls in STEM: society needs to quit telling people "math is hard, tee hee" and quit shopping in the Pink Aisle at the toy store and reinforcing that culture. Buy your kids Lego and Raspberry Pi circuit kits and see what happens.
2. CS is part coding, part science of algorithms, and part software engineering. We have to quit intertwingling all terms into the catchall "CS" bucket because sometimes "how to run excel" gets thrown in there too. Maybe best to drop the term altogether and use more descriptive names for each study.
> 1. Girls in STEM: society needs to quit telling people "math is hard, tee hee" and quit shopping in the Pink Aisle at the toy store and reinforcing that culture. Buy your kids Lego and Raspberry Pi circuit kits and see what happens.
Girls in STEM =/= Girls becoming professional programmers.
There are plenty of girls in STEM fields such as medicine, biology, geology, physics, Math, civil engineering...
The fact that not a lot of them want to be forced to sit before a computer 10 hours a day for the rest of their lives certainly isn't an issue if you asks me...
> Girls in STEM: society needs to quit telling people "math is hard, tee hee"
To me, the very existence of "Girls in STEM" groups is sending a weird message to girls (and I’m apparently not the only one to think that). Something along the lines of “sure you can do STEM, you’re just not good enough to do it the regular way so we created a group just for you”.
Honestly that’s the message a lot of diversity initiatives end up sending.
Sitting at a computer for 10 hours a day isn't a gendered thing.
There is nothing about computer science or programming that is gender specific. It, ideally, should sit around 50-50, ±5%. So yes, it is a problem that it so heavily skews male.
As to why, it's multi-faceted cultural issue, with how our society treats boys and girls starting from birth. In other words, a pipeline issue.
RE: 2: I think I agree. There are lots of "CS" programs targeted towards high-school students which I have mixed feelings about. The goal shouldn't be to turn every student that walks through the door into a SWE (there's somewhat of a conflict of interest here considering most programs are sponsored by big tech companies who are desperate for talent – Microsoft does a lot in this space). Instead, I think it should serve a few roles: expose students to new opportunities (learn if you do want to be a SWE); give students the skills to understand that computers and algorithms are not magic (important from a public awareness perspective); and also to teach enough "deep" technical skills to prepare them for a world dominated by software (e.g., learning how to query databases, write small automations, etc.).
But I think most important is that intro courses need to serve as jumping off points (i.e., they should be INTRO courses). Give students a taste and let them decide if they like it and want to take another bite.
> We've gotten a lot better at recruiting CS students from underrepresented groups (women and BIPOC chiefly), but numbers drop off quickly
Are you really better at it if you can’t retain them in the long run? The stats you shared are interesting, but to me it seems to highlight that students are getting “weeded out” at the beginning of the course. I would be curious to attempt a correlation with High school GPA and SAT scores. Because, if lower performing students leave, regardless of gender or race, that’s to be expected. But if overachieving students of color leave and their (white or asian) peers with lower grades don’t, now that’s an interesting issue.
> Students arrive in intro CS courses, are sat next to students who have been coding since they were 10, and are rightfully intimidated even though they could succeed in the course.
I would argue the solution here is to have different “levels” of intro courses. Because the converse is also true; students that are coming in with a decade of coding and who already had an introduction to programming might assume they will be able to “coast out” courses and then suddenly realize they are falling behind their peers. And then drop out.
> This is especially important in CS especially when boys are encouraged from a young age to do "techy" and "geeky" things in ways that girls usually aren't.
It's not my experience. When I was a kid CS/IT didn't exist where I lived.
I was a math geek who loved to occupy himself with solving problems which are useless in real life and I was actively discouraged from it by parents, teachers and even bullied by peers. I still liked it but I tried not to speak about with anyone except some closest friends who accepted my weirdness. From my perspective it seemed that compared to boys the girls need more acceptance are less likely to pursue something they like if they are actively discouraged from it.
Do you know of any comparative studies with other countries? Or is this a predominately US/Canada issue?
For example, do BIPOC students in Botswana drop out at similar rates? Do non-BIPOC students in Taiwan experience similar drop out rates? What are the classes and course materials like in these countries in comparison to the US/Canada?
What about drop out numbers from international students? For example, do Polish women studying CS at American universities drop out at the same rate as American women? For those who do drop out, do they drop out for the same reasons?
If we want to get to the root of the problem we need both more breadth and more depth in our understanding. Too often we stop at the men/women (in America) or BIPOC/non-BIPOC (in America) divides, and then provide generalized solutions which have very limit impact.
I can speak as someone who has taught CS in high school in a few different East Asian countries, including Taiwan. The bias exists, but is less pronounced than it was 10 or 15 years ago. Boys will make remarks, but if you nip it quickly at the start then it's generally ok.
I teach all four years in high school and each year I get more females rolling up. My recent graduating classes have had more females, but still only 20% or so, but my entry level classes now are 50/50.
Oddly, every female I've had who takes the higher level CS classes has graduated with the highest mark you can get on the exit exams. They routinely destroy the boys on any test and with regard to programming skills. Sadly, some of those who take it at the lower level are pushed by their parents to take other classes at higher levels in preparation for university admission. Parents sometimes carry that bias that females should not be engineers.
There's some work on it. One might start at the keyphrase "Gender-equality paradox".
Yes, I remember back in the day the girls would always try to come into the computer lab to play video games. My friends and I were always like, "GET OUT! WE HATE WOMEN!" Then they left. The girls wanted to learn how to code so badly, but we wouldn't let them. My friends and I were getting lots of sexual attention from women, but we thought that was boring, and preferred to spend our time alone on computers. The girls were having sex, but they thought it was boring, and wanted to learn to code instead, but my friends and I physically prevented them from entering the computer lab, using our strong muscles. My friends and I all had zero sex drive, and if we had any attention from the opposite sex we would have rejected it and continued to spend all our time on computers.
Interesting that you felt the need to sexualize the girls who were interested in computers.
They are people, not objects for your pleasure. If your comment even remotely reflects your attitude towards them, then you might as well have been telling them "GET OUT! WE HATE WOMEN!".
Do you think that maybe if you treated them like people and welcomed them to the group with patient explanations, expecting nothing, they might have hung around?
I must share the very wonderful video by Seymour Papert on teaching LOGO. He makes a similar observation: imagine if we taught people dancing by sitting them at a desk and explaining all the steps to them, making them memorize them and write them down, but they were never allowed to actually move or try the steps. We find when teaching people a language for example that immersion works very well. So Papert suggests teaching math by immersing students in "Math land", and shows off his computer language LOGO designed to do that. It is a wonderful video in many ways and a big inspiration for me as I think about hopefully teaching in the future.
Youtube link for easy viewing but the entire video series he helped produce is here:
Missing from those analysis is the fact that not everyone has it in them to learn to code like that. I've genuinely tried learning to dance before with practice and I just sucked at it so I put it down and picked up another hobby. Yet in today's world we have this obsession with getting everyone to learn how to program in python. Instead we could be teaching the actual skills like critical thinking and problem solving in a ton of other ways that might stick better with students.
For someone who can think critically and solve problems, translating a solution into Python is the easy part.
It’s a little confusing and sad to me that people have to try to pressure themselves to go from zero to professional engineer in a short period of time. That sounds stressful and, frankly, almost impossible.
Like a lot of people here, I taught myself how to code as a child in a terribly inefficient manner. I spent probably around 100 hours making games on my TI-83 - you had write a formula to figure out how to color each pixel, it was awfully slow. I spent hundreds of hours on Microsoft InfoPath making toy apps with a little scripting. Everything was very difficult, but it was insanely fun. I’m a night owl but I would wake up at 4am to start coding stuff so no one could tell me to go outside. At some point I read an introductory text that showed how to do web things, and later I got a server, and made some real-time multiplayer games by the end of high school. I didn’t know about databases so I would serialize to and from a text file. I’ve never had that much fun for such a sustained period of time since then. I couldn’t replicate it, and with the distractions of modern tech I probably couldn’t even focus that much anymore.
I’m grateful that my childhood obsession turned out to be absurdly lucrative. Best wishes to everyone, young and old, diving in for the first time!
>>>> I’m grateful that my childhood obsession turned out to be absurdly lucrative. Best wishes to everyone, young and old, diving in for the first time!
There does seem to be an irony, that the people who were movitated by interest in the subject matter aside from money, turned it into a lucrative career. Meanwhile the people who were motivated by a lucrative career lost interest quickly. Maybe not general enough to be a good generalization, but I've seen it a number of times.
I think market demand for certain skill sets does not contradict the principle of "find your passion," but just means that some peoples' passions lead to marketable skills.
Becoming a good scientist, or professional musician, takes about 15 years, starting in middle school or earlier.
> It’s a little confusing and sad to me that people have to try to pressure themselves to go from zero to professional engineer in a short period of time. That sounds stressful and, frankly, almost impossible.
... That's what engineering school is for. At least, that's how aerospace engineers, EE and so on do it.
> I’m grateful that my childhood obsession turned out to be absurdly lucrative.
I find that, when there's passion there's generally money. People that are insanely passionate will make things happen naturally.
Yes, undergrad is a good place to learn to code. I’m still glad I learned when I did, and I think it made college a lot easier, but no doubt four years is plenty of time, and allows ample opportunities to code for pleasure as well.
I was referring to the people who, say, try to switch careers to tech and go to a bootcamp to learn to code. That just sounds really hard to me, a horribly compressed timeline, and I feel like you would always be worried about gaining professional competency vs just relaxing and enjoying the ride.
I knew a guy who actually went back for an undergrad and masters in CS in his fifties. He was a classmate and briefly a coworker. He was an excellent student and won some department award, and very organized, but somehow not very good at coding things. He would get lost in a sea of sticky pads and notebooks and take two weeks to do very small amounts of work. He was let go in the end. We forget how hard this stuff can be. (Ironically to me it’s everything else that seems hard, from music to mechanics to sports, coding is just so… logical.)
> Why? Because none of these chapters answer the most important question a reader has, the entire time, WHY!? Why is all this important and what problems does it solve? When should I use this thing that I learned?
When I was an undergrad taking an advanced class about probability theory, I asked my professor for help understanding the bigger picture. I could solve each of the problem sets, but I couldn’t see the bigger the picture. Why the hell are we doing this? The professor told me something like “Oh don’t worry, somethings are just impossible to fully understand the first time. Once you take a second and third class that uses these ideas the bigger picture will come together”
I have found this mindset to be incredibly true. Rather than philosophizing about the optimal way to learn to code (or anything) just:
1. read/take a class about the subject
2. use the ideas you learned
3. goto 1
While it seems inefficient, I think it can be a very natural way to learn and avoid all catch-22 situations
Yes, I think there are two things which are simultaneously true:
- We (as a society) often teach in not necessarily the most effective way, or at least a way that might be a bit ineffective for a number of students.
- Some people get obsessed with "the best way to learn something" and never actually start doing the learning. I'm learning Japanese atm, and the amount of people you find online who obsess about the best method of learning instead of spending that time just working through a textbook (or whatever), is staggering.
It's good that you mention probability theory, because maths is really a field where I've felt that it's totally normal to feel like a complete idiot the first time you read something.
I observed in myself that when learning new programming language/framework/concept I usually need to force myself through first few chapters even though I may not necessarily understand why. This understanding usually happens later when multiple of basic concepts are in place, absorbed and together help to grasp bigger picture which leads to understanding smaller elements.
While this seems to be working decently I'm not sure if it's only because I became accustomed to this, allegedly wrong method of teaching - not only teaching 'how to code' as this method of teaching is default one in all kinds of school books.
I agree with this. Usually when I learn something for the first time I'm lost. But after I become a beginner in it, then go back from step 0, things get much easier to understand. This has been the best approach for me.
"<x> is broken" -- clickbait title. His approach is fine, I like it. Let him offer it to paying customers, and see how they like it.
There are many different approaches to teaching out in the world, some free and some not. There are code boot camps, which survive only if they work -- since they only last 12-20 weeks, bad feedback would sink them pretty fast (unlike 4-year colleges, where the worthlessness of your degree doesn't become apparent until years later).
I am surprised no one mentioned the now-classic How to Design Programs https://htdp.org/2021-11-15/Book/index.html, which was one of the first intro textbooks to actually take in account some education research.
Since then, there is https://dcic-world.org/2021-08-21/index.html by some of the same people with substantially more education underpinning it.
The blog post has some good ideas, but really we can do so much better than armchair musing about sclerotic curriculums now!
*substantially more education research
Structure and Interpretation of Computer Programs follows this advice: designed for people who'd never used a computer before (no kidding -- this was common in the early 80s), the first lecture introduced the idea of procedures and abstraction and went on to demonstrate root finding, prime factorization, and a little symbol differentiation IIRC. A great way to get started.
I still don't any see initial introduction to the art of problem decomposition.
We want to do X ... what are the parts of X? How might we accomplish them? For each of them, what are their parts? How do we take a complex task and break into pieces that we know how to do and then compose them back together to meet the goal? What kinds of decomposition can we do? What kinds of decomposition work well?
Until you understand this high-level sense of what you're trying to, type list container map iterate immutable functional lambda coroutines are just noise.
Exactly this! To quote myself from a couple of years ago:
I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if you walk the learner through the pains first, then arrive at a solution, and tell them that "you've just [discovered how ownership works in rust]"; i.e. the concept is given a name at the _very end_, not defined at the beginning as a solution to a pain the learner never experienced. Unfortunately very few books/tutorials take this approach.