This is a great progression in the series by Zed...if you lurk r/learnprogramming, or any other place full of aspiring coders, a common complaint/desire is that students will have passed all the Khan/Codecademy courses, but have no idea what to do with the pieces of programming fundamentals that they've acquired. This is not just a problem with self-learners...I've seen a few r/learnprogramming posts by CS grads from 4-year-colleges who say they have literally no idea what an API is or why/how to work with one.
And I don't think it's necessarily correlated to the rigor/prestige of the program. I had a discussion with Stanford professor who is building a course that involves hands-on work with real-world data problems...he undertook this initiative after finding that some PhD students, while brilliant in their research and coursework, did not know where to begin with relatively easy data cleaning work. I don't know exactly what the disconnect was, but I'm guessing it wasn't because data cleaning is particularly difficult as a CS problem. But it does require the ability to "see the big picture"...not just how different code modules and components can be designed to talk to each other, but the context and general who-gives-a-shit in regards to a given data/computational problem.
So yeah, thinking about small projects to code for is a great way to make things "click". Can't wait to see what examples Zed comes up with.
Exactly my experience. I started learning web development, specifically Rails, some time ago and did all the usual tutorials, like Michael Hartl's.
However it only started to really click when I was faced with actual real world problems and was able to solve them slowly, but one after another. We needed a simple product catalog (no ecommerce yet) with syncing capabilities from our internal FileMaker system and that small project has turned out to be the most valuable learning experience on my ongoing path of mastering Rails.
I agree 100%. Moving from "Proving theories of computation" and "Syntax to think about computing" to "Projects" is actually a big step. At my undergrad you could graduate with a BA in CS without making the leap. (With a BS you wound up having to get more practical)
I think this is a great idea for him. I'm glad that he's taking CS education seriously. We all benefit.
r/dailyprogrammer is a good resource too, not only for small "projects" but also seeing how others have attempted them. It does have the issue of the top voted answers being in Brainfuck, Haskell, Lisp, Assembly, and a slew of other impractical(? for lack of a better word) languages though.
> Brainfuck, Haskell, Lisp, Assembly, and a slew of other impractical
My argument: Haskell and Lisp are just as practical as Python, Java, C#, or C++ for r/dailyprogrammer problems.
Brainfuck is impractical, I can agree with that.
Haskell is used in the real world. For instance I write Haskell for my day job right now.
Lisp is also used in the real world and was even used to create Lisp Machines[0]. I got contacted by a recruiter for a Clojure job a couple days ago.
I can kind of see why you'd call Assembly impractical for the projects on r/dailyprogrammer, but would like to make sure you aren't claiming Assembly itself is impractical.
My comment was meant to be along the lines of "/r/dailyprogrammer is a great next step up from /r/learnprogramming", so I made my practicality comment in the context of someone learning a first language wanting to learn from other code examples in their language of choice. If only I had an infinite amount of space to add footnotes and disclaimers.
I don't think the languages are universally impractical or unusable for development (BF excluded). However, I _do_ think that they lack the resources[0] important for beginners that are available with much more widely used languages. Not saying they don't have resources geared to beginners, but I've been bitten enough in many fields (programming, cooking, you name it!) by using something not as mainstream that I can comfortably say "Learn the popular way first, then explore." I guess though, if the goal is to go from zero to a job writing Haskell, then the "popular way" would be to learn Haskell!
Assembly.. I love doing trivial routines in assembly because it feels like a puzzle, but I struggle to think of where I would practically use it. Even on uCs such as ATtiny2313, I gain so much from being able to do control flow in C. The most assembly I've written from college is actually in TIS-100[0], hah.
Not sure if you realize this, but this comment about "impractical" languages reduces your chances of future employment in a number of companies to near zero.
I mean of course the companies that use some of the languages you mentioned to build large software systems every day.
That's fine. I have not really ever had companies actively seeking me based on my non-LinkedIn activity, so there's no change in the status quo there. I don't claim to know any of those languages well enough to be paid to use them for "large software systems", but luckily enough there are a significant number of companies that do development in languages I do deem practical :)
This is awesome! When I was in school, this has always been my go to way to getting people to get out of their "assignment programming" boxes.
One of my favorites was having people build a URL shortener using flask and SQLite. The general requirements were something like:
1. Server a web page in flask with a form.
2. Accept URL as POST from form in flask app.
3. Hash URL.
4. Store hash and URL in database.
5. Return new hash URL (ie, myshortener.com/?hash=12345) as a new page or with ajax.
6. Accept GET requests with hashes.
7. Lookup hashes in database and 301 to URL or 404.
Other fun ones were building a Secret Santa web app (accepts sign up separately and emails everyone on a certain day so it's completely self run) and building a simple version of Galaga (in JavaScript using just canvas, setInterval, and keydown/keyup events).
I'm about to publish a book of simple programming practice problems based on my curriculum and experience teaching programming. Each section asks the reader to rely on more fundamental concepts, from basic input processing on to reading files, working with lists, and consuming third party APIS.
And at the end, there are some projects like what Zed is envisioning.
And I have the URL shortener in there, because it's really a fantastic programming exercise.
Like you, I believe it's really important to get people thining about solving problems with code, and I think the real key to doing that is getting them to practice.
This is wonderful. I've been doing Learn Python the Hard Way and loving it, this is a really cool addition. I recently picked up the book 'Automate the Boring Stuff with Python,' and one of the best things about it is the practical applications really help drive understanding - at least for me.
At work I write a lot of PowerShell scripts, and I think the reason I took to it so quickly is because the need was there. It was never ambiguous what I was going to build: I knew what I wanted to make easier, what tool I wanted to use to accomplish that goal, and it set me to learning quite quickly.
This looks like a great idea, and I imagine the execution will be great.
Personally, though, I find no excitement in building a log searching tool. Something a bit more magical (I think something involving web scraping or markov chains would be interesting) would probably entice people to move forward much more.
Not that this tool wouldn't be useful, just that if I look at the end result, it doesn't give me the want to build it.
If your career starts out as a developer, there are going to be things you have to work on that you find no excitement in (gross generalisation of course, but true for the overwhelming majority of developers I'd say).
It wasn't until I got tasked with writing something I had no interest in as part of a recruitment process that I realised programming would always be a hobby for me, not a profession.
I agree, but it looks like there will be more projects coming. I teach a class aimed at exactly this "Codecademy chasm" and tend to use small, practical apps e.g. parsing San Francisco street sweeping data or getting the weather forecast. I'm pretty sure most of my students have no idea what logs are.
I like that site, but I have a beef with tutorial-style teaching. I find the teachings don't get internalized if all the answers are right there; I'm also speaking from personal experience - I'm 23 and went through the "okay, I sorta understand programming, now what?" phase not all that long ago. You could argue that it's up to the student to make attempts before reading on, but that rarely works.
The other extreme is the link in the OP, that is minimal in assistance. I think the sweet spot is somewhere in between. There shouldn't be hand-holding, but you don't want to leave the person clueless either.
I think this approach to teaching programming should be used more often. A good read for someone looking for something that is already out there is "Cloning Internet Application with Ruby". [I am in no way affiliated with this book]
It uses Sinatra & DataMapper to take the developer through some simpler projects (URL Shortener, Microblog, etc...)
It's odd how much novice programmers are asked to work on blank-slate exercise projects, which strike me as inherently advanced work.
Building up from "hello world" to something with interesting learning-experience challenges involves a lot of boilerplate work. It's almost guaranteed that you won't learn the core skills surrounding managing and limiting complexity in medium and large projects, or even why these things are valuable.
It's not much work to get a build environment up for a real-world program the student might use, then have them do projects to modify it (games are great for this). This can be really rewarding, it exposes the learner to realistic, large-scale code, and it serves to get them a gut feeling for "none of this is magic, it's just a bunch of code".
It's only a problem if you choose a language that requires a large build environment.
I have a very effective programming fundamentals class. y students perform very well, and every project we do is done from scratch. But I teach it in JavaScript simply because that is the absolute quickest way to introduce programming.
JavaScript can be an unforgiving, punishing language. But an absolute beginner who's learning to code can be steered away from the nasty bits. Because if you've never taught an absolute beginner, who doesn't even know how to open Notepad or unzip a file, you'd be shocked how slow and deliberate you have to be when you teach. :)
A lot of the early software development I did revolved around modifying php web applications. Looking back, that experience didn't teach me very much.
When you know nothing about software and are working on a big existing code base everything is magic. It wasn't until I implemented a web app from scratch that I really understood how the web worked, and it wasn't until I wrote complex applications from scratch that I felt like I understood software.
Certainly having high quality examples of software is good for learning how a good architecture works, but at least in my experience if you don't have a good grasp of all the fundamentals (including a good mental model of object oriented concepts) everything in a complex piece of software seems like magic.
If Zed can navigate the morass that is python package management in a way that makes newbies grok the major points and understand the value of doing things The Right Way, I'd personally buy him a beer or something.
And I don't think it's necessarily correlated to the rigor/prestige of the program. I had a discussion with Stanford professor who is building a course that involves hands-on work with real-world data problems...he undertook this initiative after finding that some PhD students, while brilliant in their research and coursework, did not know where to begin with relatively easy data cleaning work. I don't know exactly what the disconnect was, but I'm guessing it wasn't because data cleaning is particularly difficult as a CS problem. But it does require the ability to "see the big picture"...not just how different code modules and components can be designed to talk to each other, but the context and general who-gives-a-shit in regards to a given data/computational problem.
So yeah, thinking about small projects to code for is a great way to make things "click". Can't wait to see what examples Zed comes up with.