Love that this starts you right in the terminal and VSCode from the outset. A friend has been on the Codecademy grind as a new developer, and ~1 year in she is continually frustrated with how little focus it places on real-world tools and experiences. It seems they want to keep you in their in-browser interpreter for as long as they reasonably can.
I strongly believe that you cannot be a good python or any other language developer without first a good linux shell use knowledge. Specially python of runs in nix environments. How can you ever develop without knowing these systems is beyond my understanding.
I would bet that at least 90% of the best embedded engineers I've known, don't have basic Linux shell knowledge. Frankly, Your ability to develop good code has little to do with whether or not you've touched a specific OS' shell
I've been a windows user forever, played with Ubuntu for a little bit years back, but I definitely don't know Linux well.
The only times that I ever use Linux are in docker containers.
I've spent years writing java, python, php, and only occasionally need to use a Linux shell. When I do, Google and stack overflow are good enough to get the job done.
Sure, maybe in some domains it's incredibly useful, but to be a decent developer? Not at all.
I think your understanding is rather limited. It is quite easy to become a good developer in Python (or a lot of other languages) without ever touching Linux. Many people do it, and always have.
Does that mean they have the same skill set as you, or can solve the same problems in the same ways? No. But that doesn't mean they aren't good developers.
I think people are pretty good at changing an existing system that is running. Which happens to be the context of almost all professional work.
Of course if you don't focus at all on the "first principles" operational stuff, when the existing system breaks, your debugging will take a long time. But that doesn't discount that loads of people are able to get a lot of work done without having a great grasp on the incidental complexity that comes with trying to get a virtual environment up or command line things.
you can't be a good developer if you don't learn how programs are actually built and run at some point, but in my opinion it's counterproductive to start out with it.
My first language in uni was Java and we did start with the 'text editor + compile from cli' approach and 99% of people who were new to it literally don't get what or why they're typing obscure commands into the terminal.
For the first 20 years of my carrier I never touched a Linux shell because I moved right from the Amiga to Windows (and only since around 2010 to Mac and sometimes Linux, where the shell is a lot more useful than on Windows). Programming without ever touching the command line is different, but totally fine.
Also Python has very good Windows support, it's not particularly "*nix affine".
exercism.org (no affiliation) is pretty good in that regard, offering a cli to facilitate doing the exercises locally using tools you're already familiar with.
I like exercism, but the CLI can hide things like what a sane project structure looks like in that language.
I wish it generated a project with unit tests and told you which command to run (i.e. not an exercism command) in order to run those tests. That way you've got a more similar experience to what would happen if you cloned a project in that language and wanted to contribute.
Unfamiliar languages are much easier to deal with than unfamiliar tool chains IMO
So many courses demand you start in a text editor and I understand the rationale but I write almost everything in PyCharm and strongly encourage everyone to find a comfortable IDE.
If the intention of coding in Python is to get stuff done quickly, it seems a bit silly to handcuff yourself by avoiding one of the biggest time-savers.
If I were teaching someone Python, or pretty much any programming language, the first place I would start is the debugger. I would have them write a program as simple as this:
x = 1
print(x)
y = 2
print(x, y)
And then instead of just running it, I'd have them step through the code, line by line, and observe both the console output and the debugger variable display.
Some developers seem to think that using a debugger is a sign of weakness, or that it leads you to write bad code. I see it differently: the debugger is one of the best tools not only for debugging, but also to help you understand a complex codebase that you are jumping into.
> If I were teaching someone Python, or pretty much any programming language, the first place I would start is the debugger.
Totally agree.
In the first week of programming, students should be allowed only use the debugger (no direct runs) in every course/collage around the world. I saw firsthand how many courses/collages students struggle with logic because debugging was never introduced, and they were unaware of how to step through each line.
Another mistake that new programmers make is writing 30 lines of code and then run and lost why bugs occurring. As a rule of thumb, they should debug/run the program every 7 new lines of code.
Perhaps it was just my education, but my CS classes had almost zero real-world guidance on how to do anything. Maybe a one pager on how to install the development environment. No IDE workshops, source code control, project layout guidance, etc. Perhaps the non-theoretical aspects are distasteful to professors (astronomers and telescopes or something)?
I end up helping developers when they get stuck all the time and it is really amazing to me how many people get to the "senior developer" point in their career with very little understanding of how to use SQL tracing (e.g. MS SQL server) and IDE debugging.
Even the concept of the "print line" debugging into a lot file seems kind of foreign to them sometimes.
They instead rely on running the code, changing something, running it again, etc.
I am a big fan of reading through the code. That is almost always enough for me to find the issue and point it out to them assuming I understand the input and output context well enough. But if that doesn't work, add a debug point and fire it up. Not using a debugger seems like a massive waste of time in a situation like this. So much so that I have started asking "did you debug this" or "have you watched this happen in a debugger" before I will help out much. If they say "no" because they don't know how, I will teach them to do so.
Yes, I think it might be SQL specific but you can normally do this in any transnational db I have worked with (I am old, I don't use GraphQL or NoSQL dbs very often, if at all).
Basically, it is just a journal of all queries (really ANYTHING going on in the db but for developers it is useful to limit to queries) and typically filtered by database and by keyword (e.g. table or stored procedure name).
You can set up a trace to track long-running queries on a production server (DBA might do this) or on a dev server a developer might use it to capture SQL run from their code (e.g. a complex stored procedure with a lot of input params) so you don't have to try to assemble the SQL using a debugger, for example.
A good example might be "I am doing everything right in code, but the data set is coming back empty" so you profile it and realize the SQL is being called with an empty string and not a null, or whatever. When reviewing the code you thought "it will be a null". That kind of thing.
John Carmack had some interesting comments on debuggers (as opposed to "print debugging") in his recent interview with Lex Friedman. This was probably the most valuable thing I got out of their talk, because I myself use print debugging often. The main reason why I did this is that I use a lot of different languages (Julia, Go, JavaScript, Python, and so on) and it usually isn't worth it to me to learn a new and big IDE to small projects.
Not GP, but I assume this[0] is the talk. Clocking in at five hours, you might have to dedicate some time to it. The timestamps on the show indicate programming is discussed somewhere between the 10 and 51 minute marks.
I strongly believe there's a balance to be struck between getting started quickly and understanding how your code is run. Especially if it's an interpreted language like Python.
If you do understand opening a terminal in your project's repository and executing `python3 ./mypythonfile` then this should be prioritized. Even for noobs.
When teaching noobs I first have to tell them how to make folders, create files, what files are and where they are stored, modern systems abstract that all away.
I want them to realise that code is just text files, same with html
So many of my tools over the years have stuck with their simple command line initiation rather than wrapping into GUIs or other alternatives. Being able quickly write “python [whatever you are doing]” is awesome.
I worked with "senior" developers who were absolutely unable to run the project they were working on from a terminal. It was either the "play" button in the IDE or nothing.
Sorry, this is simply not realistic. This curriculum expects people to spend an entire day to learn strings, but then by the end only spend a day building an entire web server? Similarly with web scraping, these are very involved topics which could probably take a full course to introduce.
If the purpose is simply to expose learners to the concept then perhaps the advanced sections are justified, but then there’s no reason we need to spend a full day on each of the data structures. One or two days is enough.
Further, the author goes into extensive detail about strings (which is great) but then says basically nothing about the more advanced topics.
Nice learning guide. On basic level Python is easy to learn, if already familiar with anything programming related. However, acquiring a practical idiom for Python code is not that trivial, in my experience. There are so many ways of expressing the same intent in Python, also the lack of explicit types eventually bites you where least expected. Also the whole domain of the double-underscore object-functions is like an "easter egg" left for someone to figure out.
I wish the learning guides early on centered on builing an "engineered" application. Covering the approaches to structring the application, user input processing, error handling, logging, dependencies, packaging etc. Such that the learners won't be left alone with a simple knowledge of syntax and basic operations.
I'll give a plug for 'Cosmic Python'[0], it goes into detail of structuring larger python applications using hexagonal-ish architecture. I wouldn't recommend this approach for smaller services.
I'd personally like to see more python books like Cosmic Python, that delve into how to build enterprise applications with the language. Feels like an unserved market compared to all the python related data science books that are really popular.
That said, at some point it starts to make sense to read open source repositories to pick up useful patterns.
I agree, and my belief is as soon as beginners get to the inevitable early hurdle of "ah well if you want to type a number into input() you have to cast it to an integer type..." the vague allusions to simplicity surrounding Python vanishes and you might as well have started with Java like most college curriculums do.
I fail to see what the argument is here. So Python is a strongly typed language with no (/little) implicit casting, therefore you might as well learn another a language that shares those supposed faults but is potentially more complicated in every other way, because...?
Is having to explain namespaces, public vs private, static and so on just to get the most basic Java possible program off the ground on mostly the same level of complexity? Or do you just glance over those initially, like a complete beginner would for type casting an input in Python?
This could easily be expanded to 60 days of Python, but it provides a nice overview and everything included is clearly explained. Perhaps add a full section on generators and yield/yield from, those are useful, and maybe itertools as well? Also dict comprehensions are nice, they could go in as an addendum to list comprehensions.
It might be a good idea to introduce virtual environments earlier, as they help keep things from getting too snarled up dependency-wise.
In terms of modules, pathlib is very useful, if you're going to be collecting data from web scraping or similar then automating the process of creating directories and transferring files to them. Subprocess is another good one, for coordinating multiple activities in one script.
It looks like these people are using it as kind of a bookmark somehow, with the issue title as their bookmark title ("learn", "python learning", "30 days of python", "python").
Pretty good curriculum, I’m not sold on MongoDB, I’d prefer someone with Postgres or SQLite experience so they can be immediately useful on a project, but it’s better than nothing, which would be even worse.
There’s a rather deep rabbit hole really about figuring out what the best beginner curriculum should look like, because if the diversity of the applicability of Python. They might be doing to a data science role, a sysadmin role, an infosec role, an educational role, you just never know. I think it’d be prohibitively difficult to unify these tracks, and might even play a role in the perceived difficulty for a lot of people coming to computer work from zero programming experience.
Someday, I’d like to see some sort of AI platform that can gauge a users intuition about the concepts on the whiteboard and tailor lessons to be impressed upon that user the best way. I’d teach a 30yo with ten years of Excel munging experience different than I’d teach a 20yo with no CS education at all besides video games. That could be automated to great benefit, imo.
Another -1 for MongoDB here. It's a newbie trap in general.
However is is probably easier to get started with for someone who is already learning Python, because its data structures closely resemble Python data structures, the query language can be expressed directly in Python object literals. This makes MongoDB a very gentle introduction the basic usage of databases for storing data (as opposed to e.g. dumping JSON to a file).
Starting with Mongo might make it easier to graduate to relational databases & SQL later.
Arguably TinyDB might be a better choice than MongoDB, but at least Mongo does get used in industry once in a while.
> There’s a rather deep rabbit hole really about figuring out what the best beginner curriculum should look like, because if the diversity of the applicability of Python.
So true.
I really like that 1 day is devoted to:
* PyPI
* virtual environments
Those feel super useful in all the roles you've listed.
I'm also not convinced that MongoDB is the most practical choice.
On the other hand, it might be more intuitive to learn on 1 day than the relational database modelling. (Especially if we assume that the student has already learned about various data structures during week 1.)
> Someday, I’d like to see some sort of AI platform that can gauge a users intuition about the concepts on the whiteboard and tailor lessons to be impressed upon that user the best way. I’d teach a 30yo with ten years of Excel munging experience different than I’d teach a 20yo with no CS education at all besides video games. That could be automated to great benefit, imo.
