Felix Changoo

Styling feels like a frontend concern - until your server starts doing the work. I’ve written a short post on how server-side rendering changes the cost of CSS, and why some styling choices can quietly limit throughput once rendering moves onto the server. There’s also a small benchmark to make the trade-offs visible. Enjoy! 👉 https://lnkd.in/g-RFKXsc #SoftwareEngineering #WebPerformance #SSR #Architecture #React

59

🔥 Hot take: Learning more tools won’t make you a better developer. What actually matters is: How you think when requirements change How you design systems, not just UI How you debug, secure, and scale what you build Anyone can follow a tutorial. Very few can take a messy real-world problem and turn it into a working system. Right now, I’m more interested in: 🧠 system thinking 🔐 security-aware development 📈 scalable architecture 🛠 building things people can actually use If you’re in tech: What skill do you think matters more than learning a new framework? Let’s talk 👇 #Technology #SoftwareEngineering #SystemDesign #CyberSecurity #BuildInPublic #TechMindset #Developers

4

As an early adopter of AI tooling in my workflow, I can confidently agree that you must be extremely careful building anything more than simple functions and brainstorming with AI. Often times the solutions AI suggests will work, which is extremely dangerous if "it works" is your measure of success. It is only weeks later or after you have already broken something that you will discover some of the logic bugs it can introduce that do not respect the existing tooling of your codebase, only works with test values and not real production values, or reinvents the wheel (but worse) That being said, AI can help a senior developer write code in a fraction of the time they would have otherwise, especially when you need to take something that already exists in your codebase and modify it to work for a new use case. AI really excels at taking your existing code and creating something new with it. It is also adept at improving small chunks of code like a single function or algorithm. For anything more advanced, I would only recommend using it for brainstorming or prototyping (in cases where you throw the prototype out as you develop the final version from scratch with the lessons you learned.)

2

One of the more underrated things a Rails developer can do for their career is show up to an in-person event. The obvious value is learning. But the less obvious value is compounding. The conversations in the corridor between talks, the developer you get chatting to before a keynote, the hiring manager who notices your question during a panel — none of that happens on a Slack channel or in a GitHub thread. Sorcer were proud sponsors of Brighton Ruby last year, where we saw exactly this in action. The room was full of developers at every level, from juniors finding their feet to principals who’ve been writing Ruby since the early days. The quality of conversation across that range is something no conference livestream replicates. If you’re considering whether a developer event is worth the time away from the day job, the research backs what most experienced developers already know: career-defining roles are more likely to come from a hallway conversation than a job board. Brighton Ruby returns this year. If you haven’t been, put it on your list. #BrightonRuby #RubyOnRails #RailsDevelopers #DeveloperCommunity #TechEvents #RubyConference #Sorcer

7

If you’re a US startup hiring mobile this quarter: screen for release ownership, not Flutter trivia. Senior candidates don’t separate “engineering” from “shipping.” They own releases, hotfixes, and the messy production stuff that actually matters. One question that works: “Tell me about a release that went sideways. What broke, how did you diagnose it, and what did you change so it wouldn’t happen again?” The answer tells you if they’ve actually owned production when it broke.

17

5 Comments

You might be paying a full engineer's salary without getting anything in return. This will benefit the Tech leaders and the executors. Problem Weight = Problem Effect * Volume of Effected As technologists, we're constantly solving problems. But it becomes a "Grind" when we're never pausing to make the judgment if a specific problem is worth solving, if it's the highest priority to use our labour on. The equation on top is a simple way to understand the weight of a problem you're solving, and helps to guide which problem-opportunities are worth pursuing out of the infinite realms of problems captured by your mind's vision system. Here's a simple example: Your developer environments' data queries are slow; let's say it takes 30 seconds. Is this an impactful problem that you should dive headfirst? It depends. Let's look at it: The impact of the problem: 30 seconds lost on a data query. If, on average, you run the query 10 times, you're losing 3 minutes on the query. And every 30 seconds increases the probability to come out of the zone of focus, let's say the cost per 30 seconds of distraction is 5 minutes on average. We often make the mistake of calculating the weight of the problem without an understanding of human psychology. So, the cost of this delay on the workflow is around 5 * 10 = ~50minutes If we round up for easy calculation, it's 1 hour per day. For a realistic range, it'll be around 30mins - 60mins. So, problem impact = ~45mins ( avg: (30 + 60)/2 = 45mins) Now, if you have 10 engineers working on the project, you have the problem weight of: Problem Weight = 45mins * 10 = 450 mins. That query delay is costing you 7.5 lost engineering hours per day. So, due to this simple 30-second delay, you don't have 10 team members, you actually have 11 team members (you're paying ~8hours/day), and one of them is doing nothing. Would you pay someone the engineer's salary for doing nothing?

3

If a friend asked us how to choose a dev team, we'd send them this The way companies hire dev teams has changed. Rates and portfolios still matter, but they won't tell you how a team actually works day to day. We put together 6 questions that we think are worth asking on a first call with any dev partner, based on what we see from our side of those conversations. What would you add? #Pynest #devteam #hiring #software

6

New WoT Tooling for Eclipse Ditto: Generating Kotlin Code & OpenAPI from W3C Web of Things (WoT) Thing Models My awesome colleague Hussein Ahmed published a blogpost ([1]) about the ditto-wot-tooling project bringing two powerful build-time tools that work with W3C Web of Things (WoT) Thing Models: ___ WoT Kotlin Generator (Maven plugin) 🔹 Generates type-safe Kotlin data classes, builders, and path helpers directly from your Thing Models 🔹 Enables compile-time safety for building Ditto commands, RQL filters, and conditional requests 🔹 Keeps your backend code in sync with your Thing Model schema—no more model drift ___ WoT to OpenAPI Generator (CLI/library) 🔹 Converts Thing Models into OpenAPI 3.1.0 specifications 🔹 Frontend teams can generate TypeScript/JavaScript clients automatically 🔹 One Thing Model drives both backend and frontend from a single source of truth ___ The tools complement Ditto's runtime WoT support: while Ditto uses Thing Models at runtime for validation and generating Thing Descriptions, these tools use the same models at build time for code generation and API documentation. ___ We at beyonnex.io make use of that in our CI pipelines to automate documentation of our IoT devices and to make sure our Kotlin codebase creates the modeled Ditto Thing JSON formats. ___ Want to find out more? Check the blogpost ([1]) and try out creating WoT ThingModels and the tooling. Reach out via GitHub [2] for feedback or contributing. 🚀 [1] https://lnkd.in/edrZZjeB [2] https://lnkd.in/eEJQb7rS

37

1 Comment

Reflecting on agentic coding after seeing repeated refutals posts that large company layoffs attributed to AI being a copout. I don't think they are cop outs. It's real, dude. And I believe the pace is going to pick up as more company's wade into AI more deeply. Not saying I like it or that it is great, but it is real, coming from someone who is seeing what it can do firsthand as a traditional software engineer: https://lnkd.in/g3sCeFhy

9

2 Comments

TypeScript didn’t make me a better developer. It just stopped me from being a careless one. Most of my bugs weren’t complex  They were simple mistakes I didn’t catch in time. Wrong types, missing props, undefined values… TypeScript forced me to think before I wrote. It’s not about writing perfect code. It’s about writing code you can trust. #TypeScript #WebDev #CleanCode #DevThoughts

37

1 Comment

Nam, a journeyman new to the world of AI, was struggling with his colleagues and receiving tough feedback on his code reviews. Feeling discouraged, Nam sought out Nobody, the wise programmer who had traveled this path before. Under a tree, Nam found Nobody chatting with an AI coding agent. "Master Nobody," he asked, "why are my colleagues so critical of me and my AI-generated code?" Master Nobody said: "Before sending your AI-generated code for review, it must pass through three gates: 1. Have you personally reviewed the code generated by your AI? With your eyes open, looking at the diff? o_0 2. Did you ask another AI, acting as a senior engineer, to thoroughly examine the code end-to-end, checking functionality, maintainability, and security? 3. Has your AI written comprehensive tests with 100% functional coverage of the new AI-generated code? But remember this: if your AI writes mocks just to hit 100% coverage, it's cheating." Nam returned to his computer. He thoroughly examined Master Nobody's lessons, personalized the advice, and applied it. The results were 10x improvement in his code quality. His colleagues and his bosses were very very happy. Inspired by this breakthrough, Nam wrote a doc outlining his new methodology: "Working with AI Effectively by Leading with Questions and Evidence."

13

Just dropped a new post on fixing one of frontend's biggest headaches: inconsistent UIs 🎨 - Read here: https://dub.sh/W5myHj3 "Building Consistent UI with Design Tokens" explains how to go from 17 shades of blue to a maintainable system that scales. This systematic approach eliminates inconsistencies and significantly reduces maintenance overhead for frontend engineers, tech leads, and anyone building design systems. What's your biggest UI consistency challenge? It's worth a read (Link to full article: https://dub.sh/W5myHj3) if you've ever inherited a codebase where every button looks different 😅

10

I had a great time chatting with Rachel Brindle about what's new in Swift Testing. If you are looking to learn about what's coming to Swift Testing soon, check this episode out. https://lnkd.in/gPb_7Bev

5

🚨 Noticing a trend in iOS job postings lately: tons of Senior iOS Engineer openings, but very few Staff-level roles(Pinterest, Reddit, Inc., etc.) Why might that be? A few thoughts: - Staff roles are scarce by design — usually tied to cross-team strategy and often filled through internal promotion. - Senior is the default external hire — teams need execution power to keep shipping. - Mobile teams are leaner — most companies aren’t mobile-first, so iOS/Android teams often focus on feature parity with web/desktop. - Staff-level needs are narrower — backend/infra orgs require constant architectural alignment, while mobile architecture stabilizes faster. That said 👉 mobile engineering is not “simpler.” It brings its own hard problems: battery usage, scroll performance, offline reliability, and UX constraints that don’t exist elsewhere.

217

9 Comments

My current crew in Gas Town Auteur: UX expert. Focused on making everything the user sees and touches magical. Penny: Resident QA specialist. Sweeps the codebase for bugs, vulnerabilities, performance tweaks, and test gaps. Basically the auditor for everyone else's testing failures. Mutant: Mutation tester. Solely focused on maintaining mutation scripts and creating work for everyone else to fix. Effectively Penny's test auditor. Bob: Ensures the code and architecture of the app abides by the clean code principles I've documented.

7

The rate at which ClaudeCode uses mock data, hardcodes, and cheats to make a test pass or fix a bug is alarming. There’s no way you can use this tool for so-called “vibe coding” to build anything meaningful. I appreciate the progress made so far in AI-assistant coding, but these tools still have a long way to go.

4

1 Comment