Charles Severance's Python for Everybody: a beginner course whose second half FDEs should study closely

Charles Severance’s courses are among the most-enrolled ever on Coursera. Python for Everybody, one of them, states plainly on its lessons page that it is meant for people who have never programmed.

Engineers with a few years of experience can easily take that as a reason to skip it. Read the table of contents closely, though, and the second half of Python for Everybody looks very much like an FDE’s first data jobs on a customer site.

Severance is Clinical Associate Professor of Information at the University of Michigan. All the lectures, the book and the exercises are published free on py4e.com under a Creative Commons Attribution 4.0 licence, and the source code for the website and the Python 3 book is public on GitHub at github.com/csev/py4e.

Those who need a certificate can take the “Python for Everybody Specialization” on Coursera, a series of five beginner-level courses. The first course states explicitly that no prior experience is required.

For an FDE, the course’s value lies in the fact that customer data rarely arrives clean. More often you get an export file, an undocumented endpoint or a legacy database.

The names of the courses in the Coursera series show that direction: after data structures comes web data, then databases, and the final course is a capstone on retrieving, processing and visualising data with Python.

A syllabus that runs from zero to real data

The lessons page on py4e.com lists 17 lessons. The early ones are for people who cannot yet program; lessons 12 to 17 cover, in order, regular expressions, network programming, using web services, object-oriented programming, databases and data visualisation.

The accompanying textbook is called “Python for Everybody: Exploring Data in Python 3”. The book numbers its chapters separately from the 17 web lessons: according to Severance, chapters 2 to 10 are adapted fairly closely from the open book Think Python.

So the first part is familiar programming groundwork. The later part, where exploring data becomes the main theme, is where a working engineer should spend the most time.

Who should take it, and in what order?

If you are moving from support, operations or business analysis towards an FDE role, take the full Coursera version in order. The first course is designed for people with no experience, so you need no extra preparation.

If you have written Java, JavaScript or Go for a few years, it is more efficient to skim chapters 2 to 10 of the book just to get used to the syntax. From lesson 12 (regex) on py4e.com onwards, slow down and do every exercise, because this is the part you will use straight away.

If you already write Python on the backend, you can treat lessons 12 to 17 as a refresher set of exercises over a weekend or two, without taking the whole course.

Which three ideas are worth taking to a customer site?

The idea most worth keeping is using a dict as a counter. Imagine a customer sends you a support log of a few thousand lines, where each error line contains something like ERR-1042, and asks which error appears most often.

You only need to combine the regex from lesson 12 with reading a file and basic use of a dict. The code below is an illustrative example, with an assumed file name and error-code format:

import re

counts = dict()
with open('support.log') as fh:
    for line in fh:
        m = re.search(r'ERR-(\d+)', line)
        if m:
            code = m.group(1)
            counts[code] = counts.get(code, 0) + 1

top = sorted(counts.items(), key=lambda kv: kv[1], reverse=True)
for code, n in top[:5]:
    print(code, n)

In under 15 lines you have the five most frequent error codes, during the meeting, rather than promising an answer next week. The pattern works for almost any “what is the most” question: which customer calls most, which endpoint is slowest, which hour has the highest load.

The second idea is not to treat the network as a black box. PY4E devotes two lessons to network programming and web services. As you work through them, ask yourself where your request goes and what the response looks like, because when a customer’s API returns a strange error at two in the morning, the person who understands the layer underneath usually finds the cause faster.

The last idea is knowing when to move from files to a database. A one-off script answers only one question. Once the data sits in a table, you can query it again, and others can use it without rerunning the script.

Two traps when you point the counter at real logs

The first trap is multi-line logs. The code above handles one line at a time, so if an error brings a long stack trace with it, the error code and the real cause may sit on different lines. Before counting, open the file, look at a few complete entries and decide where a “record” begins, rather than assuming one line is one event.

The second trap is a regex that is too loose or too strict. The pattern ERR-(\d+) will also catch an ERR-1042 inside a quoted sentence or a URL, and will miss err-1042 if the customer’s system writes in lower case. Count the lines that do not match as well, and read a few of them: that number tells you how far your answer can be trusted.

Turning exercises into evidence on your CV

Combine the four lessons on regex, web services, databases and data visualisation into a small project, in the spirit of the Coursera capstone. Pull data from a public API, clean it with regex, store it in a database, then draw a chart that answers one specific question.

Write the README like a report to a customer: what the customer asked, where the data was dirty, what the result was.

On your CV, describe the project by the exact sequence of work you did (retrieving, cleaning, storing, reporting) rather than just naming the course.

One exercise before you open the course

Take the error-counting code above and change it to count by hour of the day instead of by error code. You only need to change the regex to capture the hour from each line’s timestamp.

Then try one more step: instead of print, write the results into a two-column table (hour, error count). If this step trips you up, that is a sign you should start PY4E at the database lesson.

Severance wrote the course for beginners, but what it teaches most carefully, taking real data from input to answer, is something many experienced engineers are still weak at.