Alvin Sng

Want a preview of what I'm going to be talking about in my keynote for RubyConf? You can catch a glimpse of it here!

10

After nearly two years as Principal Developer Advocate at Gradle Inc. (with a recent shift to a part-time advisory role), I’m ready to dive back into a full-time senior IC+lead position. Ideally, I’m looking for a player-coach kind of role where I can leverage my experience building and scaling #DevRel strategies while staying hands-on with the tech and community. What I bring to the table: * Proven results: Helped take JFrog from inception to a $6B IPO. At Gradle Inc., I created and led impactful DevRel strategies integrating Product, Marketing, and Sales. * Content powerhouse: Delivered keynotes, conference talks, podcasts, blogs, videos—you name it. * Team leader: Guided and grew advocacy teams while delivering measurable impact (e.g., leading DevRel at JFrog, creating and leading the #BuildPropulsionLab, a program that generated hundreds of VIP interviews and valuable insights for Gradle). * Tech expertise: Deep knowledge of #DevOps, #DevSecOps, #CloudNative tech, #JVM, CI/CD pipelines, and everything in between. * Community advocate: A decade-plus of engaging developers, from conference stages to open-source communities. What I’m excited about: * Building bridges between developers and products that make their lives easier. * Tackling developer experience challenges in cutting-edge spaces like #AI, #DevOps, and #DevX. * Working at the intersection of technical excellence and strategic growth. If you’re hiring—or know someone who is—I’d love a referral or share. Let’s make some DevRel magic happen! 🔥

377

26 Comments

Sup fam!! Relationships are everything!! They're the core of your engineering platform. Your team's design docs, software patterns, pull requests, and GitOps workflows all need to pass through a complex network of relationships before becoming meaningful to stakeholders. Before that, they're just bytes sitting on Jeff Bezos' disks. How are your relationships doing? Which relationships need some light touching up? Which ones need some serious investment? How about that one person on that one team? How about on _your_ team? Are you tracking these gaps with the same effectiveness you're tracking tech debt? It takes an intentional effort to build meaningful connections and to show peers you're a stakeholder in _their_ success. It's worth your time -- not to mention you'll feel great!! Want to optimize your engineering platform? Start by investing in your relationships!

38

on hiring an ea While companies like Athena and Wing are popular options, they come with challenges I didn't like: * Time zone differences * Cultural gaps * High initial costs ($3000+/month) Instead, leverage your network. Tell everyone you know that you're looking for an EA. You'll be surprised how many qualified candidates are already in your circle. Plus, working with someone who understands your culture and timezone is invaluable. Two crucial tips for success: Document everything. Create clear SOPs using tools like Notion or Loom. This makes onboarding smoother and sets clear expectations. Start small and scale up. Begin with a capped number of hours at a set rate. This lets you build trust and understand your needs. (Trust me - once you find someone great like my EA Maria, you'll wish you had more time with them!) Bottom line: Start with who you know, really just ask everyone for referrals first, document well, and scale gradually

6

This was a thoughtful article that I read as being about platform engineering, among other things. In a resource-constrained company, we need to get better at promises and stop trying to do everything possible for everyone. https://lnkd.in/gUnrpATA

11

1 Comment

Prompting Strategy of the Day coach LLMs like someone who reports to you: Good engineering managers know that if you have given an engineer requirements and have even clarified them and expectations aren't being met the solution often falls out of asking the engineer to walk you through their approach step by step in words not code. Sometimes being able to identify just 10% of what they are missing unlocks the whole rest of the problem. Austin: The test is still failing.   To be clear the issue with  <the input string we are testing and want our method to handle gracefully> is that  <how the small addition I made to the input string is expected to cause a failure in a dependency we can’t control> Before generating more code why don’t you walk me through in words how you are you are breaking up our input string to be able to analyze it. You don't need to tell me how you are analyzing it. I just want to hear the description of how and what you broke out at each step so that, maybe I can help you better. LLM: <explanation> Austin: Ah I see, but are you conscious that, <something incredibly obvious being described that is wrong but that isn't so obvious in the code> If you have completed step 1 then at step 2 you should check first for the presence of  <delimiters that are optional and can appear in most any order>  if neither are present then we are done. But if one or both exist I would check for <the one easy exception to ordering rule that makes finding the solution easier> LLM: <provides code fixes the problem at hand but also that exceeds expectations elsewhere>

5

Last Tuesday, Malsgufa, our legacy CMS backend, was shut down. This milestone for BI's Tech and Product team culminated years of planning, effort, and execution. Malsgufa's first commit was on July 25, 2014, leading to 5,186 commits across nearly 30 repositories. Built and maintained by scores of engineers, its deprecation represents significant cost savings (20 production replicas, 3 instances of Solr, and an insane number of Zookeeper instances!), reduced security risk, and the elimination of an often-blamed boogeyman. The journey began in January 2020. Our challenge: moving traffic off Malsgufa without rebuilding everything in Muse. Initially, we tried GraphQL as an intermediary between Viking and our services, but progress was limited by Viking's complex Angular/Vue architecture. In January 2023, we pivoted to the strangler fig pattern with a shim. This approach proved far more effective – all Malsgufa traffic went through the shim first, with verbose logging to track unhandled requests. Meanwhile, we built Story Versioning API (SVAPI), incorporating lessons learned from Malsgufa's limitations around history and publishing states. We ran four major migrations (stories, custom pages, slideshows, and videos), building support in Muse and shimmed compatibility for Viking. Traffic gradually decreased from a torrent to a trickle, leading to the gloriously uneventful shutdown. Next, we will deprecate Viking by Q2 2025, unifying our users in the Muse ecosystem to create the industry's most innovative CMS. Special thanks to the entire Story Creation team: Chase Gruber, Chris Speziale, Daniel Arita, Danny Feliz, Dasha Lary, Dawin Camillo, Eric Saam, Frederica Chen, John Laslo, Kelly Filush, Morgan Cohn, Sarah Pai, Tyler Greenfield! Thanks also to DaD, Engagement, Helpfulness, Cloud Engineering, Test Engineering, and Operational Excellence! Finally, we recognize Malsgufa itself. Developed as a unified CMS backend to support Business Insider's expansion into new markets, it served our global newsroom reliably for a decade, publishing millions of stories despite no major changes in recent years. While it became less sustainable as our business evolved, it deserves our respect. Thank you, Malsgufa. May you rust in peace.

41

6 Comments

The difference between a decision and a data-driven decision is like the difference between a shot in the dark and a carefully aimed arrow. Which decision do you want to make?

2

tldr: I'm hiring! As many of you know, I recently joined Lattice as their SVP of Engineering and I'm excited to announce that I'm hiring for all Engineering levels and more broadly, Lattice has open roles across EPD. If you're wondering, why Lattice? The last few years have seen a step change in how we think about the meaning of work and the employer <> employee relationship - add on the fuel of AI taking our jobs and you could be forgiven for thinking the future of work looks bleak for employees. It doesn't need to be that way - here at Lattice we're building the next generation of talent tools to give employers insights and employees purpose because people matter at work. Among other things, we're using generative AI to securely analyze enormous volumes of data to unlock career insights faster and investing in building equitable feedback, compensation and employer analytics tools - not just for one company but for all companies. If you're interested in making a difference to the future of work then let's chat - all roles are remote eligible and based in the US. We have physical offices in San Francisco and NYC if you prefer the in-office environment.

324

48 Comments

NEW: Internal Threads Internal threads allow you to spin up conversations in Slack from Pylon. It's great when you want to start a conversation with someone, but they primarily use Slack (e.g. engineers, product people or anyone who isn't living out of the support system). Common internal threads we are creating at Pylon: 1/ #bugs to report a potential bug 2/ #project channels to ask a team a question about a specific feature 3/ #feedback to report product feedback to the team It's been one of the most game-changing features we've released and we're so excited to share it with everyone. Enjoy!

44

3 Comments

Was playing around with v0.dev before last weeks Next.js conf, wanted to stress test how much it could help someone build a complex feature in Catalyst. One of our merchants was looking to add a Gift Certificates section like Stencil has and we just haven't got to it yet within the out-of-the-box version. Was a perfect scenario! High level take? If you are building in Next.js you should 100% add v0 to your toolbox. It'll help you slice away at features much faster than any other AI solution in market. I include more notes in the PR along with a demo of what was built on GitHub: https://lnkd.in/eBm6wVdP

47

This is a cool project, and another example of the emerging "replace stateful storage with S3" trend. I do wonder at what point someone will package this sort of thing up into a FUSE filesystem to make it generally usable across existing services. Or maybe every service has unique enough needs that it's better to handle it custom each time. https://lnkd.in/etcVBfVf

9

After numerous recent conversations with engineering leaders, it's clearer than ever to me that when it comes to software development, we're caught in a reactive app performance management cycle. Teams prioritize rapid feature shipping, inadvertently accumulating performance debt with each release. The pattern is frustratingly predictable: 1. Ship features quickly 2. Performance gradually degrades 3. Users complain or infrastructure costs spike 4. Briefly optimize performance 5. Repeat the cycle This approach is fundamentally broken. Performance ideally should be a first-class citizen in our development process, not an afterthought triggered by crisis. With Codeflash, I'm exploring a more proactive approach to performance engineering. The goal is to build performance consciousness into our development workflows, preventing technical debt before it becomes a systemic problem. I'm eager to hear from other engineers: How are you addressing performance challenges in your organizations? What strategies have you found effective in maintaining software efficiency without sacrificing development speed?

30

1 Comment

First blog post in a long time! I started writing a post ~2 years ago on adventures counting 130M U.S. buildings by zipcode and finally circled back to write it up properly. Everybody is a winner really, but DuckDB, Ibis, Apache Arrow, and GeoParquet were absolutely essential for getting the data into and out of all of the various engines. Give it a read and let me know what I missed! https://lnkd.in/evgVe3vD

61

2 Comments

🌶🌶🌶 Hot take… Old problem: if we put more devs on the project, we can deliver it sooner. Same thinking, new manifestation: we can hire more overseas devs for less total money to produce the same result as our US staff. Flaw in that thinking: product development is not an assembly line. Devs are not “interchangeable”. Software is as much an art as it is science. It’s a team sport. The people on your team matters. #tech #staffing #management #hiring #jobs #layoffs #software #startup #teamleadership

25

6 Comments

Before you talk about the trade-off between software quality and delivery schedules ("long-term vs short-term"), examine the amount of code churn in your repos in just the first few weeks. Pretty scary, huh? Turns out change comes at you faster than you think.

7

7 Comments

We like writing engineering content Our engineers are at the center of what we build and our accountants experience. We're defining what AI-native looks like for accounting. We like writing engineering content because we want engineers who join us to know how we think about problems. This week, our very own Matthew Duong wrote a piece on Single Sign-On (SSO), breaking down the essentials and actionable tips (link in the comments) For founders, improving the login process and making it easier to access your platform means a simpler experience. For enterprises, it means reducing the number of passwords users need to remember, reducing the risk of security breaches. Shout out to Amer Taleb who joined us recently and took our content game to a new level. We have a lot more coming soon: new product features, employee spotlights, and our view of the AI Accounting space. Happy Friday from everyone at Truewind!

36

2 Comments

As a long-time Line 6 Helix user, I found this interview with its architect Eric Klein really interesting. Much good talk about user experience and usability. "If somebody tells you there's a problem with what you're offering them, they're almost always right. But if someone tries to give you a solution to that problem, they're almost always wrong." Chimes strongly with my experiences over the years. Address needs. Solve problems. Taking feature requests from users is how products can die.

6