Online Courses for Developers - A slightly more Critical View

Post image
Photo by Tim Gouw from Pexels

We have a massive skills shortage in IT, especially in development. A natural effect of this is that there are many career changers and, as a result, alternative educational opportunities. These alternatives, mostly YouTube video courses and other online offerings, are good knowledge brokers but have downsides. Especially in such a knowledge-driven environment, scientific methods are more important than entertaining course design.

The Content Revolution

First of all, I want to express that I find the information available online a super achievement. I would have loved to have had these opportunities during my education with YouTube, Udemy, Coursera, and the like. No, of course, I’m not that old yet. The internet existed, and there was a lot of information available, but in no comparison to today. You read books about programming languages and frameworks. StackOverflow was emerging. The primary source of information on libraries and frameworks was the documentation or their source code.

The content revolution changed that. There is not just one but many videos, online training, and courses on every topic. Much of it is, unfortunately, garbage. That’s the Internet, and it used to be that way. What has changed is the offer, presentation in the media, and of course, the acceptance in the industry. Today, many people equate online courses with academic or practical training, which I find questionable in some cases.

So I need to Study?

No. I don’t believe that a degree is mandatory for a software developer. Also, little knowledge that can actually be applied in practice is imparted in foundational studies:

“Most graduates cannot program yet”

But, a degree in information science, ICT, or any other engineering science is a school of thought. You learn how to obtain, validate, evaluate, and adequately use information. Unfortunately, the scientific approach is not taught in any (or very few) online videos, even though it is the foundation for fact-based learning:

“Most graduates know how to learn programming”

Personally, my studies helped me understand how to learn and use information efficiently. The main asset was not knowledge, but methodology. I can recommend at least an undergraduate degree (in any science or engineering discipline) to anyone to take this approach with them.

A Scientific Approach

If you want to learn programming to work with it professionally, start with the basics: The scientific method of work. Of course, it’s not as much fun as just coding something quickly, but it’s a long-term investment in your future and everything you learn.

“Because some guy on YouTube said so” is not an argument!

For this very reason: Research information from different sources of various authors. Learning videos are good, but only the beginning. Study the material, and look for criticism of the methods you have learned. Try them out. Read documentation and code. Check and question statements made and validate if a specific content actually contributes to solving the problem you want to solve. Lastly, don’t use or even introduce technology, just because it’s cool. The latter is, in my personal opinion, a bold issue in many development teams.

Final Thoughts

I thought about linking a pragmatic YouTube video about the scientific method for a long time. There are many excellent videos about it. But I decided not to link one directly but let you do your own research instead. For reference purposes, however, here is the Wikipedia article on the subject:

Scientific method on Wikipedia.com

Don’t be a blind follower, and above all, don’t help spread false or insufficient information.

You May Also Like

The 9 Talents in Software Teams

The 9 Talents in Software Teams

Job titles like “Senior Engineer” or “Principal Engineer” don’t explain how someone actually contributes to a team. Counting a candidate’s years of experience doesn’t tell you whether they’ll bring stability in a crisis, explore new ideas, or quietly hold a group together when things get messy.

After leading different engineering teams and organizations, I’ve seen the same profiles appear again and again, regardless of title or tech stack. These profiles shape how teams perform, where they get stuck, and how they grow. Over time, I began to think of them as archetypes of engineering talent: Patterns of behavior and impact that show up in every healthy software team.

Read More
28 Days Later: Surviving Your First Month as a CTO

28 Days Later: Surviving Your First Month as a CTO

There’s a tired old trope in leadership circles: “Your first 100 days define your legacy.”

Cute idea. Presidential even. But let’s be real: in a tech org, 100 days is a lifetime. By the time you’re on Day 101, you’re not building credibility – you’re shambling through the hallways, moaning about roadmaps, and scaring interns. In other words: You’re already a Zombie CTO.

You don’t get 100 days. You get 28. Roughly three sprints if you’re on a 10-day cycle, and that’s all the slack you’ll ever get. If you don’t establish trust, show judgment, and land a couple of quick hits by then, you’re at best irrelevant – at worst, undead.

So here’s your 28-day survival guide – not theory, not TED-talk fluff, but field-tested tactics for how to stay alive (and keep your org alive with you).

Read More