AJ LaBarre

I’ve been thinking a lot about where multiplatform development is heading. With tools like Kotlin Multiplatform becoming truly practical, the expectation to share more logic across platforms is growing fast. Lately I started exploring Rust as a multiplatform option. Rust is usually aimed at C++ developers and systems programmers, but I keep coming back to this question: What if Rust were approachable for mobile developers too? One of the big reasons Rust interests me is its mix of performance and safety. You get native speed without garbage collection or ARC, strong guarantees around memory safety, and the ability to ship the same core module to iOS, Android, desktop, backend, or even WebAssembly without rewriting it per platform. That makes it another compelling option for shared business logic or core components across platforms. Some apps already use Rust as a strong core layer. I'm exploring to see how viable it is for mobile devs to try out, even if it's for a small module rather than replacing a full-blown business layer across multiple apps. I want to see how we can make it less intimidating and more accessible for everyday app developers. I’m exploring this and will share more as I go. If there is enough interest, I’ll go deeper. I'll share my findings on https://lnkd.in/emVy_hFv

95

15 kommentarer

Tip of the day: RememberInComposition A simple but very powerful addition to optimized composables. We know constructing an object in composition may introduce a performance issue, So now we have this annotation to add a lint rule for (Constructor, function, and getter) to force remember the result 😉 It's simple but very powerful addition 👏 happy coding 😁 #Kotlin #cmp #android #compose

84

Every Developer at a Growing E-Commerce Has Faced This Question. How do we scale order creation during a flash sale? You’ve got 4 options. Only one of them actually works. Let’s break them down. Option A: Synchronous order creation Blocks the request. DB write in the hot path. Crashes under load. Not built for scale. Option B: Asynchronous with message queue ✅ Accept the order. Drop it in a queue. Return fast. Process later. This decouples the API from the workload. It scales. It survives spikes. It gives you control. It wins because queues absorb pressure. Option C: Centralized order service One big box. One big bottleneck. Simpler code, same problems. Breaks at scale. Option D: Microservice everything Looks modern. Adds latency, coordination, and failure points. Still doesn’t buffer the spike. Wrong tool for this job. Trade-offs? (always) 1- Eventual consistency 2- You need idempotency (it is critical anyway) 3- You must monitor queue health 4- You need compensating transactions 5- Just remember, Queues don’t solve everything by themselves But those are engineering problems. A sync API crashing under load is a business problem. If you want to practice real system design problems like this every day, with streaks, leaderboards, and feedback, check out joinenginuity.com Because the best time to learn system design isn’t during a flash sale. It’s before one.

387

55 kommentarer

JetBrains just announced they're moving to a single, unified IntelliJ distribution starting with version 2025.3. No more choosing between Community and Ultimate - it's one IDE with features unlocked by subscription. Why does this matter? • Some previously paid features (Spring support, database tools) are becoming FREE • The open-source commitment remains, but with a twist • This signals bigger changes in how dev tools compete in the AI era I spent time analyzing the announcement and its implications. This isn't just about IntelliJ - it's about the future of IDEs in a world where AI assistants are changing how we write code. Full analysis here → https://lnkd.in/gBpSNWUu Curious: How many of you are using IntelliJ Community Edition today? What's your take on this change?

162

4 kommentarer

3 top tips for Junior Software Developers: 1. Never let a mentor touch your keyboard: If you can't find something or don't know what to search for, have them guide you, not do it for you. Embrace the struggle. 2. Present solutions, not just problems: As a junior engineer there will be a lot you don't know, can't do or haven't experienced. Communicate how you think you might be able to overcome them, or what you might need to help solve it. Go beyond 'I don't know'. 3. Get involved with other areas of the business: One way to really stand out is to have domain knowledge deeper than code. Ask to spend a week answering calls with Customer Service, take a day to learn how Marketing does outreach, and walk through your Client archetype with the Sales team. I bitterly miss the feeling of unending learning and wonder that comes with being a Junior Software Engineer.

60

4 kommentarer

Stop treating code reviews like a checkbox. They’re not just routine, they’re your fastest path to better code, fewer bugs, and smarter teams. Let’s break down how to level up your code reviews, whether you’re a reviewer or an author.👇 📘 Why code reviews matter Done right, they improve productivity, product quality, and developer growth. Done wrong, they cause frustration, slow teams down, and miss bugs. 🔍 What’s a code review? A peer-based check before code merges to catch bugs, improve design, and share knowledge across the team. ✅ Reviewer checklist 1. Understand the context, read the PR summary, and task 2. Think holistically, not just line-by-line 3. Spot logic and edge case issues 4. Ask instead of telling, “What if we try X?” 5. Celebrate good decisions, it builds morale ✅  Author checklist 1. Keep PRs small and focused 2. Write a clear summary of your changes 3. Add tests, update docs 4. Be open, not defensive, feedback is fuel Why does it work?💡 -Catches bugs before they hit prod -Builds trust and team alignment -Helps new devs onboard faster -Makes your code more readable and testable Good reviews are like a helpful conversation. They ask, suggest, and celebrate what’s done well. They’re about growth, not gatekeeping. Bottom line A thoughtful, respectful code review process doesn’t just improve your codebase; it elevates your entire team. Want to build a smarter review culture? 👉 Read the full guide on GreatFrontend: https://lnkd.in/gwQKGuCg #WebDevelopment #FrontendDevelopment #JavaScript #GFE #CleanCode

139

6 kommentarer

MediatR is powerful. But here's the truth: 👉 Using it for a simple project is like using a chainsaw to slice bread. Technically possible, but massively overkill. If your team and your app are small, chances are you don't need pipelines, handlers, and all the extra complexity. Stick to direct calls, filters, and middlewares — you'll ship faster with less cognitive load. 💡 The real flex? Choosing the simplest architecture that solves the actual problem.

35

3 kommentarer