I learned about Uplimit about a year ago from my friend who had just started teaching a class on dbt. Listening to her experience it sounded like a great option to discuss interesting subjects while being able to get into more detail than you are normally limited to with a single blog post or hour long talk. I had a few topics in mind but one topic I’m particularly interested in and wanted to expand upon was data engineering, specifically around Dagster.
I have now completed two runs of my Uplimit course (with another coming up soon) and have really enjoyed the experience. Looking back I wanted to share some thoughts on building and maintaining a course with Uplimit.
Keep the Destination in Mind
When I first pitched my class last year, I knew I wanted to talk about Dagster. The folks at Uplimit agreed on the topic but wanted me to step back. One of the best things about CoRise classes is that they are taught by practitioners, so as well as talking through the framework, CoRise wanted to make sure I explained it in practice.
Instead of making the class purely technical, we tried to put Dagster in the context of developing data engineering best practices. From there I worked backwards thinking what I would want students to know after four weeks. From there it was much easier to craft a narrative to help the weeks flow into each other and not just feel like I was forcing folks to read through documentation. When each week had a theme and a specific purpose it helped to keep the material focused and try to get them to learn one main concept per week that would bring them closer to the overall goal.
Education as Code
I tend to be a tinker and can jump around in my thoughts. I found this was also how I developed my course and my curriculum, I would add things as inspiration hit. I might work on something for week three and then jump back to week one. This was great for producing content but I needed to ensure that I wasn’t breaking things (especially as I had to make changes to code as the class was in session).
Since a big part of the class is teaching data engineering best practices, I started to hold my class to the same standards I would for code I maintain for my day to day job. I got into the habit of creating pull requests for myself and everything would be formatted and tested automatically before it could be merged. Having CI/CD checks in place helped ensure everything continued to work as expected. My tests also served as guardrails for students since their own projects could just use the same suite of tests I had been using when creating the course.
I ended up with two Github repos, a private one which contained my answer key and a public one which was used by students. I could experiment and tweak modules in the answer key and incrementally push changes to the public repo all without fearing of introducing any breaking changes.
Over-invest in DX
Before the first run of my class when I was finally ready for it to be reviewed by Uplimit, I submitted it to the QAer expecting to hear how great everything was. Having spent so much time on my material, I was sure they would enjoy it. Instead I received a slack that they couldn’t get started. I was crushed.
Talking to them a little bit more I realized the issue was not my content or project (though both still needed work). But I had not spent nearly enough time explaining the environment setup. I had built my project around a Python dependency/packaging manager that is not standard (I know it is shocking to hear there were issues with Python dependency management 😀).
Part of the problem is that I just carried over all the configurations and dev tools I used for work. I had become so used to these steps for getting a new service started that I had forgotten my own pains when I first got up to speed with those tools.
The other tool that Uplimit introduced me to was Gitpod. Gitpod allows users to easily drop into a preconfigured developer environment with all necessary dependencies and configurations already sorted through. In the first run of my course I did not fully embrace Gitpod. In the second run Gitpod was the primary environment for users and it saved a number of hours for the TA and myself to get people up and running with their projects. It also removed any ambiguity about different user setups and ensured consistency.
Trust the Experts
The team at Uplimit has a lot of experience in the EdTech space and I was glad to take advantage of all of it while building my class. Seeing the completed work and how it has evolved, I can say it was a group effort.
I had regular check-ins with the team when I was first creating my content and they helped make sure I was keeping pace and on track for our go live date. They provided a very intuitive platform for crafting the course which included a lot of helpful examples from other successful courses.
But more than the logistics they were all genuinely interested in my class and wanted to make sure it was a positive experience for the students and myself. They offered very thoughtful reviews of my content; letting me know when I should include more interactions or add a video to help clarify a section. Putting together a curriculum can be lonely so it was great getting input from so many different people.
Summing Up
Developing my class with Uplimit gave me exactly what I was looking for. It definitely required more work than a one off tech talk but I have something that I’m really proud of. I enjoy that the course is not a static artifact. I have continued to develop and improve it after each run.