Development hasn’t been my main focus for a while. My family had a bit of a scare that pulled a lot of my time and attention away from projects and personal work. When things like that happen, priorities shift quickly.
And honestly, they should.
But things are finally starting to settle down again.
My daughter is wrapping up some of the programs she’s been involved in, summer is right around the corner ☀️, and the schedule is starting to open back up.
Which means it’s time to hit the turbo button. 🚀
This post is also a bit of a personal reflection, but more than that, it’s a way of turning thoughts into action. Writing it down makes the plan real. It moves it from something that’s just been floating around in my head to something that actually exists outside of it.
One of my biggest priorities right now is ramping up the job search.
I’ve been thinking about making a move for a while, but now I’m planning to really lean into it.
More applications.
More conversations.
More opportunities to level up.
The goal isn’t just to change roles, it’s to find the right environment where I can continue growing as an engineer and contributing at a higher level.
A little nervous? Sure.
But mostly excited.
I’ve also been thinking about improvements to my Planning Poker application.
One idea I’m excited about is something I’m calling The Observer feature.
Right now, most planning poker tools assume everyone in the room is actively voting. But real teams don’t always work like that.
Sometimes people just need to observe the session:
The Observer role would allow someone to join a session and follow along without submitting estimates.
It’s a small idea, but I think it could make the tool much more useful for real-world teams.
Another thing that’s been on my mind is improving how this dev blog is organized.
Right now I manually organize posts into monthly folders. It works fine, but it definitely feels like something that could be automated.
I’ve been thinking about building a small solution that automatically sorts posts into their proper month based on the publish date.
It’s not a huge problem to solve, but small workflow improvements like that tend to pay off over time.
The last few months were a reminder that life doesn’t always move in straight lines.
Sometimes development slows down.
Sometimes priorities shift.
Sometimes your focus just needs to be somewhere else.
But things are starting to open back up again.
More building.
More experimenting.
More writing.
More shipping.
And now that the plan is written down here, it’s not just a thought anymore.
It’s something to follow through on.
Time to press the turbo button. 🚀
]]>This stretch has been a lot of heads-down, unglamorous work. Bug fixes and documentation aren’t the kinds of things that get applause in a demo, but I’m starting to believe they’re where a lot of real growth actually happens.
There’s a certain kind of developer humility that only comes from spending hours hunting down a bug that turns out to be a single off-by-one error, a missing null check, or a race condition you introduced two weeks ago and forgot about. 😅
I’ve been deep in that world lately. A steady queue of fixes, each one requiring me to slow down, read code carefully, and actually understand what’s happening rather than just what I want to happen.
A few things I’ve been reminded of through this process:
Debugging is a skill, not a punishment. It forces you to engage with code at a level that feature work sometimes doesn’t. You can’t skim when you’re hunting a bug.
Reading code is just as important as writing it. Fixes often live in code you didn’t write. Getting comfortable navigating unfamiliar territory is a core part of growing as a dev.
Small wins compound. One bug fix feels minor. Ten bug fixes means the product is meaningfully more stable. That matters to real users.
I’ll be honest, there were moments it felt monotonous. But I kept reminding myself: every fix is a problem I now understand that I didn’t before. That’s not nothing.
On top of the bug work, I took on something I hadn’t touched before: putting together documentation for our Strapi CRM implementation.
If you’re not familiar, Strapi is a headless CMS that gives you a lot of flexibility for managing content and data structures. Getting familiar with how it’s set up and how our team is going to use it was genuinely interesting and a little humbling. 🧩
There’s always a learning curve when you step into a system you haven’t built yourself. A lot of “okay, why is it configured this way?” moments. But working through that confusion to produce clear documentation forced me to actually understand it rather than just get a surface-level feel for it.
That distinction matters. Writing documentation you’d want to read means you can’t fake understanding.
Documentation has a reputation problem. It’s often treated as the thing you do when the real work is done, an afterthought, a checkbox.
Good documentation is an act of respect. Respect for the next developer who has to work in the same system. Respect for your team’s time. And honestly, respect for your future self when you come back to something six months later and have no idea what you were thinking. 😂
Writing the Strapi docs also forced me to think about clarity in a way that code doesn’t always demand. You can write working code that’s hard to follow. You can’t write useful documentation that’s hard to follow, it just becomes useless.
If I had to summarize what I took away from this period of work:
The unglamorous work is where consistency is built. Features get the spotlight, but stability and knowledge-sharing are what make a team actually function well over time.
New tools are only intimidating until you spend time with them. Strapi went from “I’ve heard of that” to something I can speak to with confidence. That shift came from doing the work, not just reading about it.
Documenting your own understanding is one of the best learning tools there is. If you can’t explain it clearly, you probably don’t fully get it yet. Writing forces that honesty.
Not every entry in this blog is going to be about a breakthrough or a new concept mastered. Sometimes it’s going to be about the weeks where the growth happened quietly, in the form of bugs squashed and knowledge preserved. This was one of those weeks and I’m glad I showed up for it. 🛠️
]]>At first glance that might sound intimidating, but honestly, I’m excited about it.
Stepping into multiple projects at once forces you to quickly understand different architectures, patterns, and decisions that were made before you arrived. It’s a great way to sharpen your awareness as a developer. Instead of living inside one codebase for months or years, you start seeing how different teams solve similar problems.
One thing I’ve noticed over time is how valuable a fresh perspective can be.
When developers stay on the same project for a long time, patterns and decisions become “the way things are done.” Sometimes those decisions were made for good reasons. Other times they just stuck around because no one questioned them.
When someone new enters the project, they naturally ask questions like:
Those questions aren’t criticism — they’re opportunities. 💡
Sometimes a fresh perspective leads to better workflow standards, cleaner abstractions, or even small improvements that remove friction the team didn’t realize had built up.
Another thing I enjoy about this kind of transition is the learning that comes from exposure.
Each project tends to have its own quirks:
Seeing those variations helps you grow faster as a developer because you start recognizing patterns across systems instead of just within one codebase.
It also makes you more adaptable, which is one of the most valuable skills an engineer can have.
Taking ownership of multiple front-end projects definitely comes with responsibility. There’s more context to manage and more systems to understand.
But challenges like this are where growth happens. 🚀
If nothing else, it’s a great reminder that development isn’t just about writing code. It’s about collaboration, perspective, and constantly learning from the systems and people around you.
And sometimes all it takes to unlock better ideas is a fresh set of eyes.
]]>But I have been thinking a lot about maintainability and honestly, that might be more important.
Shipping is visible. It feels productive. You close a ticket, merge a PR, deploy, move on. ✅
Maintainability is quieter. It doesn’t always show up in release notes. But it absolutely shows up six months later when someone (usually you) has to modify what you built.
There’s a difference between code that works and code that lasts.
Working code:
Maintainable code:
The second one requires restraint.
It requires thinking past the dopamine hit of “it works” and asking, “What happens when this changes?”
Future you is less patient.
Future you doesn’t remember the assumptions you made. Future you doesn’t remember why that helper exists. Future you just wants to fix a bug quickly and move on.
If your code requires a mental archaeology expedition 🏺, you’ve already lost.
Maintainability is about reducing cognitive load:
Nothing fancy. Just intentional.
Abstraction is powerful… until it isn’t.
It’s easy to chase elegance and end up building something that technically reduces duplication but increases complexity. If someone has to trace through five layers of indirection to understand a simple transformation, that abstraction isn’t helping.
Sometimes duplication is cheaper than cleverness.
There’s a balance between DRY and clarity. And clarity usually wins.
The more I think about it, the more I believe maintainability is what separates solid mid-level work from senior-level thinking.
Anyone can get a feature across the finish line.
But can you:
Great engineers don’t just ship code. They lower the long-term cost of change. 📉
That’s the standard I’m trying to hold myself to.
Even if I’m not shipping something flashy right now, sharpening that mindset still feels like forward progress.
]]>Part of me really wants to start posting development videos on YouTube. The other part immediately asks, “Who do you think you are?” 😅
But the more I think about it, the more it makes sense.
I’d probably start simple with basic LeetCode problems. Walk through the solution. Explain how I approach it. Talk through what signals I’m looking for and why I choose one path over another.
Nothing flashy. Just real problem-solving.
And honestly? Teaching forces clarity.
If I can explain why something is O(n) instead of O(n²), or why I chose a hashmap over nested loops, then I actually understand it. If I struggle to explain it, that’s feedback.
That kind of pressure is growth.
Sure, it could help elevate my status in the eyes of employers. A public record of how I think is powerful.
But what excites me more is this:
If I want to step into senior-level responsibility, communication and mentorship matter. This feels aligned with that.
Am I willing to grow in public?
Because that’s what this really is.
And I think the answer might be yes. 🚀
]]>For a long time, I assumed the gap was mostly technical.
Learn more patterns.
Design better systems.
Write cleaner code.
Grind long enough and you level up, right?
But the deeper I get into this craft, the more I realize the difference isn’t just skill.
It’s awareness.
It’s responsibility.
It’s influence.
And honestly? That’s heavier than just writing good code.
Anyone who spends enough time writing code will improve technically. That part is inevitable. You debug enough production issues, refactor enough messy modules, and architect enough features and you just get better.
But seniority isn’t just about can you build it?
It’s about:
Senior engineers don’t just ship features.
They think in systems.
They think about scalability.
They think about readability.
They think about how the machine executes what they wrote.
That depth matters.
The more I observe senior engineers, the more I notice something subtle.
They’re translators.
They can:
The ability to explain code might be just as important as writing it.
You can be brilliant technically, but if no one understands your reasoning, your impact is limited.
Confidence matters.
But so does humility.
The best seniors I’ve seen are steady. Calm. Clear. They correct without belittling. They teach without flexing.
That balance is hard. Harder than solving most algorithm problems.
Mid-level engineers often focus on personal output.
Senior engineers optimize the environment around them.
That might look like:
It’s leverage.
Instead of being the fastest person in the room, you make the whole room faster.
That’s a different level of contribution.
This is the part that’s been sitting with me the most.
If you carry the title “senior,” you carry influence.
Anyone can grind long enough to gain technical depth.
But are you helping someone else grow?
Are you:
A senior developer doesn’t just produce good systems.
They help produce good engineers.
And that’s a bigger legacy than any single codebase.
There’s also something less tangible: identity.
Not social media branding. Not noise.
But clarity.
Do people trust your judgment?
Do they feel safe asking you questions?
Senior engineers influence the room. That influence comes from consistency, competence, and character.
I don’t think the gap between mid-level and senior is just technical anymore.
It’s depth.
It’s communication.
It’s process awareness.
It’s mentorship.
It’s humility under pressure.
Anyone can eventually gain the technical ability to be labeled senior.
But how much can you contribute to the bigger picture?
That’s the real question.
I don’t just want the title.
I want to be the kind of engineer who elevates the room. 💡
]]>It just changes shape.
Right now, as I step back into the job search, I can feel it creeping in again. The timing is predictable. It always shows up around interviews.
You can ship real features. You can architect systems. You can debug production issues without panicking.
And then an interview gets scheduled… and suddenly your brain goes:
“What if you actually don’t know anything?”
It’s wild.
You’ll be productive for months building real applications, solving real problems and then a whiteboard question about reversing a linked list makes you question your entire existence. 😅
The gap between practical engineering and interview performance is where imposter syndrome thrives.
Job searching as a developer isn’t just about being good at your job.
It’s about:
That’s a different skill set.
You can be a strong engineer and still feel rusty in an interview setting. That doesn’t mean you’re unqualified. It means performance anxiety is real.
There’s also the comparison trap. You read job descriptions that list every framework ever created. You scroll LinkedIn and see someone announcing a new senior role. It’s easy to think everyone else is ahead.
They’re not. They’re just visible.
In tech, the learning never stops. There’s always:
So the bar feels infinite.
You might think:
But “should” is a dangerous word.
The reality? If you’ve been consistently building, shipping, and learning, you’re not an imposter. You’re growing.
A few things I’m actively keeping in perspective:
Imposter syndrome isn’t proof you’re a fraud. It’s often proof that you care.
I’m nervous.
There’s pressure in job searching. Financial pressure. Career pressure. Identity pressure. When you’re a developer, your skill set can feel tied directly to your self-worth.
That’s dangerous territory if you’re not careful.
But I’m also excited.
Excited for growth.
Excited for new challenges.
Excited for the version of myself that exists on the other side of this process.
If imposter syndrome shows up, fine. It can ride in the passenger seat. It just doesn’t get to drive. 🚗
If you’re going through interviews right now and feeling the same thing: you’re not broken, and you’re definitely not alone.
Keep building. Keep applying. Keep showing up.
You belong here.
]]>Whether you’re doing front-end work or full-stack projects, understanding Big O helps you write code that scales and avoids nasty surprises down the line.
Big O notation is a way to describe how the runtime (or space) of an algorithm grows as the size of the input increases.
Instead of worrying about exact milliseconds, Big O focuses on the trend, how the algorithm behaves when the dataset gets bigger.
const firstItem = arr[0];
Accessing the first element of an array? Boom. Constant.
arr.forEach(item => console.log(item));
Go through 10 items → 10 operations. 1,000 items → 1,000 operations.
for (let i = 0; i < arr.length; i++) {
for (let j = 0; j < arr.length; j++) {
console.log(arr[i], arr[j]);
}
}
Input doubles → operations quadruple. Scales badly.
function binarySearch(arr, target) {
let left = 0, right = arr.length - 1;
while (left <= right) {
const mid = Math.floor((left + right) / 2);
if (arr[mid] === target) return mid;
if (arr[mid] < target) left = mid + 1;
else right = mid - 1;
}
return -1;
}
Huge datasets? Still fast.
Big O helps you:
Even for everyday front-end tasks, understanding complexity can help you write smarter loops, filters, and data transformations.
Big O isn’t scary, it’s a tool. Treat it like a lens that shows your code’s behavior under pressure. Once you see it that way, it’s actually kind of fun.
Next steps for me: build a cheat sheet, practice analyzing small snippets of my own projects, and finally stop pretending that the traveling salesman problem isn’t terrifying. 😅
]]>I’ve spent a lot of time honing my skills in frontend development, UX improvements, and full-stack problem solving. My current setup has been great for growth, but it’s time to find a role that challenges me further and gives me space to level up even more.
There’s a lot to consider: technical interviews, resume tweaks, cover letters that don’t feel like boilerplate. Even after years of coding, putting yourself out there for a role is stressful. It’s a reminder that being a developer isn’t just about writing code, it’s about communicating your skills and experience effectively.
On the flip side, this is thrilling. The opportunity to explore new teams, technologies, and projects is motivating. It’s also a chance to reflect on what I’ve learned so far and articulate the value I can bring.
Plus, I get to brush up on my interview skills, which is always a good exercise. (Also, slightly terrifying. 😅)
It’s a lot, but that’s the point. This is the start of a journey, not just a single step.
Starting today, the search is on. Nerves aside, I’m excited to see where this path leads. Here’s to growth, challenges, and new opportunities. 🚀
]]>Spoiler: it’s going well.
One of the first things I tackled was cleaning up how the backend handles environments. I updated the BE so it works in both production and local development without changing the code.
If API_BASE_URL is not provided, the logic now defaults to localhost—backend included. That means I can develop and test features locally without worrying about accidentally impacting production behavior.
This kind of setup removes friction. Less config juggling. Fewer “why is this broken locally?” moments. Just run it and go.
On the frontend, I reworked the login flow to behave like a real application instead of a client-only shortcut.
The auth token is now stored in cookies so it can be validated at the server level during SSR. That opened the door to properly securing the admin portal instead of just hoping the UI behaves.
I added frontend middleware (admin-auth.ts) that does the following:
validateToken methodThis ensures users without valid credentials never even reach the admin UI. No flashing content. No half-loaded pages. Just a clean denial.
Exactly how it should be.
I also started updating the flow for creating a project, which is where things get interesting and complicated.
This isn’t a single request. It’s a sequence of linked operations across multiple tables:
All of this logic already exists in the backend. I can run every step via SQL prompts or Postman without issues.
The remaining work is on the frontend: building the payloads correctly and wiring the UI to the backend endpoints.
The good news?
The UI/UX for this entire flow is essentially complete. A few minor tweaks remain, but structurally it’s done. What’s left is implementation, not design, which is the part where you get that warm fuzzy feeling seeing the fruits of your labor post a finished product.
Coming back to this project was a reminder of something every developer learns the hard way:
You can be super organized when you start a project and still get lost when you return later.
It took a bit to reorient myself. Not because the code was bad, but because context fades. That moment of “okay… where exactly was I?” is unavoidable.
It was also a solid reminder of why clean code, documentation, and repo organization matter, even when you’re working solo. Future-you is still another developer, and future-you does not remember everything.
Overall, I’m genuinely excited about how this is shaping up. The foundations are solid, the architecture is doing its job, and I’m past the vague phase and back into concrete progress.
Now it’s just execution; and that’s a good place to be. 🚀
]]>