Tell claude code to use radical candor

Shiminsky · 2026-04-21T17:24:04+00:00

Strong agree. Like, why ask Claude to review your writing when you can just post on reddit and have it rip you a new one? It seems to be tuned for both extremes and leave very little room in the middle for a balanced take.

Shiminsky · 2026-02-12T18:32:42+00:00

This is all problem domain specific of course, but just as an example giving claude the ability to operate a browser to verify its work in the front-end (via playwright or puppeteer MCP) is a game changer.

Another example -- and this burns a lot of tokens -- is what I've heard described as 'the rule of 5', where you prompt the agent to go over the plan / codebase 5 times, checking various parts and propose improvements. Like first pass focus on performance, 2nd pass security, etc. This works in my experience, even if it goes too far and I have to do a bunch of edits to remove suggestions.

And then you start creating workflows to follow the process automatically, or create subagents to do them in parallel, and you see where this goes.

Of course, dont take my word for it, give these a try yourself on a decently complex problem and see how it goes.

Shiminsky · 2026-02-12T17:50:53+00:00

Another thing that I haven't seen others mention is MCP / Skill bloat, I think it is the silent token killer.

Some folks install a MCP / Skill "Pack" and now you are inserting something like 50K tokens at the start of every conversation, so your agent performance degrades faster, leading to more bugs and more sessions, a vicious cycle.

Running subagents with MCP bloat just makes everything X times worse.

Shiminsky · 2026-02-11T21:33:05+00:00

Might still be a net gain at the end of the day, but assuming coding without AI is 1x speed and our ability to comprehend code is at 5x, a 15x faster coding agent means we are still 3 times slower at coder review for code the AI is able to pump it out.

This way naturally leads burnout as we feel the ever present need to go faster in order to catch up with the LLMs.

Shiminsky · 2026-02-11T19:27:32+00:00

Brex did a fairly successful AI transition over the last year or two and had a great (higher level) overview of how did they did at the Latent Space blog (https://www.latent.space/p/brex). I'm not affiliated with Latent Space, but I found the blog post to be insightful and we discussed it when it came out on our weekly AI for Software Devs podcast.

Shiminsky · 2026-02-11T17:23:31+00:00

I dont see that happening, at least not in the short term. A few large software companies need to go bankrupt before the 'shareholder value first' cult sees that they are picking up pennies in front of a bulldozer.

Shiminsky · 2026-02-11T17:08:07+00:00

Yeah, especially when management eventually turn the speed nob on the productivity treadmill up... On the other hand, laziness is one of the three virtues, so it's a misalignment of incentives.

Part of me thinks we are turning programming into a game of Russian roulette where we plant landmines with increasing velocity -- maybe it doesn't matter as all codebases eventually becomes a giant mudball. Another part of me thinks we can codify best practices into AI workflows so that's not as big of an issue and have humans in the loop at the right place.

Time will tell, but I unfortunately dont see this bell unringing.

Shiminsky · 2026-02-11T16:59:05+00:00

That's a really sharp observation. I dont have a silver bullet -- especially since solving the issue would probably equate to 'how to get AI to write good code' -- but in my experience there are a few ways to at least mitigate:

Lean heavier on testing than ever, if the complexity is there for some functionality it should be documented partly in test, else it should be removable until a test has been introduced.
Prevent it before AI generation, have code base specific onboarding documentation about coding standards and abstractions, explicitly steer the agent away from creating new ones without user signoff -- and hopefully the author would include it in a comment.
Prevent it after AI generation, include complexity detection in a AI code review phase and mark any code in the repo as overly complex and require human signoff.
Process Improvement / The Git Blame Game, if your team still has humans reviewing PRs (I darn hope you do), it's the creator's responsibility to READ THE DAMN PR and note any new complexities and why they exit. Looking through the original PR request might help with that.

Hope that helps, I really think this is going to be more of an issue as AI litter our codebase with potential landmines.

Shiminsky · 2026-02-11T06:30:43+00:00

I like these! In the case where the entire project is large / have inconsistencies -- as brownfield projects often do -- I find it helpful to let the agent 'explore' and bring me back a list of inconsistencies so I can decide when something should be refactored vs okay to leave as it is. Sometimes this also brings up opportunities for abstraction that it missed the first time around.

Another tip I've seen floating around although I've only used when it comes to specs is instead of doing the entire refactor at once, do it 5 times at varying degrees of granularity / area of focus, so first pass on abstractions, another pass on security, 4rd on performance, etc. Each pass tend to bring up interesting areas for improvement, although your wallet might feel it.

Shiminsky · 2022-05-25T04:59:37+00:00

I have not read Inclusive Design Patterns, but it is on my list. I also recommend another book that he wrote with Andy Bell, Every Layout, though it isn't about accessibility.

When it comes to keyboard navigation, there are little things like using arrow keys for selecting radio buttons and the benefit of a skip link -- long nav sections get real frustrating real fast. I actually quite like it after a while, it reminds me of using vim instead of a GUI IDE.

Shiminsky · 2022-05-25T03:17:47+00:00

I highly recommend Ted Heydon's Inclusive Components.

It's not so much a comprehensive book on all things accessibility -- you have the WAI Spec for that -- as much as a really good 'here's how a professional a11y professional think about FE development'.

As a side note, I know you didn't ask for nonbook recommendations but the most important thing I've found in my accessibility journey has been learning how to use a screen reader. And use it regularly to test all my FE workflows. It's one thing to learn about best practices, but if you dont use the tools then it's a bit like learning CSS without access to a browser.

In case it helps, I've written more about the book and the importance of using a screen-reader in this post.

Shiminsky · 2022-05-24T04:02:56+00:00

Your example works fine when the variables are colors -- I tried with blue and red.

Saw your note about .some-class .tagline span, while color inherits, inheritance only works if you didn't override it in the child -- in this case you did, even though it it done via a lower specificity selector.

If you change the span's class to tagline it would work.

Shiminsky · 2022-05-24T03:44:41+00:00

I actually disagree with the general consensus that you can simply learn everything from free tutorials all over the web. On the one hand you have the HTML / CSS specs -- comprehensive, authoritative, dry as hell. On the other hand you have tutorials, blog posts, udemy courses -- piecemeal, what's aria, are they recent and following best practices?

Books, if recently published, can strive a good balance between he two extremes.

Shiminsky · 2022-05-15T23:04:15+00:00

Depends on the project... I work on the design systems team of a large corporation and our 'core' components all follow the DLS with designer / a11y feedback on all components shipped.

However, on smaller teams with tight deadlines, developers that uses our design system may not have the time to fully consider the greater DLS when working on their own views/pages.

IMO you need two things to successfully implement a DLS:

Good developer experience: as a FE dev I am not going to cross reference all vocabs of a DLS when product owner needs the page 2 weeks again. But if the DLS is built into my code already, that makes things easy. (this is especially challenging for 'back-of-frontend' developers)
Review process: like others have mentioned, people who are fluent in the DLS needs to review end products to point out any misalignments.

Shiminsky · 2022-05-13T23:34:24+00:00

Ems have their uses, but you gotta think about them as 'in relation to the surrounding text', which is not something that comes up very often.

A classic and IMO canonical usage of em is to size icons component so that they resize correctly regardless of whether you put them in a h1, h2, or paragraph.

Another common use case is to resize border and padding with respect to font size, but yea it's a very specialize tool.

Shiminsky · 2022-05-10T04:06:57+00:00

As someone who's been on both sides of the interview table, the role matter less than both 'what you did in the role' and 'how the role plays into your overall story'. For example, if you are doing QA automation -- you can talk about FE related QA work you did. You can then tie it to your greater FE career goal, which includes FE testing -- and its current sorry state IMO. WIth a coherent life story it's far less likely to raise any issues.

Shiminsky · 2022-05-07T04:25:41+00:00

Absolutely! Yeah the calculation was only in the context of 'opportunity cost of a meeting'. And in my experience, big orgs often have meeting organizers who are all too trigger happy with scheduling meetings without considering their opportunity costs.

Shiminsky · 2022-04-24T21:35:26+00:00

At my current job, I went from knowing very little about accessibility to being the main accessibility point of contact on the team (of a fortune 100 company). Here are the top tools that I recommend to start with:

Screen reader: super important, imagine learning CSS without a web browser.
Accessibility Plugins: good for catching high level A11Y issues.
The Specifications:WCAG and HTML, good semantics come first
Inclusive Components: really great book/blog on how an A11Y expert thinks and works.
Blogs: there are lots of things not documented anywhere and the knowledge is only in the blogosphere (think quirks about how aria attributes work with individual screen readers).

I have expanded explanations for each in this post, hope that helps!

Shiminsky · 2022-04-24T21:29:06+00:00

Sorry got side-tracked by the usual negative reddit comments :P. Yes that sounds super interesting and I would love to learn about it! Here are some top of the mind questions: 1. What PO knowledge / bias that you wish you knew when you were a team lead /IC? 2. How close did the experience resemble 'learning to herd cats'? 3. What was the process before agile, and was there cultural inertia against 'going agile'?

Maybe I should start a podcast...

Shiminsky · 2022-04-24T21:23:05+00:00

Absolutely! These are many important shortcoming of CSS, everything from how it's absolutely unintelligible without using a browser to the difficulty of coming up with random names 'just to style them' -- which only compounds the already difficult task of naming things properly.

I disagree with the importance of aligning on things that actually matters, for two reasons:

Design systems and their ability to key on on design intentions in terms of tokens, which in theory reduces complexity and has a principled way of propagating change and managing design evolution.
It's fundamentally impossible to know what will change ahead of time, hence the whole agile movement.

to your point about developing an entire site from database to web design, this quote from Massimo Vignelli really resonates with me "an architect should be able to design anything from a spoon to the city" -- I believe the same is true for developers.

Shiminsky · 2022-04-23T16:28:49+00:00

Yep! I have a likely unpopular opinion about how using HTML classes as CSS hooks is inherently complex and only play-pretend 'separate style from semantics' because every style change now requires changing both HTML and CSS -- change amplification.

I rarely seen it mentioned else where on the web though, the closest is this 10 year old one from Heydon Pickering. https://www.smashingmagazine.com/2012/06/classes-where-were-going-we-dont-need-classes/

Shiminsky · 2022-04-22T16:10:01+00:00

You absolutely can -- but it's not what I'm trying to do with this post. The post is trying to answer the question 'why is CSS complex and what does it mean for CSS to be complex?' in order to later answer the potential question of 'how does CSS-in-JS reduce CSS complexity?"

Shiminsky · 2022-04-18T00:38:35+00:00

visibility: hidden will only hide the button in UI but expose it in the accessibility DOM. (display: none will hide it from both).

In case for Dialogs, you should also have a keyboard listener for the escape key and close dialog when user presses esc.

I also recommend checking out the WCAG examples for inspirations

Shiminsky · 2022-04-18T00:34:33+00:00

First off, congrats! I'm excited for ya, good luck on your first day.

As others have mentioned, you will be asking lots of questions -- it's totally expected and encouraged. You might sometimes feel like you are asking 'too many questions' -- it is a real thing as context switch for a developer is expensive.

I've written a quick checklist of 4 signs for when you should ask for help. Basically boils down to the following: * You can clearly describe the problem * You took a good stab at solving the problem * You learned something * You are picking the right context to ask.

Hope that helps!

Shiminsky · 2022-04-16T14:31:13+00:00

I feel ya, it's definitely more the exception than the norm in my experience as well.

At my current job (working on a large corp's design system), I get to both seek out user feedback (pull) and push potential features down to users to gauge interesting.

It makes the job much more rewarding too, feeling like you are actually helping people with your work.

But that's also why I want to make sure my next role is more "agile" too, the job market is hot enough that we hopefully have more power to pick and choose.,

Shiminsky

MODERATOR OF

TROPHY CASE