Timothy Haasdyk

This is the thing I struggled with when I was a junior: How to represent Table per Hierarchy inheritance in EF? Did you hear about the Discriminator column? Suppose you are building a transport management system for different types of vehicles, such as cars and bikes. These types share some properties (e.g., Id, Model), but they also have unique attributes (has NumberOfDoors, and Bike has HasGear). The Discriminator column allows you to handle this scenario more effectively. When you retrieve vehicles from the database, Entity Framework Core will use the Discriminator column to instantiate the correct type (Car or Bike), enabling you to handle them polymorphically. Similarly, when you save a Car or Bike to the database, Entity Framework Core automatically assigns the correct Discriminator value. Learn more: https://lnkd.in/drVrmMYn

501

46 Kommentare

How can you ensure that your backend API in #Node and #TypeScript remains easy to maintain, flexible to change without breaking the entire system, and scalable to the moon?  Of course, there’s no universal solution (if someone tries to sell you one, they’re lying). However, you can apply several #techniques, #design #patterns, and general #programming #principles to make your life easier.  Today, I’ve updated an article about crafting SOLID APIs that are not over-engineered, leveraging function composition—a fundamental concept in functional programming, combined with declarative code.  OOP is great, but in my opinion, in stateless ecosystems (like microservices), it doesn’t always provide the flexibility one might expect. Functional programming, on the other hand, focuses on getting things done rather than abstracting everything into classes.  Don't get me wrong—OOP is cool. It has its pros and cons, just like functional programming. But OOP truly shines in areas like game development or other highly interactive systems.  Personally, I use a functional programming approach in my backend APIs about 80% of the time, switching to OOP or other paradigms when needed (a percentage pulled from no official data institute 😆).  In the article, I dive deeper into this perspective, explaining why I favor this approach. I also share additional techniques for building fast, concise, and maintainable APIs using Node.js, TypeScript, and cloud environments (e.g., Google Cloud).  My focus is on low coupling, minimal code, and reusability—primarily achieved through simple dependency injection (just passing arguments, nothing fancy). Before you dive into the article: the approaches presented here apply to any cloud platform and will also work in an on-premise environment. I’m abstracting away infrastructure details, making them easy to replace later—all of this is covered in the article. You can check it out here: https://lnkd.in/gPruA8yr  PS: Please don’t nitpick my words! 😜 I'm not against OOP—I'm just saying that for stateless APIs, it often introduces unnecessary complexity that function composition can help avoid.

74

5 Kommentare

A few years ago, one of our juniors left a PR comment on my code that said: “Why is this retry logic needed? Isn’t the upstream service already doing retries?” At first, I smiled. Then I double-checked. And guess what? He was right. The retries were already happening upstream. My retry block was adding noise and doubling the latency on failure. So I removed it. But more importantly, I told him in front of the team that he saved us from a slow bug that could’ve hit prod under load. That’s the thing about juniors: If you only treat them as learners, you’ll miss what they can teach. Let them comment. Let them question. Let them review your code. Not just the “easy” tickets or the tests. The real logic. The stuff that matters. Because when juniors feel safe to challenge things, They learn faster. You get sharper. And the whole team levels up. "Your title doesn’t make your questions less valid. Your experience doesn’t make your code unquestionable."

2.466

64 Kommentare

If you've enjoyed using all the new functional programming features in the latest versions of C#, why not investigate what F# - A language for .NET, built from the ground up to be functional - can offer? An easy way to get started is to download my free 200-page e-book Essential F# from https://lnkd.in/dT3FJ_Yd. #dotnet #csharp #fsharp

87

13 Kommentare

"Two front-end developers are sitting at a bar. They have nothing to talk about." I first heard this quote from Chris Coyier in 2019 - but it feels even more relevant today. The idea is that that front-end has grown to cover so many different areas that it's *really hard* to be an expert at all of it. Some might be great at HTML/CSS and working closely with designers to implement slick designs and interactions. Others might be entirely focused on mastering a modern JS framework + metaframework to handle data fetching and building an architecturally sound front-end application. These are all important skills, but mastering everything is simply too much to ask of most front-end developers (especially juniors). That's why I think it's important to realize what you most enjoy working with, and then doubling down on that part. Of course it's great to have an understanding of both "ends" of the front-end. But to really excel your career, you probably have to narrow your focus ✌

932

100 Kommentare

Don’t undersell the value of your legacy knowledge. I speak to a lot of .NET engineers who play down their experience with older frameworks or systems. But really… legacy knowledge is often what keeps critical systems running. Clients still rely on it. Teams still need it. And pairing that experience with modern skills makes you stand out even more. If you’ve spent years fixing, maintaining, and improving legacy platforms, you’ve built resilience, problem-solving skills, and real-world impact. That’s value. Don’t hide it.

46

Every now and then, I collect programming quotes I like into blog posts. Here are some from the sixth installment: “Configuration is coding in a poorly designed programming language without tests, version control, or documentation.” Gregor Hohpe “It’s the developers misunderstanding, not the expert knowledge, that gets released in production” @ziobrando And I think this is pretty funny: “What’s the difference between C and C++? 1” Unknown

29

10 Kommentare

How you can get some Async in PHP using Symfony HTTP Client or Guzzle: I published a video on a small refactoring on our own Tideways GmbH codebase to use parallel HTTP requests to reduce time spent talking to a microservice. https://lnkd.in/eAEsmtB7 #php #symfony

21

3 Kommentare

Most software projects do not fail because of bad code. They fail because of: Unclear requirements Slow communication Endless scope creep No one thinking about the actual users We have seen it too many times, so we built our dev process differently. At Septem Systems, we: Ask the right questions before we write a single line of code Stay lean, fast, and user first Treat your product like it is our own business If it is a startup MVP or scaling an enterprise platform, our goal is simple: ◾ Build clean and scalable software that actually solves the problem. If you are tired of missed deadlines, bloated codebases, or devs who don’t “get it”, let’s talk. We don’t just write code. We ship results 🙌

26

4 Kommentare

I've been writing the Dev Secrets newsletter for more than 1.5 years. I hand-picked the 7 best articles 👇 1. Where I host .NET apps in 2025 (top 5 picks) https://lnkd.in/dHjvd2vV 2. Throwing exceptions kills apps. Here's how to fix that. https://lnkd.in/dzdXXFnX 3. 2025 .NET Development roadmap [Minimalist Edition] https://lnkd.in/dvt8Baaa 4. 10 fatal mistakes .NET developers make https://lnkd.in/d2ebfrVk 5. Zero Azure cloud experience? Start here https://lnkd.in/d7483w3u 6. Choose your poison: EF Core or Repository Pattern? https://lnkd.in/djb7KyDd 7. 7 powerful LINQ methods you'll wish you knew sooner https://lnkd.in/dXKw278h Which article do you like the most?

27

5 Kommentare

Although 𝗳���𝗰𝘁𝗼𝗿𝗶𝗲𝘀 are nothing new for most developers, I am still rather pleased with how we've integrated them into our configuration! From a user perspective, you would not even notice them. You would simply ask the configuration: "Give me a component of this type and this name (please)." If the component is present, it will be returned right away. If it 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 exist, the configuration will ask the "component factories" to make one. When there's a factory capable of building the requested component, you will get a newly constructed instance! Which, of course, is registered with the configuration right away for future reference. Although not massively complex, it will significantly simplify several constructs from Axon Framework 4 for those moving to AF 5. For example, when you need a Command Bus for a specific context in AF4, you must create it yourself. The same holds for event stores and query buses, of course. That's just a cumbersome user experience to me, as it's a piece of cruft that: 1. Require you to recall how to build the component in question. 2. You need to be mindful to maintain the component's life cycle. Sure, it's doable (I have been there), but we can do all this for you so easily! Furthermore, I see it as a great stepping stone to simplify our multi-tenancy support! For multi-tenancy, you would typically want to separate the message streams for each tenant. Thus, you are required to make tenant-specific components. With component factories as an integral component of Axon Framework, it will become easier for us. And, for you! :-)

15

3 Kommentare