Wednesday, 29 July 2026, 1:03 AM +02:00
The apartment is quiet. Just the hum of the fridge and the soft click of my keyboard. I've been at this for hours now, and I'm only just realizing how late it's gotten. But I wanted to get this down before I sleep, because something feels like it's starting to click.
I spent the evening working through the MDN tutorial on JavaScript functions. Not just skimming it — I mean really reading it, line by line, trying to hold the whole concept in my head before I even look at the examples. I called this "THE NET-OPENING" in my notes, which is a dramatic way of saying I'm trying to build a mental scaffold first. Before I see the code, what do I already understand? A function is a reusable block. It takes input, it does something, it returns output. That's the simple version. But then you get into function expressions versus declarations, arrow functions, parameters versus arguments, scope, closures… and suddenly the simple picture isn't enough. You need a richer model. You realize that functions aren't just procedures — they're objects, they're values you can pass around, they carry their own little bubble of memory with them. That's what I was trying to grasp before the tutorial filled in the details: the idea that a function is a thing with a life of its own, not just a list of instructions.
It's easy to rush into the examples and feel like you've learned something because you can mimic the pattern. But I don't want to just know the syntax. I want to know why it works that way, what problem it's solving. So I forced myself to pause and ask: What does it mean that functions are first-class objects? Why does that matter? And I think I'm starting to see it. It means you can compose them, pass behavior around like data, build abstractions that actually fit the shape of the problem instead of just writing step-by-step instructions. That's a shift in how you think about solving problems, not just a language feature.
The other chunk of my night went into software testing terms. I've been picking at this knowledge gap for a while now, and I decided to be systematic about it: research, read up, investigate. I'm working through Martin Fowler's article on mocks and stubs — I've got it open in another tab, and I keep going back to it between function exercises. The distinctions are subtle. A stub is just a stand-in, a canned answer. A mock is more active — it has expectations, it verifies behavior. One tests state, the other tests interaction. I'm still trying to internalize that, to feel the difference rather than just recite the definitions. I think what's stirring here is a growing awareness that testing isn't just about catching bugs. It's about designing your code. If you have to think about how you'll test something, you start writing it differently — more modular, more decoupled. And functions, the things I was studying earlier? They're the unit you're testing. So these two threads are braiding together in my head: the more I understand how to design a testable function, the better I understand what a function really is.
Nothing profound yet. I'm early in all of this. But I can feel the framework taking shape. It's not about any single fact I learned tonight — it's that I'm starting to ask better questions. Not just "how do I write a function?" but "how do I write a function that can be reasoned about in isolation?" Not just "what's a mock?" but "what does this testing approach tell me about the structure of my code?" That feels like a step toward becoming a real developer — not just someone who writes code, but someone who thinks through it.
Comments
No comments yet — be the first.