HN user

jwaldrip

69 karma

[ my public key: https://keybase.io/jwaldrip; my proof: https://keybase.io/jwaldrip/sigs/kM1Q8gxhpCx8hWOi97gJ_4G7I5L-AxdmhImathT8II8 ]

Posts12
Comments30
View on HN
LLMs Are Not Fun 7 months ago

Typing is not fun. It robs me of my craft of holding my pencil and feeling it press against the paper with my hand... LLMs are merely a tool to achieve a similar end result. The different aspects of software development are an art. But even with LLMS, I critique and care about the code just as much as if I were writing it line by line myself. I have had more FUN being able to get all of my ideas on paper with LLMs than I have had over years of banging my head against a keyboard going down the rabbit hole on production bugs.

On OpenAPI vs GraphQL: I disagree with the premise that OpenAPI achieves the same thing. GraphQL is necessarily tightly coupled to your backend — you can't design a schema that does something other than what's actually implemented. OpenAPI, on the other hand... I've seen countless implementors get it wrong. Specs drift from reality, documentation lies, and you're trusting convention. Sure, OpenAPI can do whatever you want, but for those of us who prefer convention over configuration, GraphQL's enforced contract is the whole point. On authentication concerns: Yes, auth in GraphQL has varied implementations with no open standard. But REST doesn't thrive here either... it's all bespoke. This is a tooling problem, not a GraphQL problem. Resolvers become your authorization boundary the same way endpoints with controller actions do in REST. Different shape, same responsibility. On type generation: In my experience, the codegen tooling with Apollo and Relay is incredible. I haven't seen anything on the OpenAPI side that comes close to that developer experience.

Hey HN – I built Han, a curated marketplace of Claude Code plugins that actually enforces code quality instead of just suggesting it.

The problem: developers constantly ship broken code because tools warn but don't block. Linters flag issues, but you can ignore them. Tests fail after pushing, not before.

Han solves this by running validation hooks at Claude Code "Stop" events – when you or a subagent finish working. If types fail, tests break, or linting errors exist, you can't continue until they're fixed.

Key features:

- 129 plugins covering 19+ languages, 30+ disciplines, 15+ testing frameworks - AI auto-detection – analyzes your codebase and recommends the right plugins - Smart caching – only runs checks when relevant files changed - Zero config – MCP servers like GitHub integration work out-of-the-box with `gh auth token` - Monorepo-friendly – automatically finds all applicable directories

The architecture separates techniques (jutsu – language/tool skills) from disciplines (dō – developer practices), reflecting that your identity as a frontend developer doesn't change when you switch from React to Vue.

Built with TypeScript, Ink (React for CLI), Commander.js, and the Claude Agent SDK. MIT licensed.

`npx @thebushidocollective/han plugin install --auto`

Happy to answer questions!

There are so many wrong things said in this post. First off, much of this is a comparison between react (not react-native) and flutter. React-native does not use webviews or a DOM. It uses similar paradigms to flutter, just written in dart rather than javascript.

All I am reading here is a complacency with the way this person was taught. I have no problem adapting to the new tech and welcome the abstraction. I trust the communities and maintainers of such abstractions to help me when the time arises.

Full Stack Engineer (Postgres, Ruby, Node.js, React.js) | Brandfolder (https://brandfolder.com) | Denver, CO | Full Time | ONSITE

http://jobs.brandfolder.com/

Brandfolder is a Digital Asset Management Platform Serving some of the largest brands in the world. We are a lean, mean, fast machine -- We have built an amazing process that allows our 4 person development team to out pace our competitors who have 40 person teams.

Requirements: * Experience working in a Modern OO Backend Language -- Ruby (preferred), Python, Java, etc. * Experience working in a Modern Front End Framework -- React.js (preferred), Ember.js, Angular.js, etc. * A passion for elegant user experiences and experience driven development. * A will to learn and become a better developer -- We use many technologies and expect all of developers to learn our entire stack, from ops to UX.

@recruiters: Do not contact us.

Dropping out or not finishing college may be acceptable in this industry, and there are many reasons why; Cost, pace of education vs self-teaching, etc. All that being said, the same does not apply to High School. I recommend at least getting your diploma or GED. It is unlikely that any tech company will overlook such an easily obtainable requirement. I don't think freelancing is a great solution either. If you want to become a good developer, at least work with a team for a few years that can teach you some things.

Regulating SOPA will prove to be more cost prohibitive than actually solving the real problem. The real problem is that people want to be able to get content on demand, and the problem is that media companies are unwilling to adopt new ways of delivering that content. The music industry was plagued by this same thing a decade ago, but allowing the online purchase of content either via subscription or purchase has significantly reduced music piracy. Adopting the same principals for movies and television shows across the board will undoubtably have the same effect. The fact of the matter is that until studios are willing to be more flexible with their means of distribution rather than trying to have full control, then piracy will continue to be a problem.

iTriageHealth - Denver, CO, USA

Looking for: Ruby Developers, JavaScript Developers, QA Managers

What we Do: iTriageHealth is a multi-platform application (iOS, Web, Android) focused on providing relevant healthcare knowledge and a patient to provider pathway. We are paving the way for bringing more technology and transparency to the worlds' currently opaque healthcare systems.

Culture: We are a strong team who fosters creativity and innovation. We are currently 40+ developers and growing of a 90+ person company. We are looking for passionate talented individuals.

We are competitive in Salary and have great benefits. Reach out to me for more information.

Jason Waldrip m: 646-460-5959 e: jwaldrip@itriagehealth.com

iTriage Health -- Denver, CO. Full-time | Ruby Developers, JS Developers & Node.js Developers.

Join us in creating mobile and web applications that empower consumers to make better health care decisions. We have a very talented tram and are looking for additional talent to join the team.

email: jwaldrip@itriagehealth.com

site: http://about.itriagehealth.com/careers/

Wow, its about time! Using Postgres full text search is okay, but I still prefer ElasticSearch. Hopefully, Mongo's implementation will circumvent the need to maintain both a persistence DB as well as a full text search engine. Looking forward to test driving it!