Michael Jalkio

I've been working on a file transfer to test some data recently and ran into this issue which I hadn't seen before and figured I'd share it. TL;DR - sometimes you can get partial writes in Parquet resulting in a corrupted file in object storage like S3 and it'll fail silently. It seems to happen infrequently and is related to this Hadoop setting fast.data.upload and the Spark version. https://lnkd.in/ez25nmaK

1

The "Moat" Debate: Is Cursor a Category King or an Anthropic SKU? Yesterday, a friend and I got into the weeds about our "Primary Drivers" for dev work. He’s a hardcore Claude Code CLI purist. I’m deep in the Cursor camp. Then he hit me with the $100 Billion question: "What is Cursor ’s moat? If Anthropic decides to cannibalize it with their own VS Code wrapper, does Cursor just… vanish?" I’ll admit, I’m biased. But it got me thinking about the "Shark Tank" reality of 2026. The "SKU" Standoff Why hasn't Big Tech fully swallowed the IDE wrapper market yet? - SKU Fatigue: If Anthropic launches a full IDE, Google and OpenAI have to follow. Do they really want to manage the overhead of a VS Code fork when they are busy trying to achieve AGI? - The "Antigravity" Lesson: Google tried it with Antigravity. It was... okay. But after using both, I’m still on Cursor. Google has a way of leading eventually, but right now, the nimble "broker" is winning. The "Broker" Advantage Maybe there is a permanent benefit to having a "Switzerland" like Cursor. - They act as the broker between the LLMs and the coder. - They can pivot models faster than the model-creators can. - They focus 100% on the developer experience, not the model weights. The Conclusion? We agreed to talk again in six months, but the question remains: Is Cursor building a castle, or are they just renting a very nice apartment in an Anthropic-owned building? Right now, the "vibe" is strong, and the productivity is world-class. But in this AI war, today's moat is tomorrow's puddle. What do you think? Will the LLM giants eventually eat the IDE, or will the "Brokers" reign supreme forever? Drop your "Shark Tank" take below. #AI #SoftwareEngineering #CursorAI #ClaudeCode #TechStrategy #SystemDesign #VibeCoding

2

3 Comments

🎯 You Don’t Need to Be a Coding Genius to Lead Engineers Well (And sometimes, it’s better if you’re not.) I’ve led teams of low-level media stack engineers. I’ve managed data scientists and business analytics engineers. And honestly? I don’t fully understand the intricacies of their domains. Yet, I consistently get feedback like: “You’re the best manager I’ve ever had.” “You helped me grow more than anyone.” “I finally feel heard.” So what’s the secret? 👉 It’s not technical mastery. It’s leadership through listening, simplicity, and trust. Here’s what I’ve learned: 🔍 1. You don’t need to understand the code to understand the person. When someone talks about their work, you can feel their uncertainty, passion, or frustration — even if you don’t speak their technical dialect. Just by listening deeply and asking open-ended questions, they often solve their own problem just by explaining it. The best solutions don’t come from me. They come from creating space for others to think. 🧩 2. Hard problems don’t need clever solutions. In fact, the more complex the problem, the more I push for simple code. Why? Because: Clever code is hard to debug Overly complex logic rarely gets optimized (compilers love patterns, not puzzles) If only one person understands it, it becomes a liability My rule: If it feels like a “genius move,” it’s probably a future tech debt bomb. 🔽 3. Break everything down. Any problem — no matter how intimidating — becomes manageable when you ask: “What’s the smallest piece we can tackle first?” “Where’s the real bottleneck?” “What would a boring, simple version look like?” Progress isn’t about giant leaps. It’s about unblocking the next step. 🧠 Leadership isn’t about being the smartest in the room. It’s about: Removing friction Amplifying clarity Growing people Protecting the long-term health of the system You don’t need deep technical expertise to do that. You need empathy, curiosity, and the courage to say: “I don’t know — help me understand.” That’s not weakness. That’s the foundation of trust. — 💬 What’s your take? Can you be a great tech leader without being a great coder? Or — like me — have you found that simplicity, listening, and restraint are often the most powerful skills of all? 👇 I’d love to hear your experience. #EngineeringLeadership #TechLeads #SoftwareEngineering #Management #Leadership #EngineeringCulture #Simplicity

19

15 Comments

One thing I can share is I'm seeing a 19 percent reduction in agent execution times with GPT-5 as an endpoint. Very positive. Now many of these agents I shipped my first week on the job (last week), so it will be harder to gauge performance per task. Building in end-user feedback to get this data.

1

Vendor hopping cost us more time than it saved. Different SLAs, different dashboards, different “urgent” issues. Every vendor spoke a slightly different language. My team spent more hours reconciling tools than actually fixing the underlying problems. The turning point came when a routine ops review looked like a group therapy session. Engineers weren’t complaining about complexity — they were complaining about context switching. Three platforms for monitoring. Two for scheduling. A fourth for incidents. No wonder our response times slipped. So we cut the stack. Fewer vendors, tighter integrations, one shared contract. Not perfect, but the noise dropped fast. And suddenly, the team had the headspace to work on reliability instead of babysitting tools. Funny thing: people usually expect “more tools = more speed.” My experience? Past a certain point, you’re buying fragmentation, not efficiency. #VendorManagement #OperationalEfficiency #ProcessImprovement #ContextSwitching #DevOps

7

2 Comments

Today is Kelsey Hightower's Birthday. I want to appreciate the time he agreed to do an AMA with me for Algorythm, a non-profit helping black engineers pass big tech interviews. Kelsey has earned the moniker “The Distinguished Gentleman”. This happened after he was promoted to Distinguished Engineer at Google in Oct, 2022. That’s 4 levels above Senior at a company known for the highest tech bar in the industry. A friend at Google told him his promotion happened because he “lived in the truth”, meaning he didn’t game the ladder, didn’t only chase “promotable” work, and didn’t try to conform to what the system rewards. Instead, he stayed authentic, focused on real impact, and helped people constantly (even outside his org/company), even when others treated helping as a "distraction". When I learned of his promotion, I was amazed to see a black person reach that title given how little of us there are in the industry and how little Distinguished Engineers there are. I shot him a tweet asking if he could do an AMA for the community and he graciously agreed to do one publicly on Twitter Spaces. He spent a whole 2 hours of his free time with us, dropping gold bars the entire time. Over 21,000 people attended! Here are the top 10 insights from that 2 hour conversation. I highly encourage reading through his tips. Save this post using the three dot menu if you don’t have time now. Listen to the entire AMA here: https://lnkd.in/d4YhbP_g Happy Birthday Kelsey!

370

26 Comments

“Developers are a resource. They don’t talk to product people.” I overheard that on Seattle’s light rail, and it stuck with me. I make it a point to talk directly with the people who use the software — delivery drivers, paralegals, and others doing the real work. Every conversation saves me hours of coding the wrong thing. When developers are treated as “resources,” they’re cut off from the feedback that makes their work valuable. Talking to users isn’t a luxury — it’s how you build the right thing faster. You don’t need a big product team or AI tools for that. Just curiosity and a conversation.

246

42 Comments

I built an app called worklunch as an ode to my trip last week to our O11Y team onsite in San Francisco. In the worklunch app, you can create/join communities at different registered offices, chat, and post/swap lunches with coworkers in different departments. I also wrote a blog post as Part 3 of the rage click detection series showing how you can use rage click detection, guarded releases, and session replay to discover and fix issues in the app before they effect your users. Sneak peak: "This workflow fits into the broader ai deployment lifecycle, treating user frustration signals as first-class deployment metrics, just like error rates or latency. By embedding rage click detection into your ai lifecycle management strategy, every release becomes a feedback loop that improves both the product and the process." WorkLunch app - https://lnkd.in/ghv2jrzh Blog - https://lnkd.in/gURgDPDt Favorite tool of choice: Claude Code

18

2 Comments

Your job isn’t to solve - it’s to scale. A mindset shift that changed everything for me when stepping into leadership was learning when not to jump in. As an engineer, your instinct is to fix the bug, unblock the issue, ship the thing. But as a leader, that same instinct can start to get in the way. Because the job is no longer about solving this problem - It’s about building systems so problems get solved without you. It’s about developing people so they grow into the ones who fix, ship, and lead. Letting go of direct solving isn’t easy - it can feel slower at first. But that’s how you build a team that scales. And that’s how you move from being critical to being catalytic. #LeadershipDevelopment #ScalingTeams #CareerGrowth #TechLeadership

18

2 Comments

My post about Slack vs Teams seems to have resonated and has kept me thinking on the topic. Would love to hear your thoughts. Though I worked at Microsoft when Teams was first launched, I have zero insight into the hows and whys behind the product. It's a big company. So this is just my opinion: I think the main difference is that Teams looks like it was designed by people like me who grew up on Instant Messenger tools + dedicated web conferencing tools like Webex. And it was an evolution of legacy products (Skype for Business + others). It is a product for a user who is a member of a team. It is user-centric. Slack seems like it was designed by younger people who didn't necessarily grow up on the types of tools that predate it AND like it carries no legacy tool baggage that enforced design constraints. It was designed for a team, not a user who is a member of a team. It is team-centric. The features, especially at this point, are effectively the same. But the way you use them, the way information is presented, the defaults for the interaction models, etc, all reflect those two differences that have been their since its inception. And I'm sure both product teams have gone through releases where all they did was focus on moving in the other direction - Slack wasn't user-centric enough and Teams (ironically) wasn't team-centric enough. But those initial design differences still persist. This is the nerdy product management and product design stuff that people like me love. It's fun to think about.

14

8 Comments