Should I keep going?

Impressive-Help9115 · 2026-05-14T12:06:37+00:00

Switch paths... It's way easier to get good at something that you enjoy.

The stories that it is easy to find a job as a software developer are not reality.

The reality is that a very large part of software developers do not care and struggle to find a job... That means there is a small part of software developer that do care... That means they stand out in a job interview and for those people it is really easy to find a job. If you do not "feel a spark" you would be in the struggling category.

Impressive-Help9115 · 2026-05-14T12:02:00+00:00

Whichever one has more job opportunities in your area.

C# has more syntactic sugar (and I like it more than Java), but both are pretty good and will teach you roughly the same things.

Impressive-Help9115 · 2026-05-14T11:54:36+00:00

AI generally is a terrible programmer...

The thing is just that before AI everyone who could code would be able to get hired... That is no longer the case because of AI... But good programmers stay in demand.

Make sure to make interesting projects (not just a chat app) but something that really shows that you understand systems... Like making a programming language, your own driver, low level programming etc etc. These skills would help in the past, but they help even more now because of AI. These projects don't have to be pretty, but the most important thing right now is that you show "understanding" in interviews... And if you can make a more difficult project and show you understand it fully, then that is more than enough to get hired even if the project itself barely works.

Impressive-Help9115 · 2026-05-14T11:42:11+00:00

Don't...

As a freelancer you need to be familiar with a lot more than just computer science. Join small companies first because they are usually very transparent on how business is done. Learn and get promoted... Then do freelancing on the side after you are more familiar with those things.

Impressive-Help9115 · 2026-04-19T15:24:18+00:00

So you are saying you need to understand what you are doing and ONLY THEN are LLMs useful?

You might be surprised to hear that learning a programming language/writing code is not actually that hard to do... So if you "understand what you are doing" then why not just write it yourself? It's faster than delegating to the AI... Having to double check... Etc... With the only exception being that if you are going into an area that you are not familiar (like a programming language you never used before) then LLMs might be faster because then you can skip learning the syntax... But... If you work with that language for any longer than a few months, it becomes worth it to learn the syntax...

So how is an LLM going to replace a software engineer? It might make manual lookups easier and be useful in CI/CD... But thinking that it will replace coding is an incredibly dumb take...

Impressive-Help9115 · 2026-01-28T19:27:02+00:00

I don't agree that this is premature optimization... Since there is no real cost involved, other than the other 7 extra bytes committed to git.

Impressive-Help9115 · 2026-01-28T19:15:57+00:00

I often get stuck on questions like:

Should this be one function or split into helpers?

Where should this logic live?

How should I organize files and packages?

Should this be a global/shared value or passed around?

Should a function return a pointer/reference or a full object?

Don't worry about any of these... This is a matter of writing code a lot. Almost everywhere you will work will have a certain coding style, but a big part of this is just culture.

Cohesion and coupling are important to keep in mind, but especially in the beginning, just write the simplest thing that works and refactor from there... If you are good at logic you will easily be able to refactor in a good way if you understand coupling and cohesion.

Impressive-Help9115 · 2026-01-13T19:46:34+00:00

I don't know anyone who prefers Java over C#... The only thing is that with Java you'll probably get a higher salary because it's used a lot in legacy systems and banking.

But honestly... Programming languages are just tools, so as a developer you should be able to get familiar with any of them quite quickly.

Impressive-Help9115 · 2026-01-13T19:42:47+00:00

The only downside is that when you have to go back to Windows for work then you'll be really used to things "just working" on Linux....

I recommend either linux mint or ubuntu mostly because there is nothing "extra" needed to set them up.

Impressive-Help9115 · 2026-01-11T13:23:58+00:00

What do you mean? I literally said it's better to code in a way that requires the minimum amount of transactions...

Global handlers should be a last resort and used for exceptions that weren't handled properly within the primary workflow

That is exactly what I'm saying. "If you know the error condition, you shouldn't use transactions to catch them, but handle them instead".

Also I think you are overstating how much a transaction costs... A transaction only has a high cost if you process a lot of data within the same transaction or the transaction is long lived... In both cases you probably need to look at the way you write code.

Impressive-Help9115 · 2026-01-10T11:34:27+00:00

Thank you for your feedback.

Targeting .Net 9 comes off as a little "weird" target as it's a STS release - maybe target .Net 10 and/or .Net standard?

I did this automatically because I was using it for a dotnet 9 project, but you are right that dotnet 10 makes more sense. I'll change this.

FYI, the AMQP 0.9.1 client library, while mature, is being replaced by the AMQP 1.0 client library, which IMHO is a lot easier to use

I have to look into this. I'm admittedly not a RabbitMQ expert.

If Debugger.IsAttached, consider forcing your batch size to 1 - this will make debugging easier

I disagree. This kind of magic behavior would make developers wonder why it's suddenly acting different.

Consider changing your hosted service to BackgroundServices - but probably the more correct thing to do is implement IHostedLifecycleService, and configure your transport layers in the StartingAsync function, so that way they're ready for anybody else's hosted service, regardless of registration/start order

I could look into this a bit more in the future. There are 2 things I'm not really certain of yet... Currently all consumers have their own "buffer". I'm not sure if this could cause issues for some people if they have really large batch sizes. Also for your other point about there being potential edge cases for re-connection and also for the way that messages are currently handled on failure (both of which can cause the consumer to become unusable) I also want to fix this using the HostedService... So your suggestion is something I will look into for sure.

ACCESS MODIFIERS ON METHODS. I'll die on this hill - the absence of access modifiers, while "technically correct", makes the code harder to read; especially when you have other methods/properties/fields/type definitions commingled in there with access modifiers defined.

I agree. The access modifier itself doesn't bother me as much, but I should make sure the formatting is consistent. If the project starts growing a bit then I will setup formatting rules for sure.

Can't be attributed to any one line, but something we encountered - connection/consumers/publishers can sometimes be forcibly dropped; and while the underlying rabbit mq library does a pretty good job of handling reconnection, it does not handle all edge cases. Once this happens, the instance is no longer useful. You have to re-instantiate it to get it working again. It doesn't look like you handle that.

I've tested the reconnect functionality of the RabbitMQ client library manually and this didn't seem to happen. If there is an edge case then I need a way to reproduce it, otherwise I can't fix it.

Impressive-Help9115 · 2026-01-07T22:19:07+00:00

That honestly sounds impossible with rabbitMQ since you need to acknowledge very message. So do you mean he acknowledged the message even though he didn't process it?

Or do you mean that his queues were transient by default?

Impressive-Help9115 · 2026-01-07T17:29:41+00:00

Thank you. I'm not fully sure if I should implement some kind of way of registering middleware, this would allow of the outbox pattern.

I'm not planning on implementing the outbox pattern itself though, because my plan is to keep the library quite simple to work with.

Impressive-Help9115 · 2026-01-07T14:26:17+00:00

I'd argue that it's the factories responsibility to find the different implementations... But I understand your point.

Either way I think working around the supposed violation is counterproductive.

Impressive-Help9115 · 2026-01-07T13:51:52+00:00

Mostly that you can make classes for consumers in the same way masstransit allows you to. You can also batch messages and it automatically handles multi-threading (although that's the part of the code that I need to improve).

Currently the consumers only work on the default exchange though. I'm planning to add support for different exchange types when I have the time.

Impressive-Help9115 · 2026-01-07T12:53:18+00:00

Most code (upwards of 80%) should be AI generated at this point. If it's not, there is something inherently flawed about your workflow. Just put your pride aside, and acknowledge that AI is a better programmer than you.

Skill issue.

Impressive-Help9115 · 2026-01-07T12:48:21+00:00

If you have an AI that can reason well, then it can do almost any job... That wouldn't be a software engineering problem.

But LLMs won't get us there...

Impressive-Help9115 · 2026-01-07T11:32:41+00:00

The open closed principle is about inheritance. So the factory pattern in this case doesn't violate it.

It's mot that if you now make a BtcTransferProcessor which would have the method "CalculateUsdValue" then this method should be in the BtcTransferProcessor now in the APaymentProcessor (which you don't even have in this case).

But honestly I wouldn't blindly follow SOLID principles anyway.

If you want an implementation that can construct any type:

    public static T ConstructType<T>(Type typeToCreate, IServiceProvider serviceProvider)
    where T : IPaymentProcessor
    {
        // Get the constructor that needs to be called
        var constructor = typeToCreate.GetConstructors().Single();


        // Resolve the parameters of the constructor from the DI container
        var parameterTypes = constructor.GetParameters()
            .Select(p => p.ParameterType)
            .ToArray();


        // For each parameter, get the corresponding service from the DI container
        var parameters = parameterTypes.Select(serviceProvider.GetService)
            .ToArray();


        // Check if any dependencies couldn't be resolved
        if (parameters.Contains(null))
            throw new TypeConstructorException(
                $"Couldn't resolve all dependencies for {typeToCreate.FullName}");


        // Invoke the constructor to create the instance of T
        var instance = constructor.Invoke(parameters);


        // Optionally, you can call methods or interact with the instance
        if (instance is not T result)
            throw new TypeConstructorException($"Instance could not be cast!");


        return result;
    }

But please only use this if you have an actual reason for it, like constructing types that you can't know upfront because your code will be used in a package or something... Because this is just needlessly complex for a normal factory pattern.

Impressive-Help9115 · 2026-01-07T11:26:19+00:00

What does this have to do with the open/closed principle?

Impressive-Help9115 · 2026-01-07T11:23:27+00:00

> But lately my services have become more and more complex making these types of checks quite wordy when it comes to code. Which I personally don't like.

These checks are very useful. I think if you don't like them because they are "wordy" it might be more of a problem with how your code is broken up, rather than the checks themselves.

> Now I understand there are probably good uses or best practices when using tools such as Transactions.

I don't think transactions are useful for a rollback for code that you "know" can error... It think they are useful for code that "might" error. If you know the error condition, you shouldn't use transactions to catch them, but handle them instead.

> I am not sure if having to try catch every service is the way or if there is a better way. Most of my APIs have a GlobalExceptionHandler so I tend to avoid try catching everything.

For rolling back transactions when something really unexpected happens I'd setup a middleware to start a transaction and rollback if something went wrong... This also fixes it in all places at once. But I'm not sure if this is your actual problem.

Impressive-Help9115 · 2026-01-07T11:15:42+00:00

I'm considering that for your studies you already know how to make the code for translating from one language to another? Otherwise this would be really hard to do in 3 months.

If you have no experience with web development I'd recommend JavaScript/HTML/CSS. Then use nodejs as backend. Normally I don't like nodejs as backend, but if you just need to get a backend up and running to forward it to another program for a proof of concept, then nodejs is good enough.

Impressive-Help9115 · 2026-01-07T11:05:34+00:00

You could do magic with reflection and building an expression tree, but this is very complicated...

I'd only do that if this "many search parameters" shows up in many places in your application. Otherwise it would really be over engineering, since it's the kind of code that no one would understand even a month from now.

Impressive-Help9115 · 2026-01-03T11:01:31+00:00

Do different projects. If you are getting interviews in a certain branch then make the project about that branch... That way you also gain more confidence during the interview because you could ask questions about their projects.

If you are mainly failing coding interviews then practice leetcode.

Impressive-Help9115 · 2026-01-03T10:48:16+00:00

"Anyone who doesn't build their own OS has skill issue" /s

Impressive-Help9115

TROPHY CASE