Hands On Developer Experience - Steven Van Beelen

Stefan van Eerde explains why hands-on work matters more than theory for developers. His early projects at Trifork, from banking to gaming, taught him domain-specific challenges textbooks skip. Contributing to the open-source Axon Framework forced him to internalize complex architecture in ways that paid off in later client work.
Chapters
Hi everybody, nice to meet you all. Thanks for introducing me there, Stefan van Eerde. Nice to electronically meet you.
Yeah, welcome to Amsterdam Tech and the TechMinds series. So great to have you talking about hands-on developer experience. Yeah, I prepared a few questions together with the Amsterdam Tech team. The first question I have is, in your opinion, Why is it crucial for aspiring developers to engage in hands-on projects? How can they best balance theoretical learning with more practical application?
So I'm going to answer this. I'm going to do a little bit of background. So I studied at the Vrije Universiteit in Amsterdam. I also did a master's there. And a lot of the— it was very interesting, don't get me wrong. It was a very good education I got there, very happy with that. And a lot of it was theory, and the development side, the IT side of it, was the tool to understand the theory. That's how I would put it. And that was, well, very helpful to get a grasp to a lot of the concepts. However, when I I finished my studies, I went for a job. I figured, okay, what the language we use most was Java. So I figured let's try to be a Java programmer, I guess. I didn't really feel like doing, how do you call that, research into IT. That wasn't really my thing. I really wanted to build something because that was the thing I like most. So I went that route and I started at a company called Trifork, still exists actually. And I was pretty overwhelmed actually by the amount of things you need to deal with on a hands-on experience. So that was— I managed, I mean, I'm still here, I'm still very much enjoying my job, but I figured that a balance that was towards doing the hands-on, actually doing something, is very helpful because you'll make mistakes, you'll you'll learn new things. And especially by making those mistakes, you ingrain them more into your mind. So I really value actually just building something, developing something. To me, that was, or still is actually, a very important tool to understand how to proceed with something.
So are you saying with that, that more or less your developer heart came alive when you actually started to do stuff? Compared to the more theoretical foundation that you had the years before?
Yeah, for me, that's definitely true. I mean, a lot of my peers during the courses were, I think, happier with what they were doing, with the focus on theory in there. I, in hindsight, would have likely preferred more of a practical thing to it. So more exercises, more team things, more trying out how to build application XYZ. And, well, like I said, I've been able to do so through the years. So I'm very happy I got that opportunity. But that's what made it click for me better. Cool.
And why Java? Was that sort of the off-the-shelf language you learned during your studies in Amsterdam and therefore a logical choice? Or Were there like several programming languages that you were looking into and this one came up because it was what Trifork needed, or how did that sort of come along?
Very fair question. Yeah, the focused program courses were around Java. So the most broadened perspective of how to use a programming language for me was based on Java. I know that the year I was done, I think they switched that to Python at the Vrij Universiteit because it was a bit more friendly on the syntax side. So yeah, it just came natural. I did most of it in Java, so I went that route, which doesn't mean I only had Java because I also did Python. There are also the scripting stuff was in there with JavaScript, CSS. I had some functional programming languages like Haskell and OCaml, C#, C, all kinds of things. It was a bit to the discretion of the tutor what kind of language we used. So what tool we used to understand the theory, and the tool just always switched. For some, they use Java. But for me, Java just— I have most of it in Java. So I figured, I guess I'm going to be a Java developer.
Cool. Yeah, at Amsterdam Tech there are also several hands-on projects taking place, and that also brings me a bit to the, to the second question. How did this hands-on experience complement your formal education in computer science, and what specific skills or insights did you gain that you wouldn't have from, from the theory alone?
Oh, How do I—
so focus on sort of the on-the-job experience, like what did you learn that wasn't handled in, in any textbook?
Yeah, I mean, a lot of the, the— I'm, I think I personally am pretty good at just pushing knowledge in and then I can rehash that knowledge, but actually seeing it in practice is, at least to me, very different. Because the, the, there is a certain domain that you use on the theory side. You, you pick a focus and it's typically the education domain, whereas while you're actually doing hands-on things for a client at somebody in the bank, in the financial industries, or somebody doing shopping domains, or maybe some governmental agency, it really changes what you're doing. And Seeing it in different flows really helps for me to, well, further cement the thought of what something is or what something means. Does that work?
Can you give one example of such a flow? How should— yeah, how do you visualize that, or how can the audience get sort of an understanding of what you mean by flow?
Yeah, so from theory, I mean, you look at— you read a textbook and you get a description of a certain concept that, how something is explained. But really using that theoretical tool in practice differs if you're building an application that is dedicated towards building an e-learning environment, or an application that is there to make a chat environment, or an application that is intended to be a shopping cart, for example. There are always certain gotchas that differ per domain that have impact on how you use the theory. So doing several hands-on experiences of something and not just in one angle, to me, was very valuable. Cool. Yeah.
So you get a broader perspective and you can apply things, learn from it, iterate, and then see what you can do differently, literally on the job. Yeah.
Yes, yes, exactly. Yes.
Nice. Yeah, then when it comes to a third question I'm thinking of is, can you also share an example from your own career where hands-on experience directly contributed to your success? And maybe particularly in, in an open source development environment?
So yeah, like you stated at the start as well, I'm very busy in the open source environment. So I deal with Axon Framework, an open source framework that everybody can play with and contribute to. My, one of my earliest projects, we used Axon Framework, was very new to me back then. So I really had to do it on the job and understand the theory that's behind it, because there's a lot of theory behind it and the architectural concepts that it helps with.. And then I stuck there for, I think, 1.5, 2 years. I did that job. And I wanted to do something new. I really wanted to change the pace. I wanted to have different hands-on experiences at different domains. Luckily, there was another project that also wanted to use this open source software to build their application, which was more in the gaming corner and betting corner, actually, in this case. So I went on site, I discussed pros and cons with them. And I could immediately, through the questions they had, I could recall the things I did at the previous job, at my previous hands-on experience, thinking, okay, no, you shouldn't go that route. Because if you do this, this might go wrong, or this other flow might not work out. That was— I went there with a colleague of mine, which was still junior, more junior than I was at the time. And after we had that session with this potential client back then, she commended me for, for the way how I was picking it up and how quick I did that. And to me, that felt like, oh, that was like top of, top of my knowledge I just had available because I had experienced it before. So that was, um, yeah, that was very insightful thinking, okay, just doing this to me, for me helps.
Yeah, putting it into practice. And then sort of duplicating the efforts in a different context. But you know, the right way to do it. Yeah, that was the, the hands-on experience putting into practice. Again, hands-on, I guess. Yeah.
How this might relate a bit more to the open source side of it. I guess some of the attendees here are familiar with things like Stack Overflow. You also have, well, on Discord, you also have a lot of places you can go to, to gain information about a certain language, a certain library, a certain architectural principle in IT. You can just attach yourself and see what's happening. I also did that, but then for Axon Framework. And then going through that process of seeing what all these different people coming from different sides of the world with different angles, ask or the issues they face was such a great learning master to me as well. Because on your own, you can only do so many projects. You cannot, well, split yourself into doing 10 of those in, in a month or so. I typically, in the job, you're dedicated to a client, maybe 2 at a time, uh, not that much more. Whilst if you take the, let's call it, forum approach, that you see what other people are doing and just going to help out. Well, that's so— yeah, that was very invaluable as well. And that is more of an open source mindset to me, because you're contributing on a different level. You're not necessarily contributing code, you're contributing on the understanding of other people of how to do something, how to solve it.
Okay, yeah, thank you. Yeah, another question. Do you have some, some words of advice for future students who are considering, you know, going for a software engineering degree or doing something else in, in the domain of software— could also be related to machine learning or AI or other broader meaning. So any, anything based on your own experience in the, in the last years that you would say, hey, this is very important to consider?
I think there are two things that come to mind here, and the first of that is that When I was studying, I was really somebody that, well, I valued going to a party, meeting friends, having a drink. But there were a lot of students in my year that did plenty of these exercises in their own spare time. So IT or programming was their hobby as well. And I really like this. It's not really my hobby. It's not my thing. So for a very long— or it's not really my thing, it is my thing, but it's not something I would do in my spare time. So, um, for a very long time I figured, okay, I'll be somewhere in the bottom rung because I'm not doing this on my spare time. I'm just okay, uh, not very special. Um, I think as times have changed, or the experience I've gained over the last 10 years seeing how I'm interacting with people, the value I still provide, even though I'm not somebody that— in this, well, in the attic I'm in right now, uh, also programs at night or in the weekend, I'm still there. So what I want to say with this, if you also feel acquainted like that, that you, you like this, you're okay with this, but it's not 100% everything you do Nothing wrong with that. You'll still get there. If you find joy in solving puzzles, which programming to me is, to building something tangible, between quotes, because you can't really touch code, right? Then you'll find a way eventually. Just go for it. And I had a second point, which I honestly forgot. My bad. This is definitely the most important one though. Yeah, good.
Now we can always circle back to the, to the other point another day. So, of course, yeah, thanks Stefan van Eerde for, for being with us. I'm just checking to see if we have some other questions from the audience, but I see if I can find something in the comment section, and if there are no other questions, then we'll call it a— yeah, I got a message now that there are no other questions right now. So, all right, so then we'll call it a day. And thank you, Stefan, for being with us, for joining the TechMind series here at Amsterdam Tech. And it was a pleasure to have you here in the studio. So hope to see you again soon.
Thanks. Yeah, thanks for having me. This was fun. Like I said, I'm always willing to help This is also helping, so—
Great. Thanks for being here. Yes.
Bye-bye.
Bye.









