[THREAD] It's a new year, and I'm so excited to see what's coming for us here at @LinkedInEng! My team has so many incredible #EmberJS projects on our roadmap, and 2022 is looking to be a huge year.
Prepare yourselves for a thread...
TLDR: We're hiring, come join us!
1/
What do we do, you might ask? Well, my team is called "LTS UI Infra", which means that we're focused on enabling product teams within LinkedIn Talent Solutions (LTS) to ship applications faster and with higher quality by empowering them with the right set of tools. 2/
What is LinkedIn Talent Solutions? We're at the core of @LinkedIn's business and are the central piece of the hiring marketplace. Our organization owns the foundations of LinkedIn's talent ecosystem and builds tools and solutions to support consumer and business experiences. 3/
I have been leading our Developer Experience (DX) track for the past year and a half. My vision is to improve the DX of LTS frontend engineers to enable increase productivity and satisfaction with their development workflows. That's why we use #EmberJS, and it's working! 4/
I administer a quarterly survey to measure our frontend developers' satisfaction with their technologies, tools, and processes, and we have consistently trended upward since my team was formed. In fact, last quarter we set an all-time high satisfaction score! 5/
We achieved this by organizing our team's charter around four key efforts:
* Upgraded our apps from #EmberJS 3.8 to 3.26
* Converted 60% of existing code to native JS classes
* Converted 75% of existing code to Angle Brackets
* Enabled Ember Octane for new code (53% of our components are Glimmer)
... 7/
We also:
* Became the first major @LinkedIn app to adopt GraphQL
* Built a Puppeteer-based live test framework to catch critical regressions in alpha deployments
* Led huge accessibility compliance efforts across LTS
* Created a framework for actionable/debuggable errors
... 8/
But wait, there's more!
* Standardized JS & template linting across 70+ repos within LTS
* Adopted Lint TODOs to help manage rollout of new lint rules and keep ourselves accountable
* Drove early adoption of GitHub Enterprise for our organization's repositories
... 9/
Beyond execution, we introduced new processes:
* Revamped our production oncall process to improve training, handoff, tracking, and shift duration
* Launched an infrastructure project board that saw 10 projects staffed or completed in addition to our own roadmap in 2021
... 10/
We worked to improve knowledge-sharing too:
* Hosted a weekly frontend-oriented brownbag session with 44(!) unique talks throughout 2021, featuring speakers from our own org and across @LinkedInEng
* Started a monthly company-wide meetup of infra-focused frontend engineers
11/
I'm so incredibly proud of the work my colleagues have done. We did all of this with just a small, passionate team; 9 developers at its largest, often fewer. Our impact can't be overstated, either: we had <1.2 million lines of code in Jan 2021, now >1.4 million a year later!
12/
Our work has enabled dozens of product teams to ship hundreds of thousands of lines of code to production over the last year, using the latest modern JavaScript and #EmberJS patterns that make them more productive than ever before. We're not stopping there, either.
13/
Our 2022 roadmap is PACKED with exciting projects:
* Enable Embroider builds in production
* Complete Octane migration of existing code
* Leverage yarn workspaces to merge many of our 70+ #EmberJS projects together
* Rolling out SSR after a test showing 37% web vitals gain
14/
...and that's just what we're focused on this quarter alone! There's so much more we can do to make a huge impact on the future of engineering in LTS and @LinkedInEng as a whole, not to mention helping drive technologies that make this possible within the #EmberJS community.
15/
That's where you come in. The LTS UI Infra team is hiring, and we want YOU to help us achieve these lofty goals and more! We're looking to increase our full-time staffing by 80% this quarter, and we want the best Staff/Senior #EmberJS engineers to be part of our mission.
16/
If you're interested in making a huge impact on the future of frontend development for over a hundred product engineers, you're in the right place. If you love #EmberJS and want to keep pushing it forward to be the best it can be, this is the opportunity for you!
17/
Reach out to me over Twitter or Discord (Axle#3134 or Jordan in the #EmberJS community), and I'd be happy to talk to you about our work! Our main offices are in the San Francisco Bay Area, but we're a remote-friendly US-based team.
After three years here at @LinkedInEng, I can tell you that the future has never looked brighter for what we're positioned to accomplish with your help. Come join me and we'll push the boundaries of modern web development together!
P.S. - TypeScript is on the horizon, thanks to incredible efforts by @chriskrycho and other amazing folks outside my team who are pushing it forward at our company! We can't wait to get it on our roadmap.
@chriskrycho P.P.S. - Ember 4.0 is a high priority for 2022 as well, and you joining our team will help us move it further up our roadmap to tackle as soon as possible! We already have most of the deprecations we need from 3.26, and if we land 3.28 we can immediately be paying down that debt.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A thread on JavaScript technology, application architecture, frameworks, and #EmberJS:
When it comes to choosing your technology stack for web applications, your personal philosophy of architecture design comes into play. I want to talk a little about my perspective.
1/11
Some developers are tinkerers. They really enjoy being an architect of *things*. It's a great feeling to point to something and say "I designed that myself!". Everyone has a different level of tolerance for how deep they're willing to go to build bespoke architecture.
2/11
That's not inherently a good or bad thing, but it comes down to a matter of preference. At what level do you want to be tinkering? The compiler? The framework? The application? The component? Everyone has their own desires and goals, which drive their technology choices.
@Wellington_Tds@garrickcheung One of the biggest problems with the route-action helper is that it becomes very difficult to track the flow of data in your application. Data Down Actions Up exists to be a predictable flow of data through every level of your application. route-action allows you to bypass it.
@Wellington_Tds@garrickcheung The reason this is bad is that you now have to reason about where an action is going. Let's say you have three levels of nested routes in your application and 10 levels of nested components. You put a route-action on the leaf component (level 10). Where does that go? Which route?
@Wellington_Tds@garrickcheung As applications grow and scale, this problem becomes worse. What if you've broken your application into multiple addons or engines? route-action might be targeting an action that isn't even defined in the SAME REPOSITORY.