How I Approach Software Engineering
As a software engineer, my role goes far beyond writing code that compiles. Real engineering is about solving meaningful problems, communicating clearly, and understanding the broader impact of technical decisions. That includes how code behaves, how users experience it, and how it fits into the product’s long-term goals.
This post is not a résumé or a list of frameworks. It’s a reflection of the habits, principles, and mindset that guide how I work—regardless of the tech stack.
Strong Foundations That Go Beyond Any Framework
Some of the most valuable skills I’ve learned aren’t tied to one language or library. Clean code, separation of concerns, testable design, and clear thinking apply whether you’re building in Angular, React, or a backend service. When you understand the patterns and ideas behind the tools, it becomes easier to adapt, improve, and contribute across environments.
Frontend Expertise (Angular and Beyond)
I’ve worked extensively with Angular, including modern techniques like Signals and Standalone Components. My focus is on building modular, maintainable applications with clear structure and strong reusability.
I’ve also designed systems with complex asynchronous flows using RxJS, Angular signals, and service-based facades. On projects with real-time requirements, I’ve integrated SignalR to manage multiple live data streams. These implementations typically involve synchronising authentication, API states, and socket connections to ensure components only render when the right data is available.
Although Angular is my primary frontend tool, my deeper value lies in understanding where complexity lives and how to manage it. I focus on making that complexity predictable and easy for teams to work with.
Testing and Code Quality
I treat testing as a core part of development, not a separate phase. Whether using Jasmine, Jest, or writing code with testability in mind, I aim to bake quality into every layer.
I structure components to be as lean and “dumb” as possible, using input and output bindings to keep them focused on presentation. This design makes components easier to test, easier to reuse, and easier to showcase in tools like Storybook.
I consistently include data-testid attributes as part of my markup, not as an afterthought. These allow developers to write robust unit tests and enable QA teams to create automated scripts without chasing DOM changes. For me, writing test-friendly code means thinking about the entire lifecycle of the feature—from implementation through to testing and maintenance.
Clean Code and Clear Thinking
I prioritise readability over cleverness. I write small, purposeful functions, use clear naming, and separate concerns to keep complexity under control. Where appropriate, I introduce wrappers or facades early to reduce future refactor pain and keep teams focused on business logic, not boilerplate.
The goal isn’t to write perfect code. It’s to write code that’s easy to understand for my future self, my teammates, and the business that depends on it.
Practical, Delivery-Focused Approach
I have strong experience delivering MVPs, scoping features, and shipping under real-world constraints. That includes:
Collaborating with product teams to define realistic outcomes
Delivering in small, testable increments
Communicating technical trade-offs without jargon
Using CI/CD pipelines, code reviews, and static analysis tools as daily habits
I don’t just implement tickets. I solve problems with attention to quality, context, and end-user value.
Curiosity That Drives Consistency
Books That Shape My Thinking
I read regularly across topics like psychology, marketing, and personal development. Books like Thinking, Fast and Slow, Atomic Habits, The Psychology of Money, and The Mom Test influence how I think about user experience, product decisions, and clear communication.
Staying Current with the Tech Landscape
I follow engineering blogs, changelogs, and newsletters to stay up to date without chasing trends for their own sake. I stay aware of what’s evolving—framework updates, architectural shifts, tooling improvements—and choose what to adopt with intention.
Using AI with Intention
AI is part of how I work, but never a replacement for real engineering judgment. I use tools like ChatGPT and x.ai to explore ideas, compare strategies, and generate variations, especially when brainstorming or drafting. I take time to test outputs, question assumptions, and validate anything that feels uncertain.
I also design prompts to avoid echo chambers and reduce bias. For topics where AI has limitations, I follow up with practical research. AI supports my thinking—it doesn’t make decisions for me.
What I’m Not
Knowing what you don’t do is just as valuable as knowing what you do.
- I’m not a trend chaser. I adopt tools when they solve problems, not because they’re new.
- I’m not a “rockstar” developer. I favour collaboration, clarity, and consistency over complexity or bravado.
- I’m not tied to Angular. It’s where I’ve built deep experience, but my core practices apply across frameworks.
- I don’t just complete tasks. I think about what happens next—how it’s tested, maintained, and evolved over time.
Conclusion: Building With Intention
Whether I’m writing code, reviewing work, or collaborating with product teams, I bring a thoughtful, disciplined approach. I aim to write software that is not only functional, but dependable, understandable, and ready to scale.
I’m always learning and always looking for ways to improve. If you’re building something and this approach resonates with you, feel free to reach out.