I’ve identified as a full-stack web developer for years, starting with my first job where I dove deep into SQL, ASP.NET, jQuery, and JavaScript. My journey with jQuery began in 2016 (yes, a bit late), and it was my first glimpse into dynamic web frontends. Through my involvement with the VirtoCommerce project, I also gained exposure to AngularJS and Shopify’s Liquid template system.
In 2020, I shifted to a backend developer role, which introduced me to Linux, Docker, Message Queues, and DevOps. Working with high-throughput systems taught me the critical importance of robust backend architecture — a revelation that shaped my understanding of system design.
By 2022, I returned to full-stack development, this time leading web development initiatives. I introduced modern technologies like React, TypeScript, React-Admin, React Query, SignalR, and EF Core to the team. This experience taught me several valuable lessons:
- Effective communication is crucial when adopting new frameworks
- While frameworks are replaceable, core domain knowledge is permanent (as emphasized in “Clean Architecture”)
- A framework’s community and resources significantly impact its viability
- The size of the community matters
- Consider whether the framework is popular enough for generative AI tools to provide meaningful assistance
- User experience is critical, but UI implementation is somewhat inessential
My perspective on UI’s importance has crystallized over recent months:
- While UI creates the first impression, content remains the core value
- Using the Kano Model as reference, UI elements are often “exciters” while content represents “must-haves”
- With limited resources, prioritize completing all must-have features to ensure basic quality
- This aligns with YAGNI and the principle that “Premature Optimization Is The Root Of All Evil”
- Additionally, developing applications without concrete content, context, and requirements violates YAGNI
- Full-stack developers often struggle to efficiently create polished UIs
- This work is better suited for dedicated designers or frontend specialists
I’ve noticed that CI/CD and Developer Experience (DX) share similar characteristics:
- Source code represents the core content
- Features are closer to must-haves, while DX improvements are more like exciters
- Achieving excellence in DX requires dedicated effort and commitment
From my experience, here are some guidelines for selecting the right tools:
- Commit to one framework or design system at a time
- Success comes from understanding requirements and comprehending the primitives of the chosen tool (good primitives also lead to success)
- Identifying requirements early helps avoid switching tools
- Switching tools mid-project is costly
- Consider the cost of: workarounds, source code modifications, paid features, or finding a new tool
- This insight helps determine whether to choose a high-level abstraction tool or a low-level one
- High-level abstraction tools offer ease of use but limited customization
- Sometimes, simpler tools with good primitives, combined with generative AI, provide better results
- Switching tools mid-project is costly
- While libraries are more modular and replaceable
- Stick to one at a time to maintain lean dependencies and consistency
These insights stem from various experiences:
- Developing a custom ERP for a small business instead of adopting existing solutions
- Exploring headless and framework-agnostic design while building a proof-of-concept
- Creating a personal productivity app without established usage patterns
- Over-customizing a default website theme instead of starting with a well-designed template
While these experiences have made me better equipped for similar challenges, mastering UI, DX, and product development remains an ongoing journey. Some call it “learning development the hard way.” Though I don’t have all the answers, “failing fast” seems to be a viable approach.
For full-stack developers, I believe the key is to continue exploring and experimenting with short iterations. This process often leads to discovering your niche and strengths. Here are some opportunities I’m considering:
- Creating a data converter between LogSeq and LibreOffice to leverage LibreOffice’s table editing capabilities
- Integrating Astro frontend with headless backends (e.g., LogSeq, WordPress, Odoo)
- Installing a local LLM for note analysis
- Using n8n to introduce new interfaces and streamline the workflows mentioned above
Hopefully, one of these paths leads to a fulfilling “full-stack developer” career 🤓