This isn’t a polished post with a clear thesis. It’s a log — an attempt to take stock of where things are while I’m still in the middle of them, rather than writing a retrospective from the comfortable distance of having figured it out.
I’m in my 3rd semester of a CS degree and simultaneously running a full-stack web development course. This wasn’t a clever plan. It’s just how it worked out, and I think it’s worth writing about honestly rather than framing it as a success story I haven’t actually finished yet.
The actual situation
The degree covers foundations: data structures, operating systems, computer networks, algorithms. Important material. Mostly abstract right now in the sense that I can’t always see clearly where it connects to the practical work I’m doing in the course and on my own projects. That connection becomes clearer over time, which is reassuring in retrospect and frustrating in the moment.
The course covers the practical layer: React, Node.js, Express, MongoDB, Firebase. Less abstract, immediately applicable. I can build something with it today and see it working. The gap between effort and visible output is much shorter, which is motivating in ways the degree sometimes isn’t.
Both are demanding. Running them simultaneously produces a specific kind of cognitive overload that I want to describe accurately: it’s not that any individual task is beyond what I can handle, it’s that the context-switching cost is real and cumulative. The mental mode required to work through a data structures problem is different from the mode required to debug a Node.js API. Switching between them multiple times a day has a cost that doesn’t show up on a task list.
What’s actually working
The overlap is more valuable than I expected. There have been several moments where something from the degree clicked differently because I’d seen it applied in the course first, or vice versa. When we covered database indexing in the course the same week I was studying B-tree implementations in a data structures module, something about both became more concrete than either would have been in isolation. I don’t think that’s incidental. Seeing the same concept from two different angles — theoretical and applied — is probably the most efficient learning I do.
Building outside of coursework is what keeps me honest. The projects on this portfolio exist because assigned work has a safety net: there’s a rubric, there are expected outputs, the scope is defined for you. Projects you build for yourself don’t have any of that. When something is broken and there’s no one to ask and no partial credit for effort, you either figure it out or you don’t. That constraint is where the real skill development happens. It’s uncomfortable in a way that assigned work usually isn’t, and I think that discomfort is the signal that it’s working.
Writing things down changed how I learn. I keep a plain text file with two sections: things I don’t understand yet, and things I thought I understood but got wrong. Looking back at it is the closest thing I have to a concrete measurement of progress, which is otherwise hard to track when you’re deep in the middle of learning something. The file is longer than it used to be, which means I’m encountering more things I don’t know — but it’s also more annotated, which means I’m coming back and resolving them.
What’s hard
Depth versus breadth is a real tension. The course moves quickly by design — covering a lot of ground to give you a working vocabulary. The result is that I frequently understand how to use something without fully understanding why it works or what it’s trading off against alternatives. That gap bothers me more than it probably should at this stage. I’m trying to be deliberate about coming back for depth on the things I use most, rather than feeling guilty about the breadth-first approach during the initial pass.
Time management is mostly just prioritisation under constraint. There isn’t enough time to do everything well. I’ve stopped trying to solve that and started being more deliberate about what gets deferred. Not everything needs to be done well right now. Some things need to be done adequately and shipped so I can move on to what’s actually important. Learning to make that call quickly, without spending twenty minutes feeling bad about the trade-off, is underrated as a skill.
Comparing timelines is a waste of attention. Other people appear to be further along, more certain, building more impressive things. Some of that is real. Most of it is the difference between what people show and what their actual process looks like. I’ve mostly stopped tracking it.
What I’d tell myself six months ago
Finish the portfolio and put it online sooner. Visible work is worth more than perfect work that nobody can see, and the act of shipping forces the kind of clarity that private projects don’t.
Get comfortable with the depth-first / breadth-first trade-off earlier. You can’t go deep on everything simultaneously. Choose deliberately rather than feeling guilty about everything you’re not deep on yet.
The things that feel hard are probably the things that are actually teaching you something. The things that feel easy might not be.
That’s approximately where I am. Not dramatic. Just continuing.