At least I hope it isn’t otherwise why bother writing this?
Most people probably think that when I say AI makes me a better programmer that it makes me more efficient. That I can get more done with less effort. And while that is also true, I find that AI has forced me to become a better programmer in ways that will continue to benefit me even if AI is just a fad and we all start writing code by hand tomorrow.
There is a lot of noise on the Internet regarding the use of AI tools in software development. Some say it’s the future, while others are skeptical about its effectiveness. As you’ll quickly ascertain from this article, I believe AI can be a powerful ally when used correctly.
While this article will focus on TypeScript development, many of the tips can be applied to other programming languages as well. So, don’t ignore this article just because you don’t use TypeScript. In my career, I’ve used everything from C/C++, Java, C#, JavaScript, TypeScript, Scala, and F# and I could apply each of these tips to any of those languages and associated frameworks.
Since TypeScript introduced Interfaces and Types, we’ve been getting lazy. It is so much easier to create an object that obeys an interface than it is to create a Class that obeys the same interface. But what have we lost in the process?
I was recently asked how I would optimize an Angular site for speed. Interestingly, I’ve never written about this explicitly even though I’ve done a lot of work related to this issue.
For the purposes of this article, I’m going to assume you have already implemented most of the things that Angular gives you “for free.” For example, we won’t discuss “Tree Shaking” or “AOT.” Those are given.
Here are my 30 or so tips on how to optimize an Angular application for speed.
Over the course of working on SmartNgRX, I’ve discovered a secret to making NgRX faster. A way that is so obvious now that I know about it, I’m surprised this isn’t the recommended way to use NgRX.
As most discoveries occur, I’m building on the backs of giants. In this case, I’m specifically building on the back of the increasingly popular NgRX facade pattern (done well) and a statement with regard to Angular Signals that says “Don’t use Signal Effects.”
There are, of course, other minor improvements but these are the top two catalysts for what I want to share with you today.
Imagine an NgRX world where you almost never knew you were using NgRX. A world where you never had to write a reducer, action, or effect. A world where you never had to call store.dispatch(). A world where the data you worked automatically persist to the server. A world where the data is retrieved from the server as it is needed and removed from memory when it is not, or never removed if that’s what you want. A world where the data automatically refreshes from the server, or you can use websocket messages to refresh the data and, in either case, the only data that refreshes is the data the code is actively using. A world where optimistic UI is built into the framework.
Last week, I announced a project I had been working on for over 10 months. I call it SmartNgRX and it solves many common issues most of us have using SmartNgRX, including the boilerplate issue, over-fetching, and memory pressure caused by stale data.
Today I want to talk about a few things I learned while creating SmartNgRX that can be applied globally to any project.
Sharing experiences with a friend has highlighted the complexities we all face in the workplace. Together, we’ve often speculated on how work life could unfold more smoothly. It’s a captivating dance we all do, navigating through life’s ever-changing rhythms.
I’ve cultivated a daily ritual—tiny reminders that influence my perspective and guide my daily interactions. These cues become the cornerstone of my morning, offering a touch-point for clarity. They may resonate with you or maybe not, and that’s perfectly fine. Feel free to create your own set of reminders that evolve over time. After all, our beliefs can always use a gentle reality check.
In the vibrant town of Bugville, known for its thrill,
There lived a brisk coder named Sam, climbing up a skill hill.
One day, he embarked on a project so grand,
To craft an entity, a creature named ClutterSand.
There are different opinions about whether or not to use return types in TypeScript. I respect that, but I would like to share why I think they are helpful.
First, let’s acknowledge the reasons why some people prefer not to use return types.