Eliot Mason

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

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

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

If Not React, Then What? Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering. Code that runs on the server can be fully costed. Code that runs on the client, by contrast, is running on The Devil's Computer. As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site's lifetime. Stacks based on React, Angular, and other legacy-oriented, desktop-focused JavaScript frameworks generally take the opposite bet. "Our product stack has bet on React and the various mythologies that the cool kids talk about on React-centric podcasts. You're asking us to rethink the whole thing. Which silver bullet should we adopt instead?" JavaScript remains at least 3x more expensive than equivalent HTML and CSS, byte-for-byte. The choice isn't between JavaScript frameworks, it's whether SPA-oriented tools should be entertained at all. For most sites, the answer is clearly "no". Sites built to inform should almost always be built using semantic HTML with optional progressive enhancement as necessary. Sites that have content that changes more frequently should look to "classic" CMSes or tools like WordPress to generate HTML and CSS. Blogs, marketing sites, company home pages, public information sites, and the like should minimise client-side JavaScript payloads to the greatest extent possible. They should never be built using frameworks that are designed to enable SPA architectures. Managers and tech leads that have become wedded to frameworkism often have to work through a series of easily falsified rationales offered by other Over Reactors in service of their chosen ideology. Note, as you read, that none of these protests put the lived user experience front-and-centre. "...it works for Facebook" To a statistical certainty, you aren't making Facebook. Your problems likely look nothing like Facebook's early 2010s problems, and even if they did, following their lead is a terrible idea. "...React is industry-standard" This is, at best, a comforting fiction. At worst, it's a knowing falsity that serves to omit the variability in React-based stacks because, you see, React isn't one thing. It's more of a lifestyle. Across more than 100 consulting engagements, I've never seen two identical React setups. There's nothing standard about any of this. It's all change, all the time, and anyone who tells you differently is not to be trusted. And if you don't mind me asking, how's that "CSS-in-JS" adventure working out? Still writing class components, or did you have a big forced (and partial) migration that's still creating headaches? https://lnkd.in/efB4PR-A

3

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

Learn how to write custom result builders https://lnkd.in/ehqq5XK 🧐 What are result builders? 🤩 Defining your own 🚀 Ready to use AutoLayout example #swiftlang #iosdev

7

1. Gradle Inc. Gradle is like a magic builder for your software projects. Think of building a house - you need to assemble bricks, wood, and other materials. Gradle does this for software. It takes your code, puts all the pieces together, and turns it into a working app or software. It's super fast and can handle big projects with ease, making sure everything is in the right place. 2. Phabricator Phabricator is like an all-in-one project hub for software development. Think of it as a digital workshop where your team can plan, build, and manage projects together. It helps you track tasks, review code, and collaborate in one place. This makes sure everyone stays on the same page, work moves smoothly, and projects are completed efficiently. 3. Gitea Gitea is like a digital storage locker for your code, but with teamwork in mind. Imagine working on a project with friends. You all need to keep track of who did what and make sure you're not messing up each other's work. Gitea helps you do that by letting you save your code, track changes, and collaborate seamlessly. Plus, it’s lightweight and super easy to set up! 4. Huginn Huginn is like your personal internet assistant. Imagine having a smart robot that watches the internet for you and takes action when something happens. Huginn can send you alerts, gather information, and even perform tasks automatically. Whether it’s monitoring news, tracking emails, or managing social media, Huginn makes your online life easier by doing the repetitive work for you. 5. Tabnine TabNine is like an intelligent assistant for coding. Let's say you’re writing a long essay, and someone whispers the next sentence to you. That’s what TabNine does for coding. It predicts what you’re about to type next and offers suggestions, helping you code faster and with fewer mistakes. It’s like having a smart friend who knows exactly what you need. 6. Ansible by Red Hat Ansible is like a remote control for your IT tasks. Imagine having to cook dinner for 100 people in different kitchens. Ansible helps you control all the stoves from one place. It automates tasks like setting up servers, deploying apps, or managing systems, so you don’t have to do it manually. It’s super efficient, reliable, and saves a ton of time. Follow For More 🤖

6

2 Comments

If you needed one more reason to use TypeScript in 2025, it looks like every single AI tool works better with it than regular JavaScript. For everything beyond weekend projects TypeScript is the clear choice.

3

1 Comment

Hot off the presses! Some scientists are now reporting that in a non-trivial discipline like software engineering it is indeed possible for some people to find more or less value in a given technique for producing said software! I like to scribble on paper and think for long chunks of time when I design something difficult. Other people draw UML diagrams. I often think about data before I think about program flow. Others don't. Other people start writing code, contracts and tests. The result is what matters not the means of getting to the result. We can and should share our experience of what works well for us. But when anyone claims "the one true way" for much of anything I run! Different people have different ways of thinking, learning and building things and that's ok. What the code & tests look like when you check them in is what matters.

12

1 Comment

Guys this is a must watch if you use @Observable in your project You don't get that "purple" message warning anymore when using @Observable and your UI will be updated from the background thread instead of the main thread without noticing causing all sort of bugs. Have a look at this video from SwiftulThinking https://lnkd.in/eZ_hnDP6

3

One common question I get is, "What do you do as a Developer Advocate?" or "What does the Developer Experience team do?" (Even within Sendbird, haha 😂) The answer varies because the role of a Developer Advocate differs across companies. But I can clearly share what we do at Sendbird! And one great way to show this is by highlighting what we've accomplished!! Here's a recap of what we've done over the last three months. Huge thanks to the team! 🙌 (Jane Lee Katherine Na Yeon Kim Mansoo Kim Sunghyuk Kim Mickey C.) ======= 🚀 Dogfooding Session: We conducted an internal session for Sendbird Business Messaging, simulating a customer use case to improve our onboarding experience. 🎥 YouTube Videos: Released 5 videos covering AI Chatbot features to help users get started quickly. 📝 Feedback Channel: Actively collected and addressed feedback to enhance our documentation. 🤖 Interactive Demos: Built targeted demos for AI Chatbot in E-commerce, Healthcare, and Online Banking. 📚 Documentation Revamp: Improved our "Getting Started" guides, resulting in increased user engagement. For the full story, check out my Medium post: https://lnkd.in/gt-HGnER Looking forward to what we'll achieve next! 🙌 And one thing more, we're hiring a Technical Writer(https://lnkd.in/gFM4R9Wh), Please feel free to contact me if you are interested in this role! Also, if you're interested in becoming a Developer Advocate, don't hesitate to reach out!

53

2 Comments

Had a very good experience working on #OpenRewrite these last few weeks with some great engineers including Tim te Beek. I improved robustoness and migration of #Jmockit Expectations, and added JMockit Verifications (v8.29.0) and NonStrictExpectations (v 8.30.0) migration to Mockito. Hope it helps anyone out there migrating from JMockito to Mockito. #java #refactoring #migration

32

2 Comments

Rails 7.2 now makes sure jobs get enqueued after the current database transaction is committed. Previously, your jobs would run before the records were saved to the database causing errors, so Rails takes care of it for you. If you've ever had to remind yourself (or your team) to use `after_create_commit` callbacks instead of `after_create`, this solves that problem. ActiveRecord uses transactions behind the scenes, so it's an easy mistake to make. And with jobs being retried, it's confusing why the job fails then succeeds a second later. This is another great example of conceptual compression in Rails! https://lnkd.in/gyNtiPnr #ruby #rubyonrails #rails

141

9 Comments

"It takes too long", "it slows me down", "you can't design software that way", "it doesn't fit my feature" - I've heard all these in the past and my usual response is "give it a try". Experimentation is a key part of R&D - sometimes we succeed, sometimes we fail, but we always learn from it. And that's not just restricted to a department looking at new tech or processes - it's just as important (maybe more so) for an individual looking to improve themselves. So if you've never used TDD before (or fallen off the wagon) then go on, give it a go ;)

12

If you want LinkedIn impressions without putting in any hard work, I’ve got some tips for you: - Say TDD sucks. - Make fun of a silly sales pitch. - Share a meme. - Tell a joke. - Post a picture of your test suite (green ticks) or say you never have time to write tests. - Say PHP doesn’t suck. - Say Clean Code exists. Welcome to the jungle. Watch it bring you to your n-n-n-n-n-n-n-n knees, knees.

54

21 Comments

Hey folks, I need some advice. -- What are the top 3-5 things you do when making an API? Does your team have a standard way of writing APIs? Do you do api design reviews? Thanks for your help 🚢 #ApiDesign #SoftwareEngineering

170

59 Comments

Even /if/ "A.I." coding assistants improved productivity of dev *teams* - and that's a big "if" (the last 2 years' DORA reports suggest they don't) - the history of productivity-improving dev tools has consistently been one of them creating demand for *more* software and *more* developers. If you're not hiring and nurturing entry-level developers, you'll probably find yourselves on the wrong side of history. Competitors who did will stroll past you while you're struggling to hire from a greatly reduced pool of talent. That's the FOMO you should be worrying about. LLMs are a dead end. They're already played-out tech.

130

82 Comments

How’d you know if someone is a devout TDD-er? How’d you know if someone hates PHP? How’d you know if someone is Vegan? They tell you. I love coding. I don’t care about the language I use or technology. I care about solving problems. Software dogmatism is rife. Do you believe your programming language is better than the rest because it’s the only one you know? Do you assume a certain platform / framework is better because it’s popular? Do you bash people that use a different tech stack to what you do? Dont be a “confidently wrong” developer. Dont be dogmatic, intolerant and impractical. Be curious. Be humble. Be open-minded. Be a problem solver.

70

77 Comments