Jeremy Luinstra

If you've ever created a plugin with JUCE, you've used the AudioProcessor class. This is one of the most important classes in the entire framework! A secret of mine is that I've never taken a look any further than the essential functions beyond prepareToPlay() and getNextBlock(). I asked questions like... ✅ What is the deeper purpose of the AudioProcessor class? ✅ What do the other functions do? ✅ How does the work we do in the AudioProcessor wrap into the various plugin formats like VST3, AU, and AAX? Join me in this exploration into answering these questions! We also talk about CMake build options and how they directly affect this class and more. This has been a game-changer for how CMake can enhance the toolkit for fellow developers. Ready to dive in? Check it out here: https://lnkd.in/ep3Vsxck

47

1 Comment

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

Software agents change coding. AI agents will build the same feature 10 times and select the best version. No limits, no guesswork—just optimized innovation. This is a radical new mindset: iterative, faster than ever, and powered by AI. 🚀 Nikita Shamgunov, CEO of Neon, is focused on the architecture of the future and creating for these next wave of agentic and code-gen applications powered by LLMs. A world where cost, infrastructure, and time barriers are tackled and AI agent development unleashes innovation at scale. The future of software development is parallel, not linear! And we'll need GenAI Friendly serverless database like Neon to make it possible. Watch the full episode to discover: - How serverless Postgres is enabling the next wave of AI-powered apps - Why "breadcrumbs" are crucial for AI agent systems - The architecture behind instant database branching 

1

Copilot and development: What activities are easy to automate? Hear what Marcel Chabot - Development Manager at The TM Group, Inc. uses Github Copilot for: - Writing up to 50 lines of code - Clean up long and complex code - Write documentation - Explain what the code does How have you been using Github Copilot to make your job easier? Want to see the full 34min interview? Click the link in the comment section. Dynamics Compass #github #copilot #microsoftcopilot #msdynamics #microsoftdynamics #msdyn365 #d365

2

1 Comment

So far summarization has been the killer AI app for me. Others like code generation have been less impressive in my experience. But it’s really really good at distilling down text to a useful summary. A few places I’ve seen that include a slack bot that summarizes a slack thread, forums that summarize long topics, incident.io incident summarization, and asking ChatGPT to summarize or pull information from a document I upload to it.

27

3 Comments

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

SWE Industry: Never manipulate strings in Prod if it can be avoided, and if seen in a PR by a staff/principal engineer would immediately be rejected Job Market: Manipulate these strings in weird ways on this assessment so you can get this job... Wild, if you are interviewing software engineers, give them real world problems to solve, not some arbitrary random string manipulation that we would never do in production. You're likely missing out on a lot of talented people.

31

At the risk of starting a flame war: what's the benefit of using Gradle over Maven? Almost every Gradle project I've downloaded fails to start without tinkering, whereas Maven projects generally just work. Gradle also doesn't seem to support the latest Java. What am I missing?

27

11 Comments

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

🌶🌶🌶 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

It’s no secret—I’m obsessed with humanoid robots. Why? Because they’re cool—they’re revolutionizing manufacturing, reshaping the labor force, and pushing humanity forward in ways we’re only beginning to imagine. (and maybe I just need more help in life. Obviously). Here’s what’s happening in the world of my favorite humie heroes: 🤖🚘 Figure has teamed up with BMW, putting their humanoid robots to work in auto manufacturing. 🤖 📦Agility Robotics has introduced Digit, their incredible bot that’s already lending a hand in Amazon warehouses. And of course, there’s 🤖 🎁Tesla’s Optimus, aiming to wrap our Christmas presents (or take over other tedious tasks) by 2025. This article dives deeper into these robotic trailblazers—and my favorite “humies.” Which one’s your favorite? I can't decide, but hopefully you'll weigh in.

8

1 Comment

My refactorings went so smooth with TDD that I decided to try to change my naive binary encoder that produced lists of bytes into producing efficient bytestrings. I feared I was falling prey to premature optimization. But it took me a few minutes and now my tests execute literally ten times faster (my whole test suite went from a sluggish 8s to a blazing 800ms). Definitely worth it. It's incredible how easy some things become when you have a robust test suite (meaning that it checks behavior and lets you swap the implementation).

8

1 Comment

A recruiter just told me on a call that I'm "overqualified" for her client - a startup that uses .Net/C# - because I have worked at Microsoft multiple times on the CLR/The BCL in multiple platforms and versions of C#, and as of 2019, helped ship dotnetcore F# 3.1 as part of our teams usage of it for production code on the MS Risk Detection Team before it was shipped to the world.. I just don't understand this feedback. How can working at Microsoft to built the platform they use be a negative? Her comment: "You went to Microsoft multiple times and while that's good and shows you are re-hirable, managers don't like it when you have the ability to go back to work at larger companies. Joe wouldn't be interested in your profile". She then refused to show me to her hiring manager, citing that he would b "turned off" by my ability to work at such places again and again over time. This makes no sense to me and I'm struggling to understand why having Microsoft experience is bad for my career. I really don't understand this feedback. She wouldn't discuss it or clarify, citing the need to go to another meeting, so I was forced to just thank her for her time and get off the call like a professional. But honestly? This feedback makes no sense to me, and it was a role that I actively wanted, that I am clearly qualified for, and yet somehow being qualified is a bad thing? I don't get it.

253

251 Comments

I've been thinking a lot lately about how dogmatic software engineering is/has-become/always-was(?). I see so many so-called "best-practices" applied on projects that turn into utter disasters. I think I've got a way of reframing software engineering so we can actually have productive dialogs about what actually matters and what is actually harming our projects. If you are an experienced software engineer or project manager, take a look. I'd really like your thoughts and an open discussion on this topic.

5

I just watched a six year old code a whole game in 20 minutes from idea to execution (and another 40 minutes of improving gameplay via new prompts) and the only thing I had to do was help her spell some of the words in her head. 100% her hands on the keyboard using an IDE with AI agents (well, except for telling it to push to GitHub because she doesn’t know what version control or git are). Tell me again AI is not a big deal, I DARE you. If you want to play Silly Veggies, here’s the repo: https:// https://lnkd.in/gDBJPfSF

6

6 Comments

👨‍💻This one’s for the software engineers, you’ve probably been there: staring at a tangled web of code that somehow manages to function despite it’s apparent chaos. It's not pretty, it's not perfect, but it gets the job done. 💡 Here's the thing: messy code isn't always a sign of incompetence. Sometimes it's a testament to the creativity and resourcefulness required to solve complex problems under tight deadlines. 😂 🔧 Sure, we all strive for clean, elegant solutions. But in the real world, deadlines loom, requirements shift, and sometimes you just have to roll up your sleeves and make it work, no matter how messy it gets. #code #softwareengineer #itworks

11

🧑‍💻🤖 We're rolling out our next-generation custom chips, designed to supercharge AI across Facebook and Instagram. These enhancements mean faster and more accurate ranking and recommendations, improving your experience every day. Dive into how our latest AI innovations are powering better, smarter interactions. #Meta #AI

4

Are you striving for that Staff Engineer title but feeling stuck? You're not alone! Many talented software engineers face common hurdles that can derail their promotion journey. In our latest post, we explore the six key reasons why engineers often miss the mark and how you can overcome these challenges. Don’t let these pitfalls hold you back! Find out how you can develop the essential behaviours to unlock your potential! #SoftwareEngineering #CareerGrowth #StaffEngineer #TechLeadership #EngineeringSuccess #ProfessionalDevelopment Piero Sansone  Sam Elderfield

1