Steve Kuo

Having a ton of fun writing an ORM for V2 of Case Kit. Typescript has such an incredible type system. I have autocompletion for column names, the ability to include relations, relations of relations, etc etc etc... all returning properly typed data (no classes in sight). It's been really satisfying seeing it coming together, and it's been great getting my hands dirty with some (relatively) complex generics. And to head off the obvious question… why aren’t I just using Prisma? Well there’s a couple of things I’m doing differently that I think are marginally better: there’s no code generation involved here, it’s just types (inspired by Drizzle); there’s no Rust binary you need to deploy, and it hews much closer to Postgres behaviour and syntax (the aim here is not to abstract away which database you’re using). But the real blocker to me using Prisma was that its extensions don’t support modifying queries of nested relations - a hard requirement for me due to the way I have multitenancy and soft deletes set up. It’s not shown in the video but the Case Kit ORM lets you write simple middleware that will be applied to every level of a nested query. Perfect for setting timestamps or adding clauses on tenant id or things like that.

21

Measure what matters. I've written a 1000 lines of code before, demonstrated it, and then never touched it again. I've written a line of code that gets used over, and over, and over. Which is more important? Which hits the metrics? More importantly, which one is incentivized? Find ways to measure impact and outcomes. Everyone will thank you for it. And your software production will be incentivized around what matters.

9

I've worked in similar environments and deploying to production several times a day takes a lot of the risk out of delivery. As mentioned here it's predicated on separating the concepts of deployment from release using techniques like feature flags and branch by abstraction.

8

The things that TestSenseAi will solve: - Slow QA/QC analyst - Uncompromised QA - People that thinks that knows about automation and does a counter productive work. - Middle Managers positions that works as stoppers - Help a lot to UX and developers to detect stuff before implementation - Open Source - Give you the reason to have QA that will Really help your business. Most importantly, you can contribute, help, suggest, and we can do it, or even you can do it. We don't need more processes in the software development activity, we need productivity, more time to make better products. No more QA's to win more money for a shitty product. #qa #automation #software #development #node #typescript #ai https://lnkd.in/dwTNZ4CS

7

4 Comments

🚀 How We Make Learning Stick (And Why It’s Worth the Effort) 🚀 A comment I saw recently on X/Twitter from one of my Head First C# readers really resonated with me: "So many programming books are just info dumps. This one is designed to get you to actually LEARN. Can’t say enough about it, and I wish the authors would write one for everything I need to know." https://lnkd.in/ef5-bKQY This stuck with me because it highlights something I put a lot of effort into: making sure that readers don’t just skim through the material, but actually learn it. And the funny thing is, it’s a lot of work to make learning seem effortless. Take encapsulation, for example. When we introduce this concept in Head First C#, we don’t just throw a definition at you and move on. Instead, we build a story around it—like the one where two spies are trying to keep their secrets safe. The spies represent objects in a program, each with their own hidden data that they don’t want anyone else to see. We show you how encapsulation lets these "spies" control who gets to see their secrets, which helps protect the integrity of the data and makes the program more secure. This isn’t just about keeping you entertained. It’s about making the idea stick. Your brain is more likely to remember stories and visuals than dry facts, so we use these tools to make complex concepts easier to grasp and retain. But that’s just the beginning. Learning is a journey, and I think about it in terms of Shu Ha Ri—a concept we explore in Learning Agile, another O'Reilly book I wrote with Jennifer Greene. I think about it a lot when I'm writing or teaching: • Shu (Learn the Basics): When you’re new to a topic, you need simple, clear examples to build a strong foundation. That’s why we start with basics, using stories like the spies to explain concepts like encapsulation. • Ha (Explore and Adapt): As you get more comfortable, you start to experiment, tweak examples, and apply what you’ve learned in new ways. This is where the fun really begins—when you start to see how everything connects. • Ri (Master and Innovate): Eventually, the concepts become second nature. You’re not just following rules—you’re creating new ones and finding your own way to solve problems. So, yes, it takes a lot of work to make learning seem easy, but when I see comments like this, it reminds me why it’s worth it. #CSharp #Programming #SoftwareDevelopment #TechEducation #LearnToCode #Coding #LearningJourney #Agile #SoftwareEngineering #TechBooks #OReillyAuthor #Encapsulation #TechWriting #Developers #CodeBetter O'Reilly

20

2 Comments

Between 1995-2010-ish it was popular in the agile community to talk about patterns and principals. 15-25 years later we see the industrialized late adopter / laggard version of agile as the norm. I wonder if the "product operating model" (a synthesis of patterns in use for ~20y, similar to how a 2010 agile pattern language represented patterns in use starting in the 80s and 90s) will follow the same trajectory based on the introduction of domain-specific pattern languages? In 2035 will be be talking about the "death of the product operating model"? History would say....yes. The funny part about Agile is that I would say the *core* ideas are perhaps even MORE in demand (or relevant) now, even among the companies that see themselves as high performing product orgs. You can argue that *some* Agile ideas have widespread adoption, but when you look at how few companies have healthy, functioning teams that follow some of the edgier and heretical parts of the agile manifesto, you might view those companies as the "top" 1-2%.

268

81 Comments

One reason I pulled yesterday's post out of what I'm writing for the book is that salary is almost a separate book on it's own - and one likely better written by somebody else. In my own career managing software engineers, I've seen it handled so many different ways: - When working for a very large media company, I don't recall knowing the salaries of my team. Instead, I worked in percentages that were tied to performance bands. - A few other times, I had approval, but the salary adjustments happened in HR or at a departmental level above me. I communicated the adjustment along side a review (usually), but didn't make the decision. - Another time, I got a spreadsheet with the team, their salaries, and a bucket of additional cash I could spread between them. So, right-sizing one salary might mean short-changing somebody else - unless I went back to HR and tried to make the bucket bigger. Each company has handled salary adjustments (and starting negotiation, but that's a chat for another time) differently, giving different levels of autonomy for their direct managers. These constraints and context aren't always communicated to the team - I can't recall if I ever shared this with them, for instance. If you've managed folks, how much control have you had over their salary adjustments when the time came? And did you wish you could tell them how little you had?

5

1 Comment

I see we've hit the top of "Selenium and WedDriver are crap and you're awful if you still use it" cycle again... and I despair. Either people are saying these things to get clicks since social algorithms promote controversy or they don't understand how these tools or browsers work. And I can't tell the difference. What I think people should be doing is looking at how they test their software. * Should we do everything in E2E tests? God no.... * Should we do everything in Unit Tests or Integration tests? God no... but there should be more E2E tests I can guarantee if you were to rewrite your test suite from scratch from Selenium to Selenium since your flakiness is nothing to do with the framework. It has more to do with your thinking through of how to test. I wrote about this before... Next time you see some putting hate on ANY framework ignore them, don't engage. They're showing they're other "karma" fishing or don't know the space. A rising tide lifts all ships... If you want to go fast, go alone, if you want to go far go together. https://lnkd.in/e4HYxZNy

100

18 Comments

The Daily Scrum is NOT a status meeting. It’s *not* about Developers “reporting out” to an audience like a morning roll call. It’s about the team aligning to achieve the Sprint Goal. Think of a home renovation show: the crew starts with a plan—tear down this wall, install that countertop. But the moment they swing the hammer, they discover mold behind the wall. Now they’ve got to pivot. The goal (a beautiful new home) hasn’t changed, but the plan needs to—mold remediation just made the to-do list. That’s what the Daily Scrum is: a time for Developers to inspect progress, adapt the plan, and stay on track toward the Sprint Goal. It’s team-to-team, not team-to-audience. Stop turning the Daily Scrum into a status report. Tear down that wall and build something better. #Scrum #Agile #DailyScrum

185

33 Comments

"Our documentation is great!" said no one ever. It is always interesting to talk to folks about this problem. It'ss a problem that can be hard to grasp, measure, and even harder to solve. That is; unless you think about it in a different way. A little bit of simplification, structure, and even some AI might do the trick. I also found a new AI tool, Unblocked, while at LambdaConf this week. I am excited to start experimenting with Unblocked and think it could be a game changer when it comes to managing documents across an organization. Check out my latest article where I talk about #knowledgemanagment. Dennis Pilarinos Daniel Horton

28

1 Comment

James Grenning course is top notch - well explained, easy to follow, and appropriately deep.

5

This post serves as an excellent reminder that systems design and API design are *incredibly hard* to get right, *even* for people that have lots of experience and who have built similar systems in the past. As someone who has built systems used in production and lived to regret many of my decisions, I find this somewhat comforting. The linked sig-architecture thread [0] also has lots of interesting tidbits, including this bit from the legendary Tim Hockin: "Of all the APis we have, Node has some of the weirdest semantics. First, it's one of a very few "non-causal" objects(1) we have in core. Also, it is one of the oldest APIs, so it suffers from under-design, under-specification, organic evolution, and calcification - all contributing to or resulting from the success of k8s. If we were starting over, I doubt Node would be designed the same way. That said, we have to work with what we have. IMO, deleting a Node probably *should* cause a drain and should cause a controller to release the VM behind it (if appropriate), just like deleting a volume releases the disk behind it and deleting a service releases any LB attached to it. Can we fix that? I don't know...maybe?" https://lnkd.in/diFyvWhE by David Morrison [0] The whole thread is worth reading, but especially the laments of the folks that have been working on Kubernetes since the beginning: https://lnkd.in/d48cjiBZ

3

I suppose it is safe to say now without jinxing it, because the official internal org chart has been updated. This past week was my first in a new role at Microsoft. I joined a group of folks working on the personal version of Microsoft Teams, aka "Teams for Home." Everyone has been warm and inviting. I even got to jump into the deep end via a forwarded meeting about craft and quality. https://lnkd.in/gwmyx3bv Practically speaking, this means at any given time I will probably have four versions of Teams running. – Teams for Home: desktop app – Teams for Home: web app – Teams for Work: desktop app – Teams for Work: web app [Insert joke about meeting fatigue here.] I will miss working with SolidJS, and having front-end discussions (arguments?) with Cody Lindley. Thankfully, we both landed under the same overarching umbrella of consumer facing chat products, so he is still just a DM away. #microsoft #msteams #newjob

78

12 Comments

Accessibility Tip of the Day 271: Here's a great (and short!) article from Adrian Roselli on "Things to do before asking 'Is this accessible?'" (https://lnkd.in/gK7E5wRa) The big three questions he typically asks in response are: 1. What do you mean by "accessible"? 2. What prompted you to ask that question? 3. What work have you already done to check? #accessibility #a11y #accessibilityTipOfTheDay

11

2 Comments

I started my career dreading test-writing. Testing felt like "eugh!" TDD felt like "YUCK!" Ironically, the dread was architectural: Legacy code. There was nothing wrong with my ability to write tests. In fact, I could write silly tests all day long. Often they didn't test anything useful. That was not very helpful. The architectural problems were deeper. The resistance was triggered by not being able to write testable code. By the discomfort of learning how to design testable code. Differences between composition and abstractions? What are the right ports and adapters? What behaviors matter? To the business? For the user? For me? Now I use TDD. I coach how to TDD. But that's not really the point. It's just a tool that stuck with me on my journey through learning how to attack issues on the above list. For example, I recognise formal concepts such as decomposition in functional languages, as well as Event Modelling to plan out behaviors via data flow to be a viable alternative to TDD. Well, not to TDD exactly. But to behavioral decomposition and design through TDD. Regardless if you're a TDD'er or not... 💬 ... what process do you use to decompose behavior in your design? 🚫 It's you vs. the algorithm—take control of what you see and join thusands of engineering leaders 🔔 Hit the 'view my blog' button under my name to subscribe 🔔 ♻️ Reposts feel like hugs

7

6 Comments

It sounds obvious doesn't it. Yet more often than not when I speak to industry leaders it's the first complaint I hear. "Our developers are constantly having to clarify requirements" "Our testers don't have enough information to understand if this feature works correctly." Everything hinges off requirements. If you have poor quality requirements the chances of high-quality software being produced is lower! We have found visual modelling to be an incredibly powerful approach for creating more rigorous requirements. The most impact I see in teams is by incorporating collaboration it promotes continuous feedback and refinement. #CuriositySoftware #OuterLoop #QualityModeller #MBT #ModelBasedTesting

13

1 Comment

These are 5 questions I faced implementing micro-frontends: 1️⃣ What defines a "feature"? Is it user-facing functionality, like a landing page, or something smaller, like a profile avatar module? How granular do you go before the effort of separation outweighs the benefits of flexibility? 2️⃣ How do you handle cross-cutting concerns? Features like search, notifications, or navigation bar are often used across multiple parts of the app. Should they belong to one micro-frontend or multiple? Or should they live in a shared "platform layer"? 3️⃣ What happens to the user experience? Splitting functionality can easily lead to inconsistent design patterns or performance bottlenecks if not coordinated carefully. Micro-frontends may give teams autonomy, but users still see a single product. 4️⃣ How do organizational structures influence technical decisions? Conway's Law is alive and well here. The boundaries of your micro-frontends often reflect the boundaries of your teams. 5️⃣ Will the boundaries hold over time? The hardest part isn’t always designing the boundaries but evolving them. Features grow, requirements shift, and what seemed like a logical split today might create unnecessary friction tomorrow. It’s not easy, but the payoff can be huge if done thoughtfully. If you’re wrestling with these questions right now, know that you’re not alone.

8

1 Comment

This article on #misconceptions surrounding the field of #technicalwriting and the role and skills of #technicalwriters is worth a read.

6

1 Comment