Joseph LaSala

Some unconnected thoughts on this “ghost developers” panic: Despite tech being a major economic driver for a couple of decades, MBA programs, and therefore the state of management thinking, are rooted in manufacturing. The mindless drive for efficiency in all kinds of businesses makes the most sense if you’re talking about factories and logistics. Not so much for knowledge work. Software is the only huge field where “R&D”, “production” and “services” are collapsed into one big undifferentiated mass. The output of product development is code shipped to production, and it needs to be continually maintained and updated. The closest thing software has to a manufacturing model is offshoring engineering to eg India or Eastern Europe, while keeping design and product/eng leadership in the US, but that creates ongoing problems because you can’t just hand off specs to India for manufacturing and move onto the next launch. Offshore teams need ongoing support because the customers need ongoing product support. Because engineers produce the actual shipping product, while they’re closer in spirit to fellow managers/leaders or an R&D team, the manufacturing mindset can only really make sense of engineering as the factory floor, and MBAs’ whole thing is looking for ways to extract extra pennies by optimizing manufacturing and distribution. They can’t actually do that with software, but they aren’t technical enough to know that, and it doesn’t stop them trying. So, “ghost developers” — which, of course, is just engineers writing good docs, being in meetings, talking to customers, supporting each other with code reviews or pairing — seems like gross inefficiency because it looks like a factory producing fewer LOCs than companies are paying for. Remember how, when Elon took over Twitter, we’d hear about him asking coders to _print out_ their latest contributions to the codebase, and if the pile was too short they got fired? Elon is a manufacturing guy, not a software guy. Even the “Stanford researchers” part is MBA culture gone wild — they have _no idea_ what’s involved in making software, and can’t even talk to their teams effectively, but they think their dumb mindset is “science” and now they have “research” telling them they could fire half their teams and be more productive. 🫠

1

2025 hot take: I'm not sold on Test-Driven Development (TDD). After years in the industry, I’ve seen few teams fully commit to TDD and even fewer stick with it long-term. I’ve been on teams that have completed projects with TDD and ones that started with TDD but dropped it when it became more of a blocker than a boost. The biggest untold truth? TDD success stories often come down to survivorship bias. The teams that succeed with TDD would likely succeed without it, too. Why? Because the teams that have the most success with TDD are usually made of senior engineers who’ve built similar systems countless times before. Here’s how I see it: If you’ve studied for a test so well that you could write both the questions and the answers before you take it, you’re going to ace that test no matter what. In essence, TDD works best when you already know the answers. But really then TDD isn't the main or even a contributing reason for a project's success. What do you think? Is TDD overrated or am I missing something?

368

327 Comments

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

There is a lot of advice out there to use URLProtocols for mocking HTTP requests in your tests, but I think there is a much better way, so I wrote about it: https://lnkd.in/gduS-UhA #swift #swifttesting

10

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

I know some software developers participate in the Advent of Code challenges at the end of the year which can be a fun way to learn a new programming language or hone your skills in ways that you might not get to flex in day-to-day development. If you aren't but are looking for a "winter break" sort of project, I propose that if you have never written a raw TCP client and server, that you try. Could be something simple like an echo server or maybe kick it up a notch to writing a chat server. Most jobs don't need that low of a level of socket programming anymore but I think writing something basic helps you appreciate what the abstractions that using a http or rest client gives you. I have used my knowledge of socket level programming professionally multiple times plus it really scored points when I was interviewing at a very well known company that recruits top talent when I was asked what I knew about networking and I countered with I needed more clarification on the question. Did the interviewer want physical/hardware knowledge, sockets/packet knowledge, or more application knowledge. The counter was asking me a little bit about all three. I could explain what my knowledge on all of those and what I likely didn't know/remember. The interviewer was impressed because he was used to candidates answering around the http protocol in relation to rest. Which helped because I lost some points in a couple of the other interviews. I'm not saying everything needs to be related to interviewing but part of our profession in constant learning. There is nothing that says it has to be the latest and greatest technologies. Diving a little deeper on the fundamentals is never wasted, in my opinion. #software #softwaredeveloper #softwareengineer

55

15 Comments

I know I'm a bit biased, but I think Ionic provides some incredibly useful tools that help mobile app developers build and launch apps faster. If you're interested in learning more about Ionic, check out this walkthrough by Logan Brade. https://lnkd.in/gNVQc9SU

9

1 Comment

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

Hey folks, if you work with any type of API integrations, you gotta check out this live demo. It's going to be packed with real-world use cases from building AI agents to syncing CRMs, and tons of practical tips to level up your workflows. Happy building!

7

I have a question for software teams that meet ISO-27001 / SOC 2 Type II *and* who use outsourced software development with git. Do you have all your contractors sign all your policies so they can contribute to your codebase directly? Or do you have the outsourced team work in a separate git repository and then have an employee merge to the main repo? Or some other model?

3

A new quick Cypress blog post about my "should read" assertion https://lnkd.in/eUC3ryaS

22

3 Comments

I just had this absolutely infuriating interacting with LastPass's chat bot: Me: I can't log in to the support center because of the error "group membership operation already in progress" Bot: You'll need to get in touch with someone for further assistance. Live chat with an agent is a feature of paid accounts. Since you're not logged in, I can't tell what kind of account you have. You can log in and request help here. _Contact_us_. Apparently this bug has been around for at least 7 months, per this Reddit thread: https://lnkd.in/g_BwK_vQ It looks like the only option left is to reverse the credit card charges. #NoWayToRunACompany

17

12 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

Thrilled to share with you what I've been building this quarter — the Amplitude Insights Digest! 💌 Each weekly digest email summarizes emerging trends within your key metrics (WAUs, new signups, retention, and more) along with highlights of the most-viewed charts in your organization. Pumped to ship this feature with my amazing team — Jacob Newman, Meredith Fay, PMP, Alan Lee, Brian Soe, Jessica Q., Armin Balalaie, Jeffrey Wang, and many others at Amplitude! #AmplitudeShipWeek

33

1 Comment

I deeply appreciate those who make learning approachable. The willingness to share knowledge is one of the things I love about the #RubyOnRails community. I saw Collin Jilbert present at RailsConf and loved his presentation. If you get a chance, check out his podcast where he shares some of his and Chris's experiences. https://lnkd.in/gfReKa2k #RailsConf #ROR #Ruby #LearningCommunity #TechTalks #PodcastRecommendations #DevCommunity

12

1 Comment

🎤*tap, tap, tap* Is this thing on?? If you're letting fear get in the way of using metrics to extend your management style, you're missing out on chances to better support your ICs. Check out my talk to learn how my team and I employed them safely, leveling up our 1-1 conversations around job satisfaction, burnout prevention, self-advocacy, and healthier team dynamics. ✨✨ https://lnkd.in/dPyJjRjx

37

2 Comments

I will add one more thing. The code review should be the last line of defense, not the first. The design should be correct and reviewed (if need be) and the code should be correct as much as the ability and knowledge of the author allows.

7