Staying curious as a developer

5 min read ·

How I still keep up with tech after years as a developer


Compared to other sciences, computer science is probably the most recent one. Its tools and best practices continue to evolve every year. In tech, staying up to date with major changes is generally expected. A large part of studying computer science is learning how to learn.

I believe this is a field where you need to stay curious and keep discovering new things. And no, I am not saying people should spend their personal time coding and reading about tech. But there’s a middle ground between it being an everyday passion and spending 10 years writing the same code with the same tools at the same company.

I’m convinced that trying new tools and languages, reading about how others work, and, most importantly, sharing those experiences with others is both enjoyable and something that can mostly fit within working hours.

Tech Watch

The practice of monitoring technological developments is often called tech watch. Over time, I’ve found multiple ways of staying informed. I’ll share some of them with you.

As strange as it may seem to introverted people, exchanging ideas with colleagues and fellow developers is a big part of staying up to date. You may discuss news, ideas, and projects that you find interesting.

At my previous workplace, we set up a short, 15-minute meeting with the tech team every Thursday morning to share tech news. Sometimes we’d have lots of cool stuff to share, and other times the meeting lasted a minute. Having a dedicated time slot let developers know they were allowed and encouraged to read the news during work hours.

To keep up with tech news, I mostly read individual blogs, but I also watch videos and browse some companies’ forums. I’ve started sharing some of them on my read list page. More recently, I set up an RSS reader to follow the latest news from my favourite blogs and newsletters. On Mac, I’ve found NetNewsWire to be a great tool.

I wanted another way of sharing knowledge, so I helped promote the idea of workshops. For me, workshops became one of the best ways to combine active learning, experimentation, and knowledge sharing.

Workshops

We’d run a workshop about every two months. We’d block a Friday afternoon and spend anywhere from one to four hours on it. Anyone on the team could organise a new workshop or join an existing one.

The sessions that attracted the most people were often the ones where participants could simply sit and listen. The most memorable ones, however, were the hands-on workshops.

Some workshops were directly linked to the business. For instance, we spent an afternoon exploring ways to improve our OCR results, which had initially been a one-person job.

Others were completely unrelated, such as learning how to pick locks. This is a well-known cliché hobby for cyber security people. I brought a few of my lock-picking kits for participants to try after showing them how to pick a lock. A colleague brought handcuffs for a lock-picking demonstration. I still have a photo of my manager at the time wearing the handcuffs.

When AI, and specifically LLMs, started becoming popular, we organised a few workshops around those. One team tried to create a Dungeon & Dragons Game Master by using OpenAI’s API. Later, we did a session on Speech-to-Text and Text-to-Speech where the same team reused this work so they could talk to their AI Game Master. I also have a very fond memory of this workshop because I made a program that could drive a drone with voice commands: it could take off, land, move around, and even do a backflip. That was so freaking cool.

I’ve included below a few more examples of workshops we ran. Maybe it’ll give you some ideas.

Talks
  • Talk by a maintainer of an internal project about its architecture
  • General presentations: “Hiring in Tech”, “Code Quality”, “Architecture 101”, “Playing with GPUs”
  • Based on our stack: “Encryption at rest”, “Database optimization within our technology stack”
  • Tools: Elasticsearch, GitLab CI, PlantUML
Videos
  • Watching SymfonyCasts videos together and discussing the code
  • Live coding in a specific language
Hands On
  • Build and host a blog on AWS
  • Rust: Getting started by building a small application
  • Build your own AI agent using MCP
  • Godot: Build a simple game
  • Kubernetes & K3s setup
  • CodinGame challenges
  • Pentesting exercises

As you can see, the subjects were quite diverse, chosen mostly based on people’s interests and knowledge, there was no need to be an expert to share something.

The end goal was to create opportunities for others, and ourselves, to discover new things. Sometimes we’d learn a new skill, sometimes we’d simply have fun, and other times we’d realise we never wanted to touch a particular language or tool ever again.

Looking back, these moments were also a particularly good way of fostering a healthy engineering culture

Personal projects

You may or may not enjoy coding outside of work, but hear me out before you brush off this part.

There are plenty of side projects out there, more or less time consuming, and more or less related to tech.

For instance, you could spend a weekend on a hackathon. I’ve done a few, pouring way too many hours into projects I’d never touch again. I still do one every once in a while, for the competitiveness or just to spend time with friends. They’re fun, but they eat up a lot of time.

I get a similar kind of satisfaction from Advent of Code, without losing my whole weekend to it.

But here’s another idea: why not build projects for yourself? Better yet, why not mix your hobbies with your skills? This blog is one example, but there’s so much more to do. Personally, there are still plenty of things I want to build:

A friend who’s a big RPG fan made a TTRPG Alin Motion Tracker (The picture looks cool, I know, I know, you’re welcome.). A second friend made a board game tracker, where you can log the games you’ve played and the board games you own. A third is building a relatively smart apartment that helps manage electricity consumption. And a fourth built a private sports-logging app for their friend circle to run competitions.

With the rise of coding agents, building your own applications is more accessible than ever, though you’ll admittedly learn a lot less along the way. If you’re concerned about privacy, money, or the environment, you can run Ollama locally with Cursor. Either way, there’s never been a lower barrier to finally building that project you keep putting off.

Thoughts

I hope I’ll be able to promote this idea of workshops at my next job. Meanwhile, I’ll keep doing personal projects and experiments in my free time. I’ve already started sharing some of them here on this blog.

You can’t keep up with every new technology out there because there’s simply too much. However, making time to discover, experiment with, and share new things has always felt like a worthwhile investment as a developer.