[{"data":1,"prerenderedAt":332},["ShallowReactive",2],{"systems-all":3},[4,135,241],{"id":5,"title":6,"slug":5,"company":7,"role":8,"period":9,"description":10,"isNda":11,"tags":12,"metrics":18,"highlights":22,"body":26,"bodyMarkdown":129,"order":130,"seo":131},"performance-as-a-frontend-discipline","Performance as a Frontend Discipline","Cross-project practice","Frontend Engineer \u002F Lead","2021 - Present","Performance work treated as a core frontend responsibility, not a final optimization pass.",false,[13,14,15,16,17],"performance","frontend","ux","architecture","product",[19,20,21],"Performance thinking integrated into implementation decisions","Faster interfaces and cleaner runtime behavior","Better user experience through practical frontend discipline",[23,24,25],"Treated performance as part of architecture, not cleanup","Focused on responsiveness and perceived speed, not only synthetic scores","Applied performance judgment across different products and stacks",[27,38,47,55,65,73,81,89,97,105,113,121],{"_key":28,"_type":29,"style":30,"markDefs":31,"children":32},"k0","block","h2",[],[33],{"_key":34,"_type":35,"text":36,"marks":37},"k1","span","Position",[],{"_key":39,"_type":29,"style":40,"markDefs":41,"children":42},"k2","normal",[],[43],{"_key":44,"_type":35,"text":45,"marks":46},"k3","Performance is one of the areas where frontend maturity becomes visible. It is rarely solved by one heroic optimization. More often, it is the result of many small technical choices made consistently over time.",[],{"_key":48,"_type":29,"style":30,"markDefs":49,"children":50},"k4",[],[51],{"_key":52,"_type":35,"text":53,"marks":54},"k5","Approach",[],{"_key":56,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":59,"children":60},"k6","bullet",1,[],[61],{"_key":62,"_type":35,"text":63,"marks":64},"k7","Make performance part of architecture discussions early",[],{"_key":66,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":67,"children":68},"k8",[],[69],{"_key":70,"_type":35,"text":71,"marks":72},"k9","Avoid shipping unnecessary complexity into the browser",[],{"_key":74,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":75,"children":76},"k10",[],[77],{"_key":78,"_type":35,"text":79,"marks":80},"k11","Pay attention to responsiveness, rendering cost, and user perception",[],{"_key":82,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":83,"children":84},"k12",[],[85],{"_key":86,"_type":35,"text":87,"marks":88},"k13","Prefer practical wins over benchmark theater",[],{"_key":90,"_type":29,"style":30,"markDefs":91,"children":92},"k14",[],[93],{"_key":94,"_type":35,"text":95,"marks":96},"k15","What This Usually Means",[],{"_key":98,"_type":29,"style":40,"markDefs":99,"children":100},"k16",[],[101],{"_key":102,"_type":35,"text":103,"marks":104},"k17","The work can involve many things: reducing waste in the rendering path, preventing avoidable slowdowns, simplifying heavy interfaces, and making better tradeoffs before problems harden into architecture.",[],{"_key":106,"_type":29,"style":40,"markDefs":107,"children":108},"k18",[],[109],{"_key":110,"_type":35,"text":111,"marks":112},"k19","I treat performance less as a specialty silo and more as a professional standard. Fast interfaces are not just a technical achievement. They change how reliable a product feels.",[],{"_key":114,"_type":29,"style":30,"markDefs":115,"children":116},"k20",[],[117],{"_key":118,"_type":35,"text":119,"marks":120},"k21","Why This Is Separate",[],{"_key":122,"_type":29,"style":40,"markDefs":123,"children":124},"k22",[],[125],{"_key":126,"_type":35,"text":127,"marks":128},"k23","This is presented as a standalone case because it cuts across roles and companies. It is a repeatable way of thinking, not a single isolated project.",[],"\n## Position\n\nPerformance is one of the areas where frontend maturity becomes visible. It is rarely solved by one heroic optimization. More often, it is the result of many small technical choices made consistently over time.\n\n## Approach\n\n- Make performance part of architecture discussions early\n- Avoid shipping unnecessary complexity into the browser\n- Pay attention to responsiveness, rendering cost, and user perception\n- Prefer practical wins over benchmark theater\n\n## What This Usually Means\n\nThe work can involve many things: reducing waste in the rendering path, preventing avoidable slowdowns, simplifying heavy interfaces, and making better tradeoffs before problems harden into architecture.\n\nI treat performance less as a specialty silo and more as a professional standard. Fast interfaces are not just a technical achievement. They change how reliable a product feels.\n\n## Why This Is Separate\n\nThis is presented as a standalone case because it cuts across roles and companies. It is a repeatable way of thinking, not a single isolated project.\n",3,{"title":132,"description":133,"ogImage":134,"noIndex":11},"Performance as a Frontend Discipline — ilsrbn","A cross-project view of frontend performance as a discipline, not a post-release optimization phase.",null,{"id":136,"title":137,"slug":136,"company":138,"role":139,"period":140,"description":141,"isNda":142,"tags":143,"metrics":147,"highlights":151,"body":155,"bodyMarkdown":236,"order":237,"seo":238},"sharkscode-frontend-architecture","Frontend Architecture & Technical Direction","Sharkscode","Frontend Team Lead","Aug 2024 - Present","Owning frontend architecture decisions, technical direction, and long-term maintainability across production work.",true,[16,14,144,145,146],"vue","nuxt","typescript",[148,149,150],"Architecture decisions aligned with delivery realities","Better maintainability across evolving frontend codebases","Technical direction shaped with production constraints in mind",[152,153,154],"Balanced delivery pressure with long-term code health","Chose technical directions that teams could realistically sustain","Stayed hands-on enough to keep architectural decisions grounded",[156,162,168,174,180,186,192,198,204,210,216,222,228],{"_key":28,"_type":29,"style":30,"markDefs":157,"children":158},[],[159],{"_key":34,"_type":35,"text":160,"marks":161},"Context",[],{"_key":39,"_type":29,"style":40,"markDefs":163,"children":164},[],[165],{"_key":44,"_type":35,"text":166,"marks":167},"Architecture work here is practical, not ornamental. The point is not to create ideal diagrams. The point is to make decisions that survive production pressure, team constraints, and real delivery timelines.",[],{"_key":48,"_type":29,"style":30,"markDefs":169,"children":170},[],[171],{"_key":52,"_type":35,"text":172,"marks":173},"Focus",[],{"_key":56,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":175,"children":176},[],[177],{"_key":62,"_type":35,"text":178,"marks":179},"Defining frontend direction without over-engineering",[],{"_key":66,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":181,"children":182},[],[183],{"_key":70,"_type":35,"text":184,"marks":185},"Keeping systems maintainable as scope evolves",[],{"_key":74,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":187,"children":188},[],[189],{"_key":78,"_type":35,"text":190,"marks":191},"Making architectural choices the team can actually support",[],{"_key":82,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":193,"children":194},[],[195],{"_key":86,"_type":35,"text":196,"marks":197},"Preserving development speed while avoiding fragile solutions",[],{"_key":90,"_type":29,"style":30,"markDefs":199,"children":200},[],[201],{"_key":94,"_type":35,"text":202,"marks":203},"Working Style",[],{"_key":98,"_type":29,"style":40,"markDefs":205,"children":206},[],[207],{"_key":102,"_type":35,"text":208,"marks":209},"This kind of architecture work depends on judgment. Every decision trades off speed, clarity, and future cost. The role requires staying close enough to implementation to understand the codebase honestly, while still thinking one or two layers above the immediate task.",[],{"_key":106,"_type":29,"style":30,"markDefs":211,"children":212},[],[213],{"_key":110,"_type":35,"text":214,"marks":215},"Why It Matters",[],{"_key":114,"_type":29,"style":40,"markDefs":217,"children":218},[],[219],{"_key":118,"_type":35,"text":220,"marks":221},"In many teams, architecture becomes disconnected from delivery. Here, the value comes from keeping them tied together. Technical direction is useful only when it helps the team build better, faster, and with less accidental complexity.",[],{"_key":122,"_type":29,"style":30,"markDefs":223,"children":224},[],[225],{"_key":126,"_type":35,"text":226,"marks":227},"Constraints",[],{"_key":229,"_type":29,"style":40,"markDefs":230,"children":231},"k24",[],[232],{"_key":233,"_type":35,"text":234,"marks":235},"k25","Specific clients, products, and implementation details are withheld. The public version is intentionally abstracted while preserving the real shape of the work.",[],"\n## Context\n\nArchitecture work here is practical, not ornamental. The point is not to create ideal diagrams. The point is to make decisions that survive production pressure, team constraints, and real delivery timelines.\n\n## Focus\n\n- Defining frontend direction without over-engineering\n- Keeping systems maintainable as scope evolves\n- Making architectural choices the team can actually support\n- Preserving development speed while avoiding fragile solutions\n\n## Working Style\n\nThis kind of architecture work depends on judgment. Every decision trades off speed, clarity, and future cost. The role requires staying close enough to implementation to understand the codebase honestly, while still thinking one or two layers above the immediate task.\n\n## Why It Matters\n\nIn many teams, architecture becomes disconnected from delivery. Here, the value comes from keeping them tied together. Technical direction is useful only when it helps the team build better, faster, and with less accidental complexity.\n\n## Constraints\n\nSpecific clients, products, and implementation details are withheld. The public version is intentionally abstracted while preserving the real shape of the work.\n",2,{"title":239,"description":240,"ogImage":134,"noIndex":11},"Frontend Architecture & Technical Direction — ilsrbn","Architecture decisions, technical direction, and maintainability work at Sharkscode.",{"id":242,"title":243,"slug":242,"company":138,"role":139,"period":140,"description":244,"isNda":142,"tags":245,"metrics":250,"highlights":254,"body":258,"bodyMarkdown":328,"order":58,"seo":329},"sharkscode-frontend-leadership","Frontend Leadership & Delivery","Leading frontend delivery, team growth, and execution quality across active client work in a fast-moving environment.",[246,14,247,248,249],"leadership","delivery","mentoring","process",[251,252,253],"Team leadership across active frontend delivery","Mentoring developers and raising execution quality","Stronger coordination between technical direction and delivery",[255,256,257],"Built a healthier balance between hands-on engineering and team leadership","Helped developers grow through day-to-day review, guidance, and support","Improved delivery predictability by making priorities and ownership clearer",[259,264,270,275,281,287,293,299,305,311,317,322],{"_key":28,"_type":29,"style":30,"markDefs":260,"children":261},[],[262],{"_key":34,"_type":35,"text":160,"marks":263},[],{"_key":39,"_type":29,"style":40,"markDefs":265,"children":266},[],[267],{"_key":44,"_type":35,"text":268,"marks":269},"This role sits at the intersection of leadership and hands-on engineering. The work is not limited to writing code. It includes shaping how the frontend team delivers, how technical decisions get made, and how developers grow over time.",[],{"_key":48,"_type":29,"style":30,"markDefs":271,"children":272},[],[273],{"_key":52,"_type":35,"text":172,"marks":274},[],{"_key":56,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":276,"children":277},[],[278],{"_key":62,"_type":35,"text":279,"marks":280},"Clarifying priorities and delivery expectations",[],{"_key":66,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":282,"children":283},[],[284],{"_key":70,"_type":35,"text":285,"marks":286},"Supporting the team through reviews, direction, and mentoring",[],{"_key":74,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":288,"children":289},[],[290],{"_key":78,"_type":35,"text":291,"marks":292},"Keeping implementation quality high without slowing delivery down",[],{"_key":82,"_type":29,"style":40,"listItem":57,"level":58,"markDefs":294,"children":295},[],[296],{"_key":86,"_type":35,"text":297,"marks":298},"Acting as the bridge between execution, architecture, and day-to-day team needs",[],{"_key":90,"_type":29,"style":30,"markDefs":300,"children":301},[],[302],{"_key":94,"_type":35,"text":303,"marks":304},"What This Work Looks Like",[],{"_key":98,"_type":29,"style":40,"markDefs":306,"children":307},[],[308],{"_key":102,"_type":35,"text":309,"marks":310},"In practice, this means helping the team move with less ambiguity. Some tasks are managerial, some are technical, and many sit in between: deciding where standards need to be enforced, where speed matters more, and where a developer needs guidance instead of just feedback.",[],{"_key":106,"_type":29,"style":40,"markDefs":312,"children":313},[],[314],{"_key":110,"_type":35,"text":315,"marks":316},"The strongest part of this role is not a single system or metric. It is the ability to keep delivery moving while raising the quality bar for the people doing the work.",[],{"_key":114,"_type":29,"style":30,"markDefs":318,"children":319},[],[320],{"_key":118,"_type":35,"text":226,"marks":321},[],{"_key":122,"_type":29,"style":40,"markDefs":323,"children":324},[],[325],{"_key":126,"_type":35,"text":326,"marks":327},"Client and project details are abstracted. The public version of this case focuses on the leadership shape of the work rather than implementation specifics.",[],"\n## Context\n\nThis role sits at the intersection of leadership and hands-on engineering. The work is not limited to writing code. It includes shaping how the frontend team delivers, how technical decisions get made, and how developers grow over time.\n\n## Focus\n\n- Clarifying priorities and delivery expectations\n- Supporting the team through reviews, direction, and mentoring\n- Keeping implementation quality high without slowing delivery down\n- Acting as the bridge between execution, architecture, and day-to-day team needs\n\n## What This Work Looks Like\n\nIn practice, this means helping the team move with less ambiguity. Some tasks are managerial, some are technical, and many sit in between: deciding where standards need to be enforced, where speed matters more, and where a developer needs guidance instead of just feedback.\n\nThe strongest part of this role is not a single system or metric. It is the ability to keep delivery moving while raising the quality bar for the people doing the work.\n\n## Constraints\n\nClient and project details are abstracted. The public version of this case focuses on the leadership shape of the work rather than implementation specifics.\n",{"title":330,"description":331,"ogImage":134,"noIndex":11},"Frontend Leadership & Delivery — ilsrbn","Frontend team leadership, delivery ownership, and mentoring work at Sharkscode.",1775381662721]