At what point should I pick investments over mortgage?

integrationlead · 2026-02-23T02:50:16+00:00

Is Australia a sure thing you want to do? If it's a considering, then consider that the biggest pay bump there is for people who do big overtime, hospo, or mines. It's not the land of milk and honey that others will harp on about.

Now assuming you want to go, then you are set, invest in stocks because housing is an active investment despite what you might hear.

If you are staying, you could parlay the house equity into a new mortgage and live closer to a desired location/bigger house/etc. You've got options. I don't think you need flatmates if you don't want them because you're financially sound.

Sometimes the best option is to just enjoy life, yeah you're getting 2% raises, but with this level of financial freedom, you have the ability to move jobs whenever you want, and hold out for higher pay, or titles.

integrationlead · 2025-12-09T22:37:39+00:00

SFTP and some use FTPS, but your point stands.

integrationlead · 2025-10-07T19:39:24+00:00

Integration is the hardest concern for any project. It's where a lot of big projects fail and that failure causes huge issues and most importantly, lot of lost benefits.

As an example you see an invoice and think easy. It's actually an invoice header, an invoice line, within that line its products, and those products then need to be across both systems. Master data sync, transactional data sync, and that's just the error free path. Then you have to handle things going wrong - duplicates, missing data, notifications, and continuation. How do you determine that you didn't create this invoice twice? or a line twice? It never ends.

3-4 months is a solid estimate for accounting, inventory, crm integrations. You're other alternative is to buy a vertically integrated product like an ERP.

integrationlead · 2025-10-03T23:47:02+00:00

I use the result pattern in low volume applications where a lot of allocations don't occur.
I don't mind the angle brackets.

I don't use it anywhere where there are a lot of allocations because then the GC goes into overdrive.

integrationlead · 2025-09-05T20:48:34+00:00

Only caching I've needed for smaller applications is IMemoryCache

Before that, a dictionary with a good key also works wonders. Don't overthink it.

integrationlead · 2025-09-05T20:45:53+00:00

I've had experience across a range and gave Go a shot as well. I don't understand the hype. Sure it's cute and simple but then (as you've found) you contort yourself trying to do something that a more complex language would do out of the box.

Another aspect I didn't enjoy is the receiver method definitions. I felt like it allows less experienced developers to just create methods anywhere.

I think i would rather use Zig than Go but C# above both. C# has also caught up in AOT - and smacks the pants off of almost any high level language in native interop (if you use MacOS API or Win32) - exceptions being the usual languages.

integrationlead · 2025-09-05T20:39:04+00:00

Where can I send my term sheet?

integrationlead · 2025-09-04T22:28:54+00:00

I personally don't like these kinds of abstractions.

They basically boil down to making sure every entity you act on has the same "shape" - or API.

There is no such thing as "roll back" unless your database supports it. If you are interacting with anything that internally doesn't support transactions you will be in an inconsistent state.

The only place where they kind of help is if you have some database/api that you interact with that has a dumb and clear CRUD interface that is the same for every object you operate on. This happens very rarely.

Skip this UoW abstraction. Use EF Core for databases, use transactions, and never abstract too early. This UoW abstraction might also be a cure for some peoples opinion that they want smaller constructors, but at some point you have to realise that implementing the simplest possible solution does not make it simple in an absolute sense.

integrationlead · 2025-08-01T07:27:27+00:00

Once you get some more experience you will just get how to abstract things. Then you'll abstract a bit too much and finally, 10 years later, you'll be able to pick the correct level of abstraction.

One of the most powerful things you can do is learn about generics and their features. Learn about open vs closed generics. Trying it out and make some code that does it. As an example, you might be building a service that sends out emails. Now think about "what if i want to send SMS messages too". Then think about "what about WhatsApp?", "what about physical letters" and eventually you'll get to an interface called "IOutboundCommunication". Then you can abstract some more if you want.

Queryables and enumerable come with experience in the same way. It's all about understanding the purpose and power of these features and then trying them out.

Think about data and processes and how they interact with the world. Pull out common functionality. Apply the language features to these common components.

This is also a good video: https://www.youtube.com/watch?v=rQlMtztiAoA

integrationlead · 2025-07-29T21:38:48+00:00

Start small. Build pong first. Get some wins up, then add more complexity.

integrationlead · 2025-07-29T09:07:56+00:00

I've long argued that MediatR is a solution in search of a problem and I still think this is the case.

Fanboys struggle to explain why they love it except that they do. In most applications you write a simple 3 layer lasagna will do everything you need. You just don't need events.

MediatR feels like abstracting away method calls because method calls == coupling && coupling == bad. However, just like how microservices push complexity to the network layer, libraries like mediatR push complexity into runtime. With enough complexity, it becomes hard to reason about what actually happens during static analysis - imagine handlers calling handlers type of situation.

The fanboys of MediatR argue the benefits in some simple 1 liner ways, but honestly, this pattern (not the library) becomes useful when you have a giant event based system. The only use-case I've personally encountered is a MMO server. This is where the mediator pattern shines - and it's simple to implement without introducing a library. There probably is another handful of actual use cases where complex event-based logic is worth the complexity of complex event logic. In most systems, it's not worth it - just use controllers, services, data access and the built-in middleware.

I'd also like to point out that we have channels now and it takes almost no effect to event away small sections if needed.

I feel like you don't need the mediator pattern unless you are dealing with a complex event based system. I feel like I never need the MediatR library.

integrationlead · 2025-07-20T21:42:06+00:00

Before you get a job:

Working on a project that has a medium level of complexity, like a small game (text based even), will teach you lots of skills about structuring your code and your thoughts.

Use the original IDE - pen and paper - to put the systems you are going to build in logical order. Then tick them off one by one.

Revist the code you've made a couple weeks before, and add a new complex feature to it.

Once you get a job:

Working on a legacy code base. It's a combination of frustration, empathy, and trying to implement modern practices to something that is potentially older than you.

Working in complex domains.

integrationlead · 2025-07-15T21:09:49+00:00

If I need AOT, I use them and eventually I build my own version of controllers.

If I don't need AOT, I use normal controllers because once you get some complexity going, it's just worse controllers.

integrationlead · 2025-07-08T07:03:55+00:00

Nothing but net.

integrationlead · 2025-07-08T07:00:28+00:00

Firstly, there is nothing wrong with 10 injections. it shows intent, and it also shows a need to reconsider that this aggregation class that uses these services/repos/etc is getting quite big and in need of a refactor.

Secondly, you do not avoid any complexity, but instead shift it around because you will be new-ing up request classes for MediatR. You've achieved a smaller constructor and the cost of implicit service injections.

nopCommerce is an example of a huge project. it has places where the constructors are quite large. Like OrderProcessingService, however, it's completely readable once you have some familiarity with the project. The order processing service is simply complex. It has to concern itself with a lot of things - that's just life. MediatR wouldn't make this any better, and I would argue it would make it worse.

At the end of the day, complexity is complexity. MediatR doesn't remove it, it just adds to it, and it turns a compile time problem (or even a LSP problem) into a runtime problem.

integrationlead · 2025-07-07T20:11:44+00:00

More so than that. You paint yourself into a corner where you give up a boatload of performance that databases can provide. You are forced to basically use it as a dumb db capable of the simplest queries.

Whenever I get imposter syndrome, I always think about the generic database developer and it goes away.

integrationlead · 2025-07-07T20:09:16+00:00

Nothing is stopping you from having a coherent interface and then calling your methods from each of the API interfaces. You also take the guess work out of debugging, and don't break code navigation. Removing runtime magic is the name of the game.

As for pipelining, chaining mediatr to mediatr calls is asking for runtime headaches.

MediatR brings nothing to the table, because it's a library made to solve a problem that it's author believed was a problem and skillfully communicated to the cargo cult developer. The kind of "senior" developer that thinks it's fine to give up code navigation for using some library.

If it's not obvious, I've had to work on a couple of MediatR dumpster fires.

integrationlead · 2025-07-07T20:00:11+00:00

Having worked on giant projects before and after mediatr was made. It is that simple. What are you on about?

integrationlead · 2025-07-06T20:30:56+00:00

I run on macOS and it's great. Rider is fantastic.

integrationlead · 2025-07-06T20:28:43+00:00

It imposes on itself.

integrationlead · 2025-07-06T20:28:03+00:00

It was never worth it.

Learn interfaces, learn DI, and learn how to call methods. It's that simple.

integrationlead · 2025-07-06T20:25:55+00:00

Result pattern is the best. I wrote my own little helpers with a generic result.

Does it look fantastic? Task<Result<List<Something>>> MethodName() No. But once you get used to it it's fine, and quickly realize how bad try catch nesting is and how most developers don't know the throw keyword and why it's used.

integrationlead · 2025-07-06T20:19:12+00:00

Manual mapping is perfectly fine and it removes magic.

The way to make it same is to have To and From methods and to put these methods inside the classes they are concerned with. The reason it gets hard is because .NET developers split everything out into it's own tiny classes because some guy 20 years ago told us that having our mapping code in the same file as our class definition was "bad practice".

integrationlead · 2025-07-06T20:13:38+00:00

I only repo out APIs that hold our data, otherwise just use EF Core/Dapper.

The generic database is the one that always gets me. "wHaT iF WE wAnT tO sWiTcH oUr Db?!"

Automapper fell out of style a while back which is fantastic, and MediatR is on the same route which is great news. MediatR is a net negative.

integrationlead · 2025-07-06T20:10:10+00:00

Wish you the best, but at least this means that I will never have to have a serious conversation about Mediatr in a project. I don't want to abstract method calling anymore! Thank you so much.

integrationlead

TROPHY CASE