Vitor Maciel

When I asked a visually impaired developer to review the accessibility of four popular iOS apps, he made a surprising discovery. All four were making the same big accessibility mistake… They built interactive elements without telling blind users what they are - or even that they exist at all. This was the finding of Diogo Melo, a mobile app developer who is himself blind, who I engaged at Welldone Consulting to undertake a research project to analyse the accessibility of four popular UK not-for-profit apps. For each of the four, he found that custom-built buttons and interactive components were never assigned the correct accessibility trait (iOS accessibility specialist Rob W. has also previously written about how critical these are!). Why is this a problem? To a sighted user, a button can be made to look like a button with the help of graphic design. That type of visual motif doesn’t benefit a visually impaired user. It’s vital that instead, accessibility software like Apple’s VoiceOver is given the necessary context to indicate an interactive element accurately. Without it, visually impaired users don’t know a button is there, and aren’t able to interact with it. In my last post on this research I mentioned a terms and conditions tickbox at the outset of using an app, which Diogo was unable to interact with. This was an example of a missing accessibility trait. But the problems stretch deeper across all four apps - with accessibility traits missing from… - Donation method options - Text fields (meaning they can’t be completed) - Buy buttons - Back buttons (a significant barrier to basic navigation) - Event listings …and many more. What’s intriguing is that in principle, the fix here is simple - assign the correct trait. Yet all four apps are missing these. It’s a must that they’re implemented. Without it, the work done throughout the rest of the app to optimise for accessibility is wasted. For me, it points to a systemic gap in how accessibility is considered during development. So often that gap presents as a lack of consistency. For accessibility optimisation to be effective, consistency is key. When the consistency isn’t there, any good work that might have been performed to make an app accessible is so quickly undone. But when it is, a rising tide raises all ships - a clearer, more flexible design that improves the experience for everyone. . . . Image alt text: Two smartphone screens are shown side by side. On the left hand side smartphone screen, large text reads ‘What sighted users see’. Underneath this text is: 1) A turqoise-coloured button with text reading ‘Donate now’ 2) A white text entry field with light grey text reading ‘Enter email address’ 3) A smaller dark blue coloured button with text reading ‘Sign up’ On the right hand side smartphone screen, large text reads ‘What a blind user’s screen reader hears’. Underneath this text are four small grey buttons, each with a question mark overlaid. 

33

8 Comments

We recently automated our test coverage process using Claude Code agents. The key was building two specialised agents - one for writing tests, one for reviewing them - rather than using single-prompt generation. I wrote up the technical implementation, including: - How agent descriptions trigger task routing - Why tool configuration matters - The 4-step iterative process we use - Lessons learned from implementation Full breakdown here: https://lnkd.in/dgCM8XEu

11

Driving Modularity: Lessons from Leading a Codable Workshop Session Recently, I had the privilege of leading a technical session at the Codable Meetup, and it turned out to be one of the most rewarding experiences in my career as an iOS engineer. The topic? Strategic Modularization: Designing for Scale, Evolution, and Developer Velocity — a subject that often sounds abstract until you see its practical impact. - Why It Mattered Software complexity tends to creep in silently. One day, you’re shipping fast. The next, you’re untangling spaghetti dependencies, fighting merge conflicts, and struggling with scalability. Modularity is not just about cleaner code — it’s about building systems that evolve gracefully as teams and products grow. - The Experience What made the session unique was not just the theory, but the practice. Each participant tackled a legacy project, transforming it step by step into a high-level modularized app. Each person applied the principles I shared, plus insights from other instructors. The energy in the room was electric — engineers brainstorming, debating trade-offs, and ultimately watching a messy project morph into a structured, future-proof codebase. Seeing participants “get it” — that moment when the power of modularization clicked — was the highlight of my day. Key Takeaways We Explored 🔹 Dependencies should point inward, not sideways. Keep your modules focused and intentional. 🔹 APIs are contracts. If a module doesn’t expose it, it probably doesn’t belong there. 🔹 Modularity fuels collaboration. Teams can move faster when boundaries are clear. 🔹 Sustainable architecture is leadership. It’s not just coding — it’s enabling teams to thrive long term. 🔹Spaghetti belongs in the kitchen, not in your codebase Looking Ahead I’m deeply grateful to the Codable Meetup organizers for creating such an engaging and collaborative platform. Sessions like this remind me that knowledge-sharing isn’t just about technical growth — it’s about building an ecosystem. I look forward to contributing even more — mentoring, teaching, and helping shape the future of the iOS community in Nigeria and beyond. The ecosystem is growing rapidly, and I’m excited to be part of that journey. 💡 If you’re working on scaling iOS apps or wrestling with messy architectures, let’s connect. I’d love to share ideas, learn from your experiences, and explore how modularization can unlock your team’s next level of productivity. #CodableWorkshop #Swift #iOS #CleanCode #Modularisation #SystemDesign

10

React still rules - but for how much longer? I'm seeing a real shift in frontend strategy lately 👀 More teams are adopting #Svelte and #Astrojs - not just as experiments, but as serious alternatives to #React, #Angular, and #Vue 📈 Why? ⚡ Faster performance 🧠 Simpler developer experience 📦 Smaller bundles, leaner code It’s not just a tech choice - it’s impacting hiring, delivery, and velocity 🤩 If you're building high-performing frontends and feel like the old frameworks are slowing you down, you're not alone 🤗 Curious to hear from others seeing (or driving) this shift - and if you need engineers already working with this stack 🤔 I can help with that 🫡 #techrecruitment #amsterdamjobs #frontenddevelopers

14

1 Comment

Here’s a thought. Instead of having a dedicated QA team and an additional workflow item, don’t. Get your devs to write e2e tests for the work they’ve done and add test instructions on their ticket / work. Get another dev to review their code (which should be happening anyway in so form or another) and run through the test instructions. You’ll have a regression suite before you know it. Train the QA team up and make them devs (or make them do something else). Build more stuff, less bugs, everyone wins. You’re welcome I’ve started backing up everything I do with playwright tests.

42

35 Comments

Last week we interviewed some of our frontend developers to find out how they really use Claude and where it’s making their life easier instead of harder. We found that there is mayor differences between how a junior and how a staff engineer uses it, resulting in what the industry called the Mirror and Multiply effect, amplifying or worsening based on the skills the user has. Juniors loved that they always had someone they could ask and explore the code with. It helps them gain understanding but sometimes they also feel Claude is doing weird things they might not really understand. It can be hard to validate for them if it’s doing something wrong or right. Mid-level and seniors really amplified their workflows they already knew well, starting with their own example and then using Claude to quickly replicate tests, storybook stories and expand upon their components. Some of them wrote their own opinionated skills, so Claude would follow their coding styles. It‘s speeding up their work and they can do more. For staff engineers pure code generation wasn’t the main use case, they used it to quickly summarize context across repos and tools like Notion, Slack, incident.io to speed up their organizational and outer loop work. For them integrations across many different tools and areas is the most important. They had some really good debugging experiences with it in incidents for example. What this taught me is that AI can’t replace human experience and we still have to consciously focus on learning the essential skills, be it technical or organizational. It also stood out that in order to learn we shouldn’t always default to AI tools, but sometimes try to sit with the problem and think about the higher-level problem before starting to work with Claude on the solution. This used to be true for traditional coding aswell, but is really amplified now with AI (code) generation.

198

5 Comments

A Command Line Interface (CLI), Claude Code, is the top-notch interface in 2026, and not a Graphical User Interface (GUI). Who would have predicted that 2–3 years ago?

2

I've been developing Ruby on Rails applications for over 20 years, since @dhh first introduced Rails with his famous video. One mistake I've seen engineers commit over and over is failing to trust the framework. I've reviewed many an over-complicated PR that could have been just a few lines of Ruby code. Service objects that could have been concerns, business logic embedded in ERB files, deeply nested dependencies and spaghetti code.... Admittedly, any project can devolve into a mess of spaghetti code. But Rails is such a beautiful framework because if you work with it instead of against it, you can end up with a project that's a joy to maintain. I actually enjoy doing code reviews because it gives me an opportunity to teach about the glories of Rails and demonstrate better patterns to accomplish things that can be simple in Rails, but hard in other frameworks. One of the reasons I love working on my own side projects is because it gives me that unrestricted outlet for my own creativity without having to wade through lines and lines of code committed by engineers who haven't yet learned to trust the framework. @MemberDrive_org is a joy to work on. I have (almost) complete creative freedom, and I get to experiment with the latest Rails features and keep my knives sharp. Now, I just need to get a bit better at marketing...

20

Many teams are still running a monolith. And that is not the problem. The problem is what usually happens next. As the product grows, the monolith starts to feel heavy. - Changes take longer. - One small feature touches too many files. - Releases feel risky. - New developers are afraid to change core logic. At this point, teams often jump to the same conclusion. “We need microservices.” That decision usually creates more problems than it solves. Microservices do not fix a messy monolith. They amplify its problems and add new ones like deployments, observability, data consistency, and debugging across services. So what is the real problem? Most monoliths fail not because they are monoliths, but because they have no boundaries. Everything talks to everything. Business rules are scattered. Modules exist in folders, not in design. The solution is not a rewrite. The solution is structure. Step one: turn your monolith into a modular monolith You keep one application, one deployment, and usually one database. But you introduce strict boundaries inside the code. Split the system by business domains, not by technical layers. - Orders - Payments - Users - Catalog Each module owns its logic. Modules talk to each other only through well defined interfaces. No shared models leaking everywhere. No direct database access across domains. This alone removes a huge amount of pain. Releases become safer. Understanding the system becomes easier. Developers gain confidence again. And the best part operations stay simple. Step two: decide if microservices are actually needed Once your monolith is modular, something interesting happens. You can clearly see which parts change often. Which parts need scaling. Which parts are stable. Now, if you truly need microservices, you have a clean path. This is where the strangler pattern fits. You keep the modular monolith running. You put a routing layer in front. You extract one module at a time into a separate service. Traffic is slowly redirected. No big bang rewrite. No unnecessary risk. If you stop halfway, you still have a healthy system. The practical advice If you are on a monolith today and feeling pain, do not ask “How do we move to microservices?” Ask instead “Where are our boundaries missing?” Fix that first. A well designed modular monolith solves most problems teams blame on monoliths. Microservices should be the result of pressure and scale, not the starting point. This mindset saves time, money, and a lot of late night incidents. How to choose - If your team is slowing down and wants stability start with a modular monolith - If you have multiple teams, high traffic, and need independent scaling microservices may make sense - If you already have a monolith and want microservices safely use the strangler pattern Last thing I am not against microservices I am against using microservices as a fix for unclear boundaries and undisciplined code. Solve the problem first then choose the architecture. 👍

2

3 Comments

This is the hardest article I’ve ever written. Not because of the topic — Clean Architecture — but because I tried to put years of personal experience into one structured piece. It’s the first part of a new series where I share how I moved from chaotic codebases to scalable, testable architectures — and what I wish I knew earlier. I don’t promise magic. Just lessons from real projects, deadlines, and rewrites. What’s inside: • Why even simple apps become hard to maintain • When MVVM starts falling apart • How Clean Architecture can help — if used with care Read the article here: https://lnkd.in/dqhK_n94 If you’re working on a growing iOS/macOS app — maybe it’ll save you some time. #iOSDevelopment   #SwiftUI   #CleanArchitecture   #MobileArchitecture   #SoftwareEngineering  

40

6 Comments

If you’ve ever struggled with keeping database changes in sync across dev, staging, and prod - Flyway might be the tool you didn’t know you needed. I've written a 2-part blog series tailored for developers: Part 1 : Why use Flyway? Understand the why behind Flyway, versioned migrations, idempotency, and what it brings to the table for modern dev teams. -> https://lnkd.in/dZtPAK5N Part 2 : Hands-on with MySQL A step-by-step walkthrough: setting up multi-env DBs, running migrations, seeding data, lifecycle hooks, CI/CD, and more! -> https://lnkd.in/dbGbQNc3 Built for developers by a developer🤓

7

2 Comments

Scaling to a billion documents is not just a technical challenge; it's a strategic one. The recent Symfony article on managing Germany's dynamic fuel prices and scaling with MongoDB offers a brilliant deep dive into how intelligent data modeling can transform a seemingly overwhelming dataset into a performant, insightful application. It highlights that the true power lies not in merely storing data, but in how we structure it and efficiently extract value from it. The strategic use of patterns like the bucket pattern and calculated denormalization, paired with MongoDB's robust aggregation framework, is critical. This approach allows developers to significantly optimize read operations, which is paramount for delivering lightning-fast user experiences and real-time analytics in complex applications. For instance, a simple but powerful aggregation stage might look like this for daily data processing: { "$set": { "day": { "$dateTrunc": { "date": "$date", "unit": "day" } } } } In my PHP and Laravel projects, especially when dealing with high-volume data streams, applying these NoSQL principles with MongoDB, and integrating them into responsive frontends built with React or Flutter, consistently delivers superior performance and scalability. This kind of architectural foresight ensures that businesses can not only handle massive amounts of data but also unlock its full potential for informed decision-making and competitive advantage. What are your go-to strategies for tackling billion-scale datasets in your projects? #SoftwareDevelopment #WebDevelopment #PHP #Laravel #MongoDB #DataModeling #Scaling #BangladeshTech

1

Is frontend development becoming more like electrical engineering? My latest post looks at the connection between Angular Signals and Control Theory. Reactivity is not magic. It is a study of feedback loops and system stability. I cover: Producers and Consumers as Feedforward systems. Computed values as Low-Pass Filters. Preventing UI oscillations and infinite loops. Understanding the physics of state makes us better architects. Link: https://g.omid.dev/Lbi72TS #Angular #SoftwareArchitecture #Engineering #WebDevelopment

4

Something exciting is starting for the tech community in Lisbon. I’m really happy to share that I’m helping launch LeadDev Lisbon, bringing one of the world’s largest engineering leadership communities to Portugal. LeadDev connects engineering leaders across cities like London, New York, and Berlin, and now Lisbon joins that map. Together with Fábio Sampaio, Rui Posse, Hugo João Mota, Diane Lee and a fantastic support of Ishaan Singh, we’re starting to build a space for engineers, tech leads, and engineering managers to exchange ideas, share real experiences, and discuss the challenges of building modern technology. And we’re kicking things off with our first event, hosted at AIhub by Unicorn Factory Lisboa. 🎤 Building AI that Matters João Galego - Head of Data and AI @ Critical Software 🎤 Responsible AI: Driving the Next Generation of AI Products Paulo Dimas - Founder @ Halo NeuroAI & CEO @ Center for Responsible AI 📅 March 19 🕕 18:00 📍 Lisbon - AIhub If you’re an engineer, tech lead, engineering manager, or simply interested in AI and technology, this is a great opportunity to connect with the community. 👉 The registration link is in the first comment.

66

3 Comments

The "Big Bang" rewrite is dead. Long live Shared Logic. 🛠️ I’m working on my first module to Kotlin Multiplatform (KMP), and I’ve realized we’ve been looking at "Cross-Platform" all wrong. The blueprints shared by Big Tech aren't about replacing platforms; they’re about surgical migration. My takeaways from the trenches so far: Logic over UI: It’s not about making iOS look like Android. It’s about sharing the "heavy lifting"—Auth, Checkout, and Data—in one Kotlin core. Incremental, not destructive: No need to burn the house down. I’m migrating piece-by-piece, starting with our core business logic. Zero UI compromise: We keep the high-performance native UIs that users love. KMP just makes the engine underneath more efficient. KMP is winning the Enterprise market because it’s pragmatic, not dogmatic. It respects the platform while ending the era of "writing everything twice." For the KMP veterans out there: What was the first module you moved over? Networking, Auth, or something else? Let’s swap notes below! 👇 #KMP #Kotlin #MobileDev #SoftwareArchitecture #LearningInPublic #TechTrends #android #ios

48

1 Comment

Underestimating the effort and cost for delivering on something does not give you the right to ship a sub-par product. You should not use this as an excuse to skimp on quality and do a half-arsed job! If anything, you should use it as a conversation opener, when you go to renegotiate your contract.

2

Kotlin developers know the struggle: sometimes you just need a PDF viewer SDK or a spreadsheet editor, not an entire enterprise bundle of tools you’ll never touch. Syncfusion heard this feedback loud and clear. With the release of Essential Studio 2025 Volume 3, they’ve restructured the suite into modular editions—UI controls, document SDKs, PDF, DOCX, spreadsheet editors, or the full Enterprise package if you want it all. Why this matters for Kotlin devs: ⚡ Pick and pay for only what your project needs ⚡ Integrate document editing or PDF features without heavy dependencies ⚡ Experiment with new AI-powered Blazor features like Smart Paste and Smart TextArea For mobile and multiplatform Kotlin projects, this flexibility is a win. No more bloated installs, no more licensing overkill—just the SDKs that get the job done. 👉 Which SDK would you find most useful in your Kotlin projects? #KotlinDevelopers #MobileDev #SDKtools

13

2 Comments

Been experimenting with something called Pathfinder. The idea: map user journeys in your codebase, visualise what's tested vs what's not, and generate the missing UI tests to close the gaps. Early days, but it keeps surprising me. https://lnkd.in/eKQPBwmJ

16

1 Comment