Interesting discussions with some folks on my team who don't like TS. I've went back and forth in my head on "loose" ts that allows any and escape hatches. I think I am personally a purist who likes it strict, but I would argue that "loose" ts is still better than no ts at all.
Bluesky has gotten overrun by politics. I really just want to subscribe to programmers and programming, and now those programming posts are like a needle in a haystack.
AI is still failing to impress me all that much for coding. Its increased my productivity by a little, but its still wrong or at least really bad most of the time, and just distracts from doing things right. Its been really awesome for brainstorming sessions though.
If you have a code nit, you should have a solid reasoning for it that goes beyond "I like it better this way" - think deeper, analyze the tradeoffs, and make a compelling argument for every coding decisions you make.
eslint rules are great for this!
One thing that sets SW engineers apart is attention to naming and an attempt to be proper about semantics. Try not to name your business variables which are referring to business logic entities with well known technical terms.
➡️ January 20: FAA director fired
➡️ January 21: Air Traffic Controller hiring frozen
➡️ January 22: Aviation Safety Advisory Committee disbanded
➡️ January 28: Buyout/retirement demand sent to existing employees
➡️ January 29: First American mid-air collision in 16 years
Making America Great Again!
Yellowstone is just redneck Succession
Every year I tell myself I am going to make some products and every year I spend all that time coding the perfect tech stack to launch a product without ever launching a product. But this year!....
Why is over-engineering the default for many orgs? So much out of the box functionality gets re-written with definitively worse bespoke solutions and its somehow gets sanctioned by the entire team and managers. Arguing "we really don't need that microservice" is a losing battle.
In my opinion, the best code is easyish to read and can be understood by reading a file top down, left to right, just like words in a book. The more functions that get called from other places, the more I have to switch focus to read it. DRY is overrated in many situations.
It's so frustrating to see the org I am working with constantly making poor technical decisions and to not have the power to influence them in any substantial way.
Just binged "Chainsaw Man" as my first new anime of 2025 and it was excellent. Hope they come out with more soon!
This year - I am going all in on building with @adonisjs.com. I have been pecking on my custom koajs based framework for years and it's lacking so many features still, that I haven't really built anything substantial with it. Going to switch my focus to a much more mature full stack framework!
Wheat thins are the perfect cracker
I truly enjoy code/work and spend a good bit more than 40/week working. I try to check in often with myself and ask myself how this affects my personal life.
If I am feeling stress about my work when I am not directly doing it, then I know I have taken things too far and need to step back.
My current understanding is that If you are using node19 or higher, you shouldn't need userland packages like http-terminator anymore.
Would love more clarity on this though.
I'd like to attempt a guide on this, but I am sure to get parts of it wrong.
TL;DR:
server.close is good enough most of the time and since node 19 is automatically closes idle keep alive connections.
server.closeAllConnections when you have very chatty keep-alive connections?
Closing a server and all its socket connections correctly in node.js is confusing.
Server.close
Server.closeIdleConnections
Server.closeAllConnections
When to use them vs packages like stoppable or http-terminator.
It's not 1 size fits all and its terribly documented everywhere.
I love ts-expect-error comments. They are invaluable for progressive TS enhancement. They will alert you when they are ready to be removed because your types get better and therefore are way less risky for being a cause of tech debt. ts-ignore comments OTOH have a habit of never getting cleaned up.
Does the LSP spec meet your needs?
microsoft.github.io/language-ser...
microsoft.github.io/language-ser...
Not sure if that is specific enough, but it would certainly help encourage editor plugin adoption if your linter results could be directly sent to the client without manipulation.
Sometimes TS adoption is difficult because some popular patterns that are great with JS are not so great with TS. It would be nice to have an educational resource that shows common pattern and mindset switches needed when learning #TypeScript as a JS dev.
It's no wonder code bases entropy fast at large orgs, the red tape is like a punishment for those who try to make changes. Even if the changes make a lot of sense and are non disruptive.
Every time I time I try to really improve something at work, it's always associated with a lot of scrutiny and with it, a lot of stress and anxiety. OTOH, when I spend a lot of time just knocking out tasks and bugs I get very bored and unmotivated.
I don't hear Bear get mentioned all that much when I read about note taking apps, but it's been a core part of my life and work for years now and its simplicity, awesome UI, and quick syncing across ios and mac have consistently met all my needs.
bear.app
Setting up ESLint for your project can be tedious.
That's why I love XO. ❤️
It's and opinionated but configurable ESLint wrapper.
github.com/xojs/xo
- zero-config
- batteries 🔋 included
- uses 🦄 unicorn
- full TypeScript support
- IDE extension
- no more code style discussions in the team
xo flat config coming soon!
- Use ESLint directly with xo as a config (good for some teams)
- Built in xo cli and editor extensions still available
- Make xo much more configurable/extendable for other uses, such as linting markdown, package.json etc
Thanks for using!
I prefer the strictest possible TS settings with type-aware linting whenever I have control of it. However, I often find TS projects being loosely typed with a lot of strict settings turned off. These projects make me assume I have type safe guardrails when I really don't. Danger.
How do you feel about the tidelift.com model of OSS funding?
It seems promising to me, but I have no idea what an OSS dev could expect by working with them and I am not sure if they have any focus on dev tooling.
One of the most difficult things about SW engineering to me is knowing when to:
- go with conventions even when you disagree with them
- push back against bad conventions
- do both of the above with tact and empathy
Someday, the irrational rage I feel when anyone comments on my PR's is going to get me in trouble. Do you people not even realize how hard I had to prompt AI to get this feature to work?