Every now and then, it itches. And it is said that, where it itches, one should scratch. So, every now and then, I find myself learning a new programming language, or perhaps less daringly, pressing a few unknown keys after the command
yarn add. At my first major software engineering job, I was told to keep myself up-to-date with DZone (which has become rather bloated) and to read up on what Martin Fowler has to say about enterprise pattern x on his Bliki.
Yet, at our faculty, we never teach students how to keep up with the latest trends. The only thing we do tell is something among the lines of “Watch out kids. In the software world, things happen very fast”. Most of the times, much faster than me and my fellow faculty members can or are willing to follow. This is usually the part where we start debating on which new things should be taught and which shouldn’t, but let’s sidestep that debacle for a moment and look at something else instead.
Why don’t we give actual tangible examples on how to keep up-to-date, without throwing a few web links into their inbox, and without letting students complete a mundane and usually stupid set of tasks in order to complete their “life-long learning” course. How the hell can you “complete” a life-long learning course Anyway?
The state of…
I was thinking about this, because yearly, I receive a few interesting trend report links from friends on the state of
x. These might include:
- Http Archive’s The state of the Web
- ThoughtWork’s Technology Radar
- State of JS 2020
- State of CSS 2020
- PYPL PopularitY of Programming Languages
- GitHub’s State of the Octoverse
- GitHub’s Trending pages
- GitHut’s Small Place to Discover Languages on GitHub
- Stack Overflow Annual Developer Survey
- TIOBE Programming Languages Index 2021
- The RedMonk Programming Language Rankings: Jan 2021
- JetBrain’s The State of Developer Ecosystem 2020
Wow, there are so many of these juicy reports nowadays!1 I guess every self-respecting data-collecting entity should have one. The first thing to do, when deciding which language to learn, would be to do a quick cross-reference on multiple sources, and see if it’s actually worth to do so. Of course, as Brit likes to say: everyone should learn at least one fringe language. The RedMonk graph in particular is interesting because they contain a cross-cut of popularity rank on GitHub (x-axis) compared to the popularity rank on Stack Overflow (y-axis). For instance, many questions on Visual Basic still pop up on Stack, but not many projects use it on GitHub.
Apart from hobby projects or for the sheer joy of learning anything new, judging from the size of the above trend reports, we’ll have to admit that we’ll never ever in our lifetime will have the pleasure of knowing all languages/frameworks/tools/technologies.
So, it comes down to making smart decisions. Why not teach software engineering students how we as software engineers try to make these decisions?
Spiking students' curiosity
The top 10 most used languages might not be the most interesting graph to look at: these are languages you will eventually come in contact with anyway. Oh hey, stop programming in Java and try Kotlin on the JVM instead! TypeScript’s huge spike in popularity is mostly because of it’s static typing and the fear of big companies properly training their devs to work with dynamic languages. I’ve witnessed this multiple times myself: companies systematically categorize their “devs” into boxes like “Java dev” or “C# dev”, thereby forgetting that most programming principles are fully transferable skills.
In fact, I’d even wager that being a polymath is not only much more fun, but also increases your resilience. Do the trends demand you to stop programming in PHP? Fine, switch to Ruby instead. You might even have a head-start as a reflection expert. I’d love to implement 7 languages in 7 weeks in this very same imaginative course.
Currently, I teach a couple of groups in the second semester about software engineering in C, in C++, and in Java. What baffles me is that if I explain about the principles of TDD and how unit testing works using Google Test in C++, many students are unable to abstract these principles in order to transfer them into the other course, where we do exactly the same, but in JUnit. Granted, they are not given a lot of time. I sometimes forget that, even if the courses are not small (6
ECTS points each), on average, a student spends way less time tinkering and learning these concepts than I would have done as a coder on the job, or even after the office hours.
Still, I think it is important that we as educators try to give students a head start with the right background and principles, so that they can decide for themselves what to learn - and what not to learn. At the university, we will never be able to (A) keep courses up-to-speed, and (B) see it all in the curriculum.
As a student, I would be much more interested in an overview of the state of things than in the NP-completeness of a stupid friggin' sort algorithm I promptly forgot about when starting to program in the industry (oh hai,
But simply seeing is not yet believing: one needs to get one’s hands dirty!
Preliminary course contents
So, how about this:
- Introduction: how to read, study, and interpret trends
- Trends in web development
- Reading groups on https://web.dev/
- Kata’s on sample pure
htmlpages, with respect to accessibility and privacy
- Kata’s with a focus on
- Try-outs on new hot
npmpackages on simple
- Trends in programming languages
- Kata’s with many completely different languages, unit-test based
- Transfer core principles from one language into the other
- Trends in software engineering principles
- Case studies on M2/waterfall/scrum/hippie x/…
- How and when not to apply an (enterprise) (anti-)pattern
Did I miss anything? Let me know! It doesn’t have to be in-depth: you could easily devote an entire semester to each chapter. As long as students commit to their long-term memory how to tackle new things, I am happy. I know students can get overwhelmed2, but if we somehow manage to engage their curiosity, they’re in.