[{"data":1,"prerenderedAt":970},["ShallowReactive",2],{"navigation":3,"index":34,"index-blogs":376,"mdc-ryc107-key":877,"mdc--7wvyqv-key":889,"mdc-oozyi2-key":898,"mdc--a9prnj-key":907,"mdc-2qxj0a-key":916,"mdc-citcb3-key":925,"mdc--k34o42-key":934,"mdc-y732a5-key":943,"mdc-6v1kev-key":952,"mdc--pl9eni-key":961},[4],{"title":5,"path":6,"stem":7,"children":8,"page":33},"Blog","\u002Fblog","blog",[9,13,17,21,25,29],{"title":10,"path":11,"stem":12},"Building a Reusable Skill for Vue 3: From Architecture Principles to a Published GitHub Standard","\u002Fblog\u002Fbuilding-a-reusable-skill-for-vue-3","blog\u002Fbuilding-a-reusable-skill-for-vue-3",{"title":14,"path":15,"stem":16},"From Engineer to Lead: The Shift Nobody Prepares You For","\u002Fblog\u002Ffrom-engineer-to-lead","blog\u002Ffrom-engineer-to-lead",{"title":18,"path":19,"stem":20},"Paginating Complex CTEs in PostgreSQL: Lessons from a Real Chat App","\u002Fblog\u002Fpaginating-complex-ctes-in-postgresql","blog\u002Fpaginating-complex-ctes-in-postgresql",{"title":22,"path":23,"stem":24},"Scaling Frontend Teams Without Losing Code Quality","\u002Fblog\u002Fscaling-frontend-teams-without-losing-code-quality","blog\u002Fscaling-frontend-teams-without-losing-code-quality",{"title":26,"path":27,"stem":28},"Taming Supabase Realtime in a Tauri App: Sleep, Wake, and Reconnection","\u002Fblog\u002Ftaming-supabase-realtime-in-a-tauri-app","blog\u002Ftaming-supabase-realtime-in-a-tauri-app",{"title":30,"path":31,"stem":32},"Why I Stopped Writing Components and Started Writing Composables","\u002Fblog\u002Fwhy-i-stopped-writing-components-and-started-writing-composables","blog\u002Fwhy-i-stopped-writing-components-and-started-writing-composables",false,{"id":35,"title":36,"about":37,"blog":40,"body":43,"description":44,"experience":45,"extension":64,"faq":65,"hero":108,"meta":137,"navigation":138,"path":139,"seo":140,"skills":143,"stem":345,"testimonials":346,"__hash__":375},"index\u002Findex.yml","Hey, I'm Junaid Rasheed, Principal Engineer & Software Architect",{"title":38,"description":39},"Architecting Systems, Leading Teams","I'm a Principal Engineer and Software Architect with 8+ years of experience leading engineering teams and designing the systems behind scalable, high-performance web applications. My focus is on the decisions that shape a product early—system architecture, technical direction, and the engineering standards that let teams move fast without piling up debt.\nI lead by staying close to the code: setting up architecture, reviewing critical paths, mentoring engineers, and shipping alongside the team across Vue.js, React, Ruby on Rails, and modern cloud infrastructure. I care most about building systems—and the teams behind them—that scale cleanly under real-world pressure.\n",{"title":41,"description":42},"Latest Articles","Some of my recent thoughts",null,"I lead engineering teams and architect scalable, high-performance web applications—while staying hands-on in the code. Based in Lahore, Pakistan, turning complex problems into clean architecture, clear technical direction, and teams that ship.",{"title":46,"items":47},"Work Experience",[48,56,60],{"position":49,"date":50,"company":51},"Principal Software Developer at","July 2023 - Present",{"name":52,"logo":53,"url":54,"color":55},"Strategic Systems International","\u002Favatars\u002Fssi-logo.png","https:\u002F\u002Fwww.linkedin.com\u002Fcompany\u002Fstrategic-systems-international","#1F2937",{"position":57,"date":58,"company":59},"Senior Software Developer at","July 2019 - June 2023",{"name":52,"logo":53,"url":54,"color":55},{"position":61,"date":62,"company":63},"Software Developer at","August 2017 - June 2019",{"name":52,"logo":53,"url":54,"color":55},"yml",{"title":66,"description":67,"categories":68},"Frequently Asked Questions","Answers to common questions about my work and expertise.",[69,84,96],{"title":70,"questions":71},"Services & Technical Expertise",[72,75,78,81],{"label":73,"content":74},"What services do you offer?","As a Principal Engineer and Software Architect, I offer end-to-end technical leadership and development services. This includes system architecture and technical direction, front-end development with Vue.js\u002FReact\u002FNuxt.js, back-end development with Ruby on Rails\u002FLaravel\u002FPython, database design and optimization, cloud infrastructure setup (AWS), CI\u002FCD pipeline implementation, API development, and performance optimization. I also lead and mentor engineering teams, run code reviews, and provide product and technical strategy guidance.\n",{"label":76,"content":77},"What is your development process like?","My process is collaborative and follows best practices: Requirements Analysis → Architecture & Planning → Development → Testing & Code Review → Deployment & Optimization → Ongoing Support. I emphasize clean code, scalability, performance optimization, and maintaining high test coverage. I leverage version control (Git), containerization (Docker), and CI\u002FCD pipelines to ensure reliable deployments.\n",{"label":79,"content":80},"What tech stack do you specialize in?","I specialize in modern web development with Vue.js, React, and Nuxt.js for front-end, Ruby on Rails and Laravel for back-end, PostgreSQL and MongoDB for databases, and AWS for cloud infrastructure. I'm also proficient in Python, Node.js, and various integrations like Stripe, Firebase, and Elasticsearch. I stay current with industry best practices and emerging technologies.\n",{"label":82,"content":83},"Do you work with startups and enterprises?","Absolutely! I have extensive experience working with both startups and established companies. For startups, I help build MVPs and scalable architectures from scratch. For enterprises, I lead optimization initiatives, architectural improvements, and team mentoring. I adapt my approach based on project stage and organizational needs.\n",{"title":85,"questions":86},"Projects & Engagement",[87,90,93],{"label":88,"content":89},"What types of projects do you take on?","I work on a wide variety of projects: real-time data dashboards, financial trading platforms, healthcare management systems, APIs, e-commerce platforms, analytics tools, and custom business applications. I'm particularly interested in performance-critical applications, complex system architectures, and projects requiring AWS infrastructure expertise.\n",{"label":91,"content":92},"How long does a typical project take?","Project timelines vary based on scope and complexity. Small projects (features or component work) might take 2-4 weeks. Medium projects (new applications or major features) typically take 2-3 months. Larger, complex systems can take 3-6 months or more. I always provide detailed timeline estimates after the discovery phase.\n",{"label":94,"content":95},"What about maintenance and ongoing support?","Yes, I offer ongoing support and maintenance services. This includes bug fixes, feature enhancements, performance optimization, security updates, and infrastructure maintenance. I provide both hourly support and monthly retainer options based on your needs.\n",{"title":97,"questions":98},"About Me & Work Style",[99,102,105],{"label":100,"content":101},"What do you enjoy most about development?","I love solving complex technical problems and seeing applications scale to serve thousands of users. The most rewarding part is optimizing performance—achieving 40-60% improvements in application speed is incredibly satisfying. I'm also passionate about mentoring developers and fostering a culture of clean, maintainable code and engineering excellence.\n",{"label":103,"content":104},"How do you approach code quality?","Code quality is paramount. I conduct regular code reviews, enforce best practices, maintain high test coverage with Jest and other testing frameworks, and use linting and static analysis tools. I believe that clean, well-documented code reduces technical debt and makes future development faster and safer.\n",{"label":106,"content":107},"What are your hobbies outside of work?","When I'm not coding, I enjoy contributing to open-source projects, exploring new technologies and frameworks, and sharing knowledge with the developer community. I'm also interested in DevOps, system design, and performance optimization techniques. Continuous learning keeps me sharp in this fast-evolving field.\n",{"images":109},[110,113,116,119,122,125,128,131,134],{"src":111,"alt":112},"\u002Fhero\u002Frandom-1.avif","Random Image 1",{"src":114,"alt":115},"\u002Fhero\u002Frandom-2.avif","Random Image 2",{"src":117,"alt":118},"\u002Fhero\u002Frandom-3.avif","Random Image 3",{"src":120,"alt":121},"\u002Fhero\u002Frandom-4.avif","Random Image 4",{"src":123,"alt":124},"\u002Fhero\u002Frandom-5.avif","Random Image 5",{"src":126,"alt":127},"\u002Fhero\u002Frandom-6.avif","Random Image 6",{"src":129,"alt":130},"\u002Fhero\u002Frandom-7.avif","Random Image 7",{"src":132,"alt":133},"\u002Fhero\u002Frandom-8.avif","Random Image 8",{"src":135,"alt":136},"\u002Fhero\u002Frandom-9.avif","Random Image 9",{},true,"\u002F",{"title":141,"description":142},"Junaid Rasheed - Principal Engineer & Software Architect","Welcome to my portfolio! I'm Junaid Rasheed, a Principal Engineer and Software Architect with 8+ years of experience. Based in Lahore, Pakistan, I lead engineering teams and design scalable systems across Vue.js, React, Ruby on Rails, and modern cloud infrastructure—while staying hands-on in the code.",{"title":144,"description":145,"categories":146},"What I bring to the table","A diverse set of skills that help me design, develop and deliver impactful digital products.",[147,200,218,241,249,282,299,322],{"name":148,"items":149},"Front-end Stack",[150,155,160,165,170,175,180,185,190,195],{"name":151,"icon":152,"description":153,"color":154},"Vue.js","i-simple-icons-vuedotjs","Building reactive, component-driven UIs","#42B883",{"name":156,"icon":157,"description":158,"color":159},"React.js","i-simple-icons-react","Building scalable UI components","#61DAFB",{"name":161,"icon":162,"description":163,"color":164},"Nuxt.js","i-simple-icons-nuxtdotjs","Full-stack apps with SSR & SSG","#00DC82",{"name":166,"icon":167,"description":168,"color":169},"Vite","i-simple-icons-vite","Lightning-fast build tooling","#646CFF",{"name":171,"icon":172,"description":173,"color":174},"Redux","i-simple-icons-redux","Predictable app state at scale","#764ABC",{"name":176,"icon":177,"description":178,"color":179},"Pinia","i-simple-icons-pinia","Intuitive Vue state management","#FFD859",{"name":181,"icon":182,"description":183,"color":184},"Tailwind CSS","i-simple-icons-tailwindcss","Crafting responsive, polished design","#06B6D4",{"name":186,"icon":187,"description":188,"color":189},"Node.js","i-simple-icons-nodedotjs","Fast, scalable server-side apps","#5FA04E",{"name":191,"icon":192,"description":193,"color":194},"Tailwind UI","i-lucide-layout-template","Accessible, prebuilt UI components","#38BDF8",{"name":196,"icon":197,"description":198,"color":199},"Figma","i-simple-icons-figma","Designing & prototyping interfaces","#F24E1E",{"name":201,"items":202},"Back-end Stack",[203,208,213],{"name":204,"icon":205,"description":206,"color":207},"Ruby on Rails","i-simple-icons-rubyonrails","Robust back-end architecture","#CC0000",{"name":209,"icon":210,"description":211,"color":212},"Laravel (PHP)","i-simple-icons-laravel","Elegant PHP web applications","#FF2D20",{"name":214,"icon":215,"description":216,"color":217},"Python","i-simple-icons-python","Automation, scripting & APIs","#3776AB",{"name":219,"items":220},"Databases",[221,226,231,236],{"name":222,"icon":223,"description":224,"color":225},"PostgreSQL","i-simple-icons-postgresql","Reliable relational data modeling","#4169E1",{"name":227,"icon":228,"description":229,"color":230},"MySQL","i-simple-icons-mysql","Battle-tested relational storage","#4479A1",{"name":232,"icon":233,"description":234,"color":235},"Indexed DB","i-lucide-database","Client-side browser storage","#F59E0B",{"name":237,"icon":238,"description":239,"color":240},"MongoDB","i-simple-icons-mongodb","Flexible NoSQL data storage","#47A248",{"name":242,"items":243},"Testing",[244],{"name":245,"icon":246,"description":247,"color":248},"Jest","i-simple-icons-jest","Confident unit & integration tests","#C21325",{"name":250,"items":251},"Integrations",[252,257,262,267,272,277],{"name":253,"icon":254,"description":255,"color":256},"Stripe","i-simple-icons-stripe","Seamless payment integrations","#635BFF",{"name":258,"icon":259,"description":260,"color":261},"Open AI","i-simple-icons-openai","AI-powered product features","#10A37F",{"name":263,"icon":264,"description":265,"color":266},"Google Analytics","i-simple-icons-googleanalytics","Data-driven usage insights","#E37400",{"name":268,"icon":269,"description":270,"color":271},"Firebase","i-simple-icons-firebase","Realtime data & auth services","#FFCA28",{"name":273,"icon":274,"description":275,"color":276},"Elasticsearch","i-simple-icons-elasticsearch","Fast, full-text search at scale","#43A047",{"name":278,"icon":279,"description":280,"color":281},"Typesense","i-lucide-search","Typo-tolerant instant search","#EC4899",{"name":283,"items":284},"CI\u002FCD",[285,290,295],{"name":286,"icon":287,"description":288,"color":289},"Git","i-simple-icons-git","Version control & collaboration","#F05032",{"name":291,"icon":292,"description":293,"color":294},"Docker","i-simple-icons-docker","Containerized, portable deployments","#2496ED",{"name":296,"icon":297,"description":298},"Vercel","i-simple-icons-vercel","Effortless front-end deployments",{"name":300,"items":301},"DevOps (AWS)",[302,307,311,315,319],{"name":303,"icon":304,"description":305,"color":306},"EC2","i-lucide-server","Scalable compute instances","#FF9900",{"name":308,"icon":309,"description":310,"color":306},"ECR","i-lucide-container","Managed container registry",{"name":312,"icon":313,"description":314,"color":306},"S3","i-lucide-hard-drive","Durable object storage",{"name":316,"icon":317,"description":318,"color":306},"Lambda","i-lucide-zap","Serverless function execution",{"name":320,"icon":233,"description":321,"color":306},"RDS","Managed relational databases",{"name":323,"items":324},"Others",[325,330,335,340],{"name":326,"icon":327,"description":328,"color":329},"API Development","i-lucide-webhook","Designing robust REST APIs","#6366F1",{"name":331,"icon":332,"description":333,"color":334},"Code Review","i-lucide-git-pull-request","Raising code quality & standards","#8B5CF6",{"name":336,"icon":337,"description":338,"color":339},"Product Management","i-lucide-target","Aligning delivery with goals","#14B8A6",{"name":341,"icon":342,"description":343,"color":344},"Performance Optimization","i-lucide-gauge","Optimizing for speed and great UX","#22C55E","index",[347,354,361,368],{"quote":348,"author":349},"Junaid demonstrates exceptional analytical skills and consistently approaches coding with a strong focus on optimization and efficiency. His technical mindset and solutions-oriented approach make him a valuable developer.",{"name":350,"description":351,"avatar":352},"M Awais Sarwar","CEO @ Bitsclan",{"src":353},"\u002Favatars\u002Fawais-sarwar.jpeg",{"quote":355,"author":356},"I had the privilege of working with Junaid at SSI. He is proactive, result-oriented, technically sound, and always ready to dedicate his full energy and time to deliver quality work. His impressive background and profile make him a great asset to any company.",{"name":357,"description":358,"avatar":359},"Muhammad Bilal Anjum","Software QA Engineer | Automation & Testing Expert",{"src":360},"\u002Favatars\u002Fbilal-anjum.jpeg",{"quote":362,"author":363},"Junaid is among the best developers I've ever worked with. He's hardworking, broad-minded, and forward-thinking. Intelligent, ambitious, energetic, and a proactive perfectionist—his desire for proficiency and continuous learning makes him invaluable to any team. Working with Junaid Rasheed is a signature of success.",{"name":364,"description":365,"avatar":366},"Haider Ali Anjum","Senior Full-Stack Engineer | JavaScript | React | GraphQL",{"src":367},"\u002Favatars\u002Fhaider-ali.jpeg",{"quote":369,"author":370},"Junaid is an excellent programmer and problem solver with strong leadership qualities. His deep experience in web technologies and his professional approach make him exceptional. He's also a quick learner who consistently delivers quality work.",{"name":371,"description":372,"avatar":373},"Asad Jamil","iOS | React Native | Flutter Developer",{"src":374},"\u002Favatars\u002Fasad-jamil.jpeg","1IaroKdl4C2l_tVxkYpBwxoS8nFw6nvnf8tOVf2kXtc",[377,547,683],{"id":378,"title":30,"author":379,"body":385,"date":539,"description":540,"extension":541,"image":542,"meta":543,"minRead":544,"navigation":138,"path":31,"seo":545,"stem":32,"__hash__":546},"blog\u002Fblog\u002Fwhy-i-stopped-writing-components-and-started-writing-composables.md",{"name":380,"username":381,"to":382,"avatar":383},"Junaid Rasheed","junaidrasheed","https:\u002F\u002Fgithub.com\u002Fjunaidrasheed",{"src":384,"alt":380},"\u002Favatars\u002Fme.png",{"type":386,"value":387,"toc":529},"minimark",[388,392,407,412,415,422,428,432,435,438,441,445,451,457,463,467,470,488,494,500,506,510,513,516,519,523,526],[389,390,391],"p",{},"There's a pattern every Vue developer goes through. You start writing components. Then you write more components. Then you write components that contain other components. Then one day you open a file and there's a 600-line component that does seventeen things and you have no idea how it got that way.",[389,393,394,395,399,400,399,403,406],{},"The answer is always the same: you put logic where the framework made it easy to put logic. And in Vue 2, that was the component. The Options API encouraged it. ",[396,397,398],"code",{},"data",", ",[396,401,402],{},"methods",[396,404,405],{},"computed"," — all neatly organized by type, not by concern. It looked tidy. It wasn't.",[408,409,411],"h2",{"id":410},"the-real-problem-with-component-first-thinking","The real problem with component-first thinking",[389,413,414],{},"The issue isn't components themselves — it's using them as the primary unit of reuse. When your instinct is \"I need to reuse this, I'll make a component,\" you end up with two problems.",[389,416,417,421],{},[418,419,420],"strong",{},"You couple logic to rendering."," A component that fetches data and displays it is doing two completely separate jobs. Reusing the display means dragging along the fetching. Reusing the fetching means dragging along the display. Neither is what you actually wanted.",[389,423,424,427],{},[418,425,426],{},"You create implicit dependencies."," Components communicate through props and emits, which is fine at small scale and progressively painful as the tree deepens. By the time you're prop-drilling through four levels or reaching for an event bus, you've built a distributed system inside your UI layer. Congratulations, you've invented microservices for your frontend. Nobody is happy about this.",[408,429,431],{"id":430},"what-composables-actually-are","What composables actually are",[389,433,434],{},"The Vue 3 Composition API introduced composables — functions that encapsulate reactive logic and can be used in any component, regardless of what that component renders.",[389,436,437],{},"The mental model shift is this: a composable is not a component without a template. It's a unit of behavior. It owns state and the logic that operates on that state. It doesn't care about rendering at all.",[389,439,440],{},"A component's job is to decide what to show and how to respond to user input. A composable's job is to manage the logic and state that the component needs to do that. When you split them cleanly, both become dramatically simpler.",[408,442,444],{"id":443},"where-the-shift-shows-up","Where the shift shows up",[389,446,447,450],{},[418,448,449],{},"Data fetching."," This is the clearest win. A composable that handles fetching, loading state, error state, and retry logic can be dropped into any component that needs it. The component just consumes the result. You write the fetching logic once, test it independently, and never think about it again in the context of a specific component.",[389,452,453,456],{},[418,454,455],{},"Form handling."," Forms are where component-first thinking produces the most pain. Validation logic, field state, submission handling, error display — none of that needs to live in the component. A composable that takes a schema and returns field state and validation results keeps the component focused on layout and nothing else.",[389,458,459,462],{},[418,460,461],{},"Shared reactive state."," When multiple components need access to the same piece of state, the composable becomes the single source of truth. Not a store for everything — just a scoped, intentional owner of one concept. This is often the right tool before reaching for a full state management solution.",[408,464,466],{"id":465},"the-rules-that-make-composables-actually-work","The rules that make composables actually work",[389,468,469],{},"Not all composables are created equal. The pattern can produce beautiful, reusable logic or a different kind of mess if you're not deliberate about it.",[389,471,472,475,476,479,480,483,484,487],{},[418,473,474],{},"Name them by what they do, not what they're for."," ",[396,477,478],{},"useUserProfile"," is a component-specific name. ",[396,481,482],{},"useAsyncData"," or ",[396,485,486],{},"useFormValidation"," is a behavioral name. The behavioral name travels. The component-specific name doesn't.",[389,489,490,493],{},[418,491,492],{},"Return only what the consumer needs."," It's tempting to expose everything from a composable \"just in case.\" Resist this. Every exposed value is a contract. The smaller the surface area, the easier the composable is to use, test, and change later.",[389,495,496,499],{},[418,497,498],{},"Keep them focused on one concern."," A composable that handles fetching AND caching AND error formatting AND retry logic is a component in disguise. Split it. Composables compose — that's the whole point. A composable can call another composable.",[389,501,502,505],{},[418,503,504],{},"Don't reach for composables for everything."," Simple derived state that's only used in one place belongs in the component. The overhead of extracting it into a composable isn't worth it. Extract when there's a genuine reuse case or when the logic is complex enough to warrant isolated testing.",[408,507,509],{"id":508},"the-testing-benefit-nobody-talks-about-enough","The testing benefit nobody talks about enough",[389,511,512],{},"Composables are just functions. Functions are easy to test. You don't need to mount a component, simulate user interactions, or worry about the DOM. You call the function, interact with the returned state, and assert the result.",[389,514,515],{},"This is a significant quality-of-life improvement. Testing component logic that lives inside the component requires testing through the component. Testing the same logic in a composable is three lines of setup. The tests are faster, more focused, and much easier to read and maintain.",[389,517,518],{},"If you find yourself writing complex component tests to cover logic, that logic probably belongs in a composable.",[408,520,522],{"id":521},"the-mental-model-in-one-sentence","The mental model in one sentence",[389,524,525],{},"Components decide what to show. Composables decide what's true.",[389,527,528],{},"When that division is clear, components get simpler, logic gets reusable, and the codebase becomes something you can actually navigate six months after writing it. Which, in frontend development, is about as close to utopia as we get.",{"title":530,"searchDepth":531,"depth":531,"links":532},"",2,[533,534,535,536,537,538],{"id":410,"depth":531,"text":411},{"id":430,"depth":531,"text":431},{"id":443,"depth":531,"text":444},{"id":465,"depth":531,"text":466},{"id":508,"depth":531,"text":509},{"id":521,"depth":531,"text":522},"2026-06-17","Using components as the primary unit of reuse couples logic to rendering and breeds 600-line files. The mental model shift that makes Vue 3 codebases navigable six months later.","md","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F3993855\u002Fpexels-photo-3993855.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},6,{"title":30,"description":540},"rsmg2K7YAeFKmI0g4TT2ZqBDMGCq1aFiwcK0LUquPNU",{"id":548,"title":14,"author":549,"body":551,"date":676,"description":677,"extension":541,"image":678,"meta":679,"minRead":680,"navigation":138,"path":15,"seo":681,"stem":16,"__hash__":682},"blog\u002Fblog\u002Ffrom-engineer-to-lead.md",{"name":380,"username":381,"to":382,"avatar":550},{"src":384,"alt":380},{"type":386,"value":552,"toc":668},[553,556,559,563,566,569,572,576,579,582,585,588,592,598,604,610,616,620,623,636,639,642,646,649,652,655,659,662,665],[389,554,555],{},"Nobody gives you a manual when you become a lead. One day you're heads-down in a ticket, the next you're running a planning meeting, unblocking three people simultaneously, and somehow still expected to ship code. It's a role that sounds like a promotion and feels like a completely different job.",[389,557,558],{},"Because it is.",[408,560,562],{"id":561},"the-thing-they-dont-tell-you","The thing they don't tell you",[389,564,565],{},"When you're an individual contributor, your output is visible and measurable. You shipped the feature. You fixed the bug. You can point to the PR. At the end of the day, you know whether you did your job.",[389,567,568],{},"When you become a lead, your best work becomes invisible. You asked the right question in a planning meeting that prevented two weeks of rework. You gave feedback on a junior engineer's approach before they went down the wrong path. You noticed that two teams were solving the same problem differently and quietly aligned them. None of that shows up in a commit history.",[389,570,571],{},"This is disorienting at first. Engineers are trained to measure their value by what they build. Leads create value by shaping what others build — and that requires a completely different feedback loop.",[408,573,575],{"id":574},"the-coding-trap","The coding trap",[389,577,578],{},"Most new leads fall into one of two failure modes.",[389,580,581],{},"The first is holding on too tightly to the code. You're still the best technical contributor on the team, and it feels good to be in the code. So you stay there. You take the hardest tickets. You become the bottleneck for every complex problem. The team grows but your habits don't, and six months later you're overwhelmed, your engineers aren't growing, and nothing ships without you.",[389,583,584],{},"The second is abandoning the code entirely. You've heard that \"real leads don't code\" (you haven't, but it feels implied), so you step back. You go full calendar. You lose touch with the codebase, your technical credibility starts to erode, and you find yourself unable to push back on estimates or spot bad architectural decisions because you're no longer close enough to the work.",[389,586,587],{},"The actual job lives in the tension between these two. You need to stay technical enough to be credible and useful, while deliberately creating space for your engineers to own the hard problems. That balance shifts constantly and there's no formula for it.",[408,589,591],{"id":590},"what-actually-changes","What actually changes",[389,593,594,597],{},[418,595,596],{},"Your definition of \"done\" expands."," A feature isn't done when the code is merged. It's done when the engineer who built it understands it well enough to maintain it, when the edge cases are covered, when the next engineer can pick it up without a walkthrough. You start thinking in systems rather than tasks.",[389,599,600,603],{},[418,601,602],{},"Ambiguity becomes your daily environment."," Individual contributors mostly work with well-defined problems. Leads work with poorly defined ones. \"We need to improve performance\" is not a ticket — it's a direction. Translating vague organizational intent into concrete, actionable work for your team is a skill you have to develop from scratch, and it's harder than any technical problem you've solved.",[389,605,606,609],{},[418,607,608],{},"Your calendar becomes the product."," How you spend your time directly determines what your team can and can't do. A blocked engineer who can't get 30 minutes with you this week is an engineer who loses a day or more of progress. Time management stops being a personal productivity habit and becomes a team responsibility.",[389,611,612,615],{},[418,613,614],{},"You absorb uncertainty so your team doesn't have to."," Priorities shift. Roadmaps change. Stakeholders disagree. A big part of the lead role is acting as a buffer — taking in the chaos from above and translating it into something stable and actionable for the engineers on your team. They should be able to focus. That focus is something you actively protect.",[408,617,619],{"id":618},"the-mentoring-misconception","The mentoring misconception",[389,621,622],{},"A lot of new leads think mentoring means teaching. It doesn't — or at least, not primarily. The most effective mentoring is mostly asking questions.",[624,625,626,630,633],"ul",{},[627,628,629],"li",{},"\"What approaches did you consider?\"",[627,631,632],{},"\"What do you think the tradeoff is here?\"",[627,634,635],{},"\"How would you handle it if this constraint changed?\"",[389,637,638],{},"When you give an engineer the answer, they learn the answer. When you ask them the right questions, they learn how to think. The second one scales. The first one just makes them dependent on you for the next problem.",[389,640,641],{},"This is also better for you. If your engineers can reason through hard problems independently, you're not the ceiling on what they can accomplish. That's how you build a team that can operate without you in the room — which is, counterintuitively, exactly what a good lead aims for.",[408,643,645],{"id":644},"the-visibility-problem","The visibility problem",[389,647,648],{},"Here's something that takes too long to learn: if your work is invisible, you have to make it visible.",[389,650,651],{},"Not in a self-promotional way — in a communication way. Write up the architectural decision you steered. Share the context behind a tradeoff in your team channel. Send the summary after a difficult planning session. These aren't vanity exercises. They create a paper trail of the thinking that's actually driving the team, they help engineers understand context they wouldn't otherwise have, and they make your contributions legible to the people who make decisions about your career.",[389,653,654],{},"Individual contributors can sometimes get away with letting the code speak for itself. Leads can't. The work is too distributed, too contextual, and too process-oriented to be self-evident. You have to narrate it.",[408,656,658],{"id":657},"the-honest-summary","The honest summary",[389,660,661],{},"Becoming a lead is not a reward for being a great engineer. It's a different role that requires different skills, a different feedback loop, and a willingness to measure your success by other people's growth rather than your own output.",[389,663,664],{},"Some great engineers make terrible leads. Some average engineers make exceptional leads. The skills barely overlap.",[389,666,667],{},"If you're considering the transition, go in with eyes open. The job is harder in ways you won't anticipate, more rewarding in ways you won't expect, and almost nothing like what you imagined. That's not a warning — it's just the truth. And knowing it going in puts you ahead of where most people start.",{"title":530,"searchDepth":531,"depth":531,"links":669},[670,671,672,673,674,675],{"id":561,"depth":531,"text":562},{"id":574,"depth":531,"text":575},{"id":590,"depth":531,"text":591},{"id":618,"depth":531,"text":619},{"id":644,"depth":531,"text":645},{"id":657,"depth":531,"text":658},"2026-06-10","Becoming a lead sounds like a promotion and feels like a completely different job — because it is. On invisible work, the coding trap, and measuring success by other people's growth.","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F3862615\u002Fpexels-photo-3862615.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},7,{"title":14,"description":677},"t5M1mNwfk-dxDnwLlPx2OO8J2saOrV5N7tOFEfxQ9Uo",{"id":684,"title":10,"author":685,"body":687,"date":871,"description":872,"extension":541,"image":873,"meta":874,"minRead":680,"navigation":138,"path":11,"seo":875,"stem":12,"__hash__":876},"blog\u002Fblog\u002Fbuilding-a-reusable-skill-for-vue-3.md",{"name":380,"username":381,"to":382,"avatar":686},{"src":384,"alt":380},{"type":386,"value":688,"toc":863},[689,692,695,698,702,705,708,711,715,727,730,733,737,740,760,763,766,792,796,807,810,813,816,820,823,826,832,838,844,848,851,854,857,860],[389,690,691],{},"At some point in every senior engineer's career, you have a realization: you've explained the same architectural pattern for the seventh time this month. Different engineer, different PR, same feedback. Same problem, same solution, same comment written slightly differently.",[389,693,694],{},"That's not mentoring. That's a missing abstraction.",[389,696,697],{},"This post is about what I did about it — and why codifying your standards into something shareable is one of the highest-leverage things a senior engineer can do.",[408,699,701],{"id":700},"the-problem-with-tribal-knowledge","The problem with tribal knowledge",[389,703,704],{},"Most teams run on tribal knowledge. The senior engineers know how things should be done. Junior engineers learn by getting feedback on PRs, asking questions in Slack, and gradually absorbing the patterns over months of exposure. It works, eventually. But it's slow, it's inconsistent, and it scales terribly.",[389,706,707],{},"The senior engineer becomes a bottleneck. Every non-trivial PR needs their eye on it. Onboarding new engineers takes forever because there's no single source of truth — just a collection of examples scattered across the codebase and a handful of people who hold the context in their heads.",[389,709,710],{},"The worst part? When those people leave, the knowledge leaves with them. Tribal knowledge has no version history.",[408,712,714],{"id":713},"what-a-skill-actually-is","What a \"skill\" actually is",[389,716,717,718,722,723,726],{},"I started thinking about this differently: what if the patterns I kept explaining in reviews were just... documentation? Not a wiki page that nobody reads, but an opinionated, structured reference that captures not just ",[719,720,721],"em",{},"what"," to do but ",[719,724,725],{},"why"," — and that could be handed to any engineer (or AI coding assistant) and immediately produce code at the standard you actually want.",[389,728,729],{},"That's what I built for Vue 3. A skill — a compact, structured document that encodes senior-level patterns for the Composition API: how composables should be structured, how state should be managed, how components should be split, how validation should be handled, how tests should be written.",[389,731,732],{},"Not a style guide. Not a list of rules. A working standard with rationale.",[408,734,736],{"id":735},"what-goes-into-it","What goes into it",[389,738,739],{},"The key insight is that a useful standard has to answer three questions for every pattern it covers:",[624,741,742,748,754],{},[627,743,744,747],{},[418,745,746],{},"What"," — the concrete pattern or structure being recommended",[627,749,750,753],{},[418,751,752],{},"Why"," — the reasoning behind it, not just \"because I said so\"",[627,755,756,759],{},[418,757,758],{},"What not to do"," — the anti-pattern it replaces, and why that's worse",[389,761,762],{},"Most style guides only answer the first question. That's why engineers ignore them under pressure — they follow rules they understand and skip the ones that feel arbitrary. When the reasoning is visible, engineers internalize the principle, not just the syntax. They apply it in situations the guide never anticipated.",[389,764,765],{},"For Vue 3 specifically, the areas that needed the most opinionated guidance were:",[624,767,768,774,780,786],{},[627,769,770,773],{},[418,771,772],{},"Composable design"," — when to extract, how to name, what to expose",[627,775,776,779],{},[418,777,778],{},"Component responsibility"," — the boundary between \"smart\" and \"dumb\" components",[627,781,782,785],{},[418,783,784],{},"TypeScript integration"," — not just \"use types\" but how to type props, emits, and composable return values in a way that's actually useful",[627,787,788,791],{},[418,789,790],{},"Testing philosophy"," — what to test, what not to test, and why unit testing implementation details is a trap",[408,793,795],{"id":794},"the-process-of-writing-it","The process of writing it",[389,797,798,799,802,803,806],{},"Writing this kind of document is harder than it sounds, for one reason: you have to separate what you ",[719,800,801],{},"do"," from what you ",[719,804,805],{},"should do",".",[389,808,809],{},"Senior engineers accumulate habits. Some of those habits are genuinely good patterns. Some are historical artifacts from older versions of the framework, or workarounds for problems that no longer exist, or just personal preferences that never got challenged. Writing a standard forces you to interrogate your own practices.",[389,811,812],{},"\"Why do I do it this way? Is this actually better, or is it just familiar?\"",[389,814,815],{},"That process is uncomfortable and extremely valuable. I rewrote sections multiple times after realizing I was documenting a habit rather than a principle. The final document was better for it — and so was my own understanding of the codebase.",[408,817,819],{"id":818},"communicating-it-to-the-team","Communicating it to the team",[389,821,822],{},"A standard nobody knows about is just a file on GitHub. Getting the team to actually use it requires a different kind of effort than writing it.",[389,824,825],{},"A few things that helped:",[389,827,828,831],{},[418,829,830],{},"Frame it as a resource, not a mandate."," Engineers who feel like standards are being imposed on them resist them. Engineers who feel like they have access to a useful reference use it. The framing matters more than you'd expect.",[389,833,834,837],{},[418,835,836],{},"Walk through it in a team session."," Not a lecture — a conversation. Let engineers push back on the patterns, ask why, suggest alternatives. Some of the best additions to the standard came from those discussions. It also creates shared ownership, which is what makes standards actually stick.",[389,839,840,843],{},[418,841,842],{},"Reference it in reviews, don't replace reviews with it."," When you leave a comment pointing to a section of the standard, you're doing two things: giving specific actionable feedback, and reinforcing that the standard exists and is being actively used. Eventually engineers start referencing it themselves before submitting PRs.",[408,845,847],{"id":846},"why-this-is-worth-your-time","Why this is worth your time",[389,849,850],{},"The ROI on this kind of work is slow and invisible at first. You write the standard, you share it, and nothing obviously changes the next day.",[389,852,853],{},"But three months later, the PR feedback you're leaving has shifted. You're catching architectural issues earlier, because engineers are catching the obvious ones themselves. Onboarding new engineers is faster because there's something concrete to point them to. The tribal knowledge has a home. It's versioned. It can be updated. It can be shared outside the team.",[389,855,856],{},"And the next time you find yourself writing the same code review comment for the eighth time, you don't write it — you update the standard instead.",[389,858,859],{},"That's the compounding return. One document, maintained well, that makes every future review, every onboarding, and every architectural discussion slightly more efficient. Over a year, that's an enormous amount of recovered time and transferred knowledge.",[389,861,862],{},"Senior engineers are often evaluated on their code. The best ones get evaluated on how much better the engineers around them become. A published standard is one of the clearest ways to make that impact visible.",{"title":530,"searchDepth":531,"depth":531,"links":864},[865,866,867,868,869,870],{"id":700,"depth":531,"text":701},{"id":713,"depth":531,"text":714},{"id":735,"depth":531,"text":736},{"id":794,"depth":531,"text":795},{"id":818,"depth":531,"text":819},{"id":846,"depth":531,"text":847},"2026-06-03","When you've explained the same architectural pattern for the seventh time this month, that's not mentoring — it's a missing abstraction. How I codified senior-level Vue 3 patterns into a shareable standard.","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F2004161\u002Fpexels-photo-2004161.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},{"title":10,"description":872},"mwCKOocAKp9BzT2E8z1dy1gWenUdE_oV0hlZjOc4vjI",{"data":878,"body":879},{},{"type":880,"children":881},"root",[882],{"type":883,"tag":389,"props":884,"children":885},"element",{},[886],{"type":887,"value":888},"text","As a Principal Engineer and Software Architect, I offer end-to-end technical leadership and development services. This includes system architecture and technical direction, front-end development with Vue.js\u002FReact\u002FNuxt.js, back-end development with Ruby on Rails\u002FLaravel\u002FPython, database design and optimization, cloud infrastructure setup (AWS), CI\u002FCD pipeline implementation, API development, and performance optimization. I also lead and mentor engineering teams, run code reviews, and provide product and technical strategy guidance.",{"data":890,"body":891},{},{"type":880,"children":892},[893],{"type":883,"tag":389,"props":894,"children":895},{},[896],{"type":887,"value":897},"My process is collaborative and follows best practices: Requirements Analysis → Architecture & Planning → Development → Testing & Code Review → Deployment & Optimization → Ongoing Support. I emphasize clean code, scalability, performance optimization, and maintaining high test coverage. I leverage version control (Git), containerization (Docker), and CI\u002FCD pipelines to ensure reliable deployments.",{"data":899,"body":900},{},{"type":880,"children":901},[902],{"type":883,"tag":389,"props":903,"children":904},{},[905],{"type":887,"value":906},"I specialize in modern web development with Vue.js, React, and Nuxt.js for front-end, Ruby on Rails and Laravel for back-end, PostgreSQL and MongoDB for databases, and AWS for cloud infrastructure. I'm also proficient in Python, Node.js, and various integrations like Stripe, Firebase, and Elasticsearch. I stay current with industry best practices and emerging technologies.",{"data":908,"body":909},{},{"type":880,"children":910},[911],{"type":883,"tag":389,"props":912,"children":913},{},[914],{"type":887,"value":915},"Absolutely! I have extensive experience working with both startups and established companies. For startups, I help build MVPs and scalable architectures from scratch. For enterprises, I lead optimization initiatives, architectural improvements, and team mentoring. I adapt my approach based on project stage and organizational needs.",{"data":917,"body":918},{},{"type":880,"children":919},[920],{"type":883,"tag":389,"props":921,"children":922},{},[923],{"type":887,"value":924},"I work on a wide variety of projects: real-time data dashboards, financial trading platforms, healthcare management systems, APIs, e-commerce platforms, analytics tools, and custom business applications. I'm particularly interested in performance-critical applications, complex system architectures, and projects requiring AWS infrastructure expertise.",{"data":926,"body":927},{},{"type":880,"children":928},[929],{"type":883,"tag":389,"props":930,"children":931},{},[932],{"type":887,"value":933},"Project timelines vary based on scope and complexity. Small projects (features or component work) might take 2-4 weeks. Medium projects (new applications or major features) typically take 2-3 months. Larger, complex systems can take 3-6 months or more. I always provide detailed timeline estimates after the discovery phase.",{"data":935,"body":936},{},{"type":880,"children":937},[938],{"type":883,"tag":389,"props":939,"children":940},{},[941],{"type":887,"value":942},"Yes, I offer ongoing support and maintenance services. This includes bug fixes, feature enhancements, performance optimization, security updates, and infrastructure maintenance. I provide both hourly support and monthly retainer options based on your needs.",{"data":944,"body":945},{},{"type":880,"children":946},[947],{"type":883,"tag":389,"props":948,"children":949},{},[950],{"type":887,"value":951},"I love solving complex technical problems and seeing applications scale to serve thousands of users. The most rewarding part is optimizing performance—achieving 40-60% improvements in application speed is incredibly satisfying. I'm also passionate about mentoring developers and fostering a culture of clean, maintainable code and engineering excellence.",{"data":953,"body":954},{},{"type":880,"children":955},[956],{"type":883,"tag":389,"props":957,"children":958},{},[959],{"type":887,"value":960},"Code quality is paramount. I conduct regular code reviews, enforce best practices, maintain high test coverage with Jest and other testing frameworks, and use linting and static analysis tools. I believe that clean, well-documented code reduces technical debt and makes future development faster and safer.",{"data":962,"body":963},{},{"type":880,"children":964},[965],{"type":883,"tag":389,"props":966,"children":967},{},[968],{"type":887,"value":969},"When I'm not coding, I enjoy contributing to open-source projects, exploring new technologies and frameworks, and sharing knowledge with the developer community. I'm also interested in DevOps, system design, and performance optimization techniques. Continuous learning keeps me sharp in this fast-evolving field.",1782657703533]