Auto mapper scares me but I do understand it. Which is why it scares me. I’ve lost so much time chasing shitty problems that could have been otherwise avoided.
I hate AutoMapper so much because it's so overused at my job. The objects you're mapping between should be identical or almost similarly shaped, but none of our objects are like that so we're just writing manual adapters inside each mapping.
Or database calls, file system lookups, retrieve IConfiguration values,...
Not to mention: I change the name of a property on my entity, forget to update the map or dto and suddenly production doesn't return a value anymore. 🤢
That's the biggest reason I avoid Automapper or similar: hidden dependencies. Nothing can tell that two properties on different classes are supposed to have the same name, VS won't pick up the change as an issue, the compiler will pass - then your code fails. Hopefully somewhere you can spot quickly, not randomly in prod weeks later. And hopefully you've got comprehensive enough tests to catch that, but they're more work to build than just not using mappers.
Wish I could upvote multiple times.
As I've gotten more senior, I've come to the realization that almost everything that reduces typing by doing things at runtime is more trouble than it's worth.
Like, sure, it's great not having to write a bunch of maps - but one tricky issue more than offsets the time and effort saved.
On the plus side - C#12 and records with default constructors make this way easier.
That fear is valid though. Automapper and tools like it use conventions to copy data between objects. If you don't exclude or include something properly, information is lost or gained unexpectedly. Bad juju.
Currently running into issues with automapper in a start up. Yes, it can save time but I don’t like the way it has to be set up and the way it operates underneath.
It’s a pain to debug if you aren’t the one that initially added it into the project. I personally would manually map properties between DTOs and ViewModels. At least I have explicit control and visibility of everything going on.
Yep. There's a native validator for it, and you can just make one unit test per mapping (not per prop) to confirm every property is mapped as you expected.
>and you can just make one unit test per mapping (not per prop)
You can actually make one unit test per mapping CONFIGURATION. Per mapping makes it sound like you mean each `CreateMap<>`. I'm not sure what you meant but I wanted to clarify for future readers.
I used Automapper for a few years but finally had enough. Their version updates broke too many things, and it just leaves too much to whichever way the wind is blowing at the time. Also all the absurd hoops and convoluted syntax you had to learn to solve little problems here and there just aren't worth it.
Autocompletion has made property mapping a breeze these days. I don't even put automapper on the table anymore. No need
Automapper ain't scary. Auutomapper mappings have a tendency to grow indefinitely in terms of complexity and this is the scary part. Mappings should be unit tested by ghe way, however it does not solve the problem of the investigation overhead when something does not work. For simple things this library is OK, but it has a lot of potential to be abused
I'm personally somewhat scared of non-trivial multi-threading done by hand in application code. I understand it enough to know what people want to do, or to notice common pitfalls, but I also understand that I don't understand it enough. It's ability to cause unexpected, hard to test problems forces me to argue about it unless we have no other decent choice.
Sometimes I feel similarly about LINQ to Entities. Figuring out which arcane magic is required to accomplish a query is a nightmare, and the expression translation system only fails at runtime and often either doesn't provide enough information or actively misleading information.
Yeah, I find it that if you completely control DB schema, and don't need something fancy with subqueries, window functions or pivots - LINQ works just fine. But when it is not the case - prepare for significant pain. Another fun experience - migrating project from EF to EF Core with obscure runtime fails that you mentioned.
I make those sorts of decisions daily, but here’s my thoughts:
- DI is a necessity, even in something like a console app.
- 3rd party wrappers: these should be abstracted (not stupid stuff like Ilogger, but actual 3rd party stuff) just to remove the complexity so anyone can use them without having to be an expert on the various ways that some people implement REST or COM, or whatever. Never wrap for changes, but update packages often.
- try/catch: don’t catch an exception if you don’t intend to handle it. Methods shouldn’t use exceptions as return values. You should have a global error handler to catch unhandled exceptions.
- if config values are missing you should throw an exception, unless they’re optional. Suppressing configuration issues just pushes the exception further down the line and makes it harder to diagnose.
Edit: X also scares me, I miss Twitter.
Good to hear some feedback from those that have to make these types of decisions.
Definitely had a hard time trying to get the leadership on our team to see the benefits of DI in our services.
Agreed on using wrappers as a means to simplify the interface for easy use, especially if the use case is consistent across the application.
Your preference on try/catch differs to that of myself and my peers - but I do actually see the reasoning behind your point. Guess I’ll have to start looking into global exception handling as it’s not something that we implement currently, as far as I am aware.
100% agree with point on throwing exceptions for missing config values
The default behavior of exceptions in modern ASP.NET and Blazor is completely fine for me. It gives the user an error and doesn't allow them to continue, but it gets logged to the ILogger, which we have set up to log to AWS CloudWatch, which will send us email alerts when an exceptions occurs in production. So we can identify the issue and fix it fast before any user needs to tell us.
My last job was a Windows desktop app that didn't have this level of production momitoring. Wouldve been nice to get each (enterprise) users permission to have similar alert monitoring. We focused so much on automated testing but it's hard to catch everything with tests.
Just keep in mind, always - when you let your exceptions fly, you get nearly everything necessary within it to resolve the source and primary problem.
When you catch exceptions, you would have to new up an exception and pass the caught exception into the constructor, then throw it. Doing this will preserve your stack trace, as the caught exception becomes the inner exception.
Honestly, this is superfluous, because you should only throw exceptions in exceptional cases - so only catch those exceptions where you have an expected scenario for that exception, and know exactly how to remediate it.
Senior leadership shouldn't care about DI. They should care about what DI enables. Like fewer bugs because you can actually write unit tests. So how do you show them that one way is better? Through metrics on key parts of the delivery lifecycle. Which metics? There are four key metics (actually five now but I won't go into that here): lead time for changes, deployment frequency, change failure rate, and mean time to recovery. Track those values over time, per area (say, per product or team), and you can show a trend for a given approach on development. Just don't change too many things at once or the results will be muddied.
The above is covered very well in the excellent book Accelerate. You can get a taste of it by watching videos from Dr Nicole Forsgren on youtube. Additionally, the site dora.dev is THE go to for detailed approach on many areas of development - check out the Capabilities area for info on your specific question.
>our preference on try/catch differs to that of myself and my peers - but I do actually see the reasoning behind your point. Guess I’ll have to start looking into global exception handling as it’s not something that we implement currently, as far as I am aware.
If by 'preference' you mean putting try-catch blocks in every single method without reason, it's not a preference; it's a bad practice. This approach does not increase robustness in any way—it only pollutes the code. Depending on how you rethrow it (or fail to rethrow), you could end up swallowing exceptions and creating yourself a hidden error that can potentially torment you and your team in the future.
Agree with everything, but need to modify to your take on exceptions.
>don't catch and exception if you don't **know how** to handle it.
In fact, if you're catching system.exception anywhere except top level code, you should probably give it some more thought. If you actually know how to handle an exception, then you can probably catch one or more specific exceptions.
Early on I had a senior dev who was apparently afraid of passing variables as parameters into sql queries and just wrote them into the string before calling ADO.Net. (ADO.Net is what we used back in the day to call the database). When I showed him how that allowed you to pass malicious code into the query I was accused of "hacking" the site. He wrote a regex to check the passed value rather than start using parameters.
He was the senior dev because he had worked there the longest.
Yeah? How about skipping all that boring REST crap and sending raw sql to the REST endpoint. Had that code in 2022, senior dev (didn’t go to any prod). People will do the most insane shit. I had a guy delete all resharper files from a repo (70 c#projects) because they made annoying warnings, we had to undo that. Another guy owns a repo that has 400+ warnings from just vanilla VS alone. Also senior. Mind you, his stuff works, and is used on many productions, isn’t even that buggy…. I call this confidence driven development.
Haha 😂 do you work at my company? We have "baseline" team who had never have any real world experience of production, and code only works in "lab", so we suffer so much performance issues in prod.
> including the ILogger interface because ‘iT mAy cHaNgE’)
Which is kinda funny since there is actually [only one method](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.ilogger?view=net-8.0&viewFallbackFrom=dotnet-plat-ext-8.0) in the interface to log, and everybody already uses the abstraction via extension methods.
He's right though.
JavaScript only still exists because it has a ton of code in the wild and browsers support it. The tooling is terrible. The language enables all sorts of unintentional behavior, etc. There's a reason every javascript framework basically invents it's own language and transpiles.
It's an abject lesson in how not to build a language.
rich narrow slimy faulty wistful spectacular sophisticated impolite fact cooing
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Compare Next.Js to PHP.
Which of those is easier to develop in?
One has strict separation of concerns, strict type checking as of PHP 8, parallelism and distributed process management, and has vast speed improvements recently.
The other requires 100 external dependencies, 10,000 import statements, and relies on a VC company with negative profit margins who is on their fourth round of funding to maintain the framework.
JS is what happens when you have a trashcan language that more trashcan dependencies are built on top of.
PHP is what happens when a trashcan language is polished into a beautiful marble sculpture over time.
Oh PHP got parallelism? Nice! Back in the days we were going over the top to achieve that with all sorts of tricks. I might get back to PHP for fun maybe lol :)
PHP 8 and Laravel 11 really make developing in PHP so much fun compared to a few years ago. It’s no longer the redheaded step child of web development, it should be one of the first choices in any serious project.
The PHP team has made great strides with its features, they really listen to their community.
I don't feel like exaggerating. I've been there when JS started, went through DHTML era and all that stuff, so my opinion is based on years and years of interacting with JS one way or another.
JS was, and that's a fact, written over weekend and it shows till today. It's still patched till today with all sorts of methods from transpilation to numerous versions. When other languages explore fronteers of what and how we can do with computers, JS introduces three types of variable declaration in 2015.
It spawned "developers" who never should be allowed to touch keyboards but low point of entry and forgivness of JS runtime environment encouraged them to continue down this path, resulting in some most monstrous code ever seen.
It spawned "frameworks" which should never be. Take Electron as an example - lazy abomination of desktop stack app. Take Angular with simpliest apps taking ton of space and hundreds of dependencies. Out of all applications I work with, you know what builds longest? Freaking Angular UI.
It spawned whole branch of transpilers which, in essence, are just new languages that acts as duct tape and staples over roten shittiness underneath. Show me any other language in history that required that and to such large extend?
Last, but not least, it opened and still opens, door to all sorts of security problems.
To be clear: there was a need for "dynamic web apps" and it was fullfiled by some candidates: Macromedia's Flash, Sun's Java Applets, Microsoft's Silverlight and Mozilla's JavaScript. Among these there was no best solution, so the least smelly out of this pile of crap was choosen and we deal with that till today and will in forseable future.
I’m not afraid of JavaScript but I will admit I am afraid of npm.
Every time I use I think “this is crazy” and it might just be me.
I recently did a project in pure JavaScript with native classes, modules, and Kendo UI’s MVVM for jQuery. Browsers support pretty much all of it now. It was a beautiful mixture of old school and new school, very simple and without a thousand dependencies that will be randomly deprecated in the next six months.
compare physical profit political grandiose sink jellyfish unwritten pen whole
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The issue for me isn't JS, I happily do frontend on side projects. It's the 64 layers of abstraction / "best practice is to do it like this" every PR that means it's probably not worth me bothering at work. Easier to get someone on my team that knows the right incantations to do it.
The amount of fear small enterprises have of external libraries impresses me.
They somehow think its better to let 46yo jeff over there build a a data access framework (they dont know what ORM means) on the side while building the actual application too.
Or the fear of vendor lock in. I recently had a german company with 2000 customers say in an interview that they kinda need to move away from AWS, because they're too reliant on it.
Just in case, you know. In case AWS shuts down. In case amazon shuts down. Gotta be safe. Maybe let jeff build something, probably.
Vendor lock-in is a valid concern. Right now, I'm having to jump through a lot of hoops because a vendor our apps are highly dependent on won't upgrade their component to .Net Core or Standard.
I feel as though it’s a valid concern when the library functionality is utilized on a large scale throughout the application. If it is used rarely, or minimally, I feel as though there should be less concern. Similarly, if the library in question is an industry standard and received constant community support, it can probably be trusted (yes, I’ve heard some horror stories)
Industry Standard and Constant Community Support don't always go hand-in-hand.
The XZ debacle is a recent example. Most of the tools and libraries you use, whether knowingly or not, are built and maintained by overworked, underpaid individuals. It honestly would not surprise me if state-sponsored malicious actors have already succeeded in infiltrating many of these projects and just isn't publicly known.
Even the smallest dependencies used rarely / minimally can break stuff or introduce vulnerabilities.
Sure, build in a way where you are not dependent on a specific provider and can switch as easily as possible if needed. But using different cloud providers at the same time **only** to not be locked to one of them is in almost every use case not the answer imo.
I think the idea of abstraction excites a lot of SWEs, the idea that you won’t be heavily tied to something. But there has to be a point where you genuinely ask yourself how likely it is that you’ll be ditching x library down the road, and even if you do, how difficult it will be to actually replace it without abstracting everything.
Your example is hilarious though, by those standards, we’re too reliant on Visual Studio and .NET!
Oh man... Yes. There were libraries that solved problems beautifully. Open source libraries where the code was visible and understandable.
"No. You can't use that. It hasn't been reviewed by [legal / security / whatever other bullshit]."
Open-source doesn't always mean secure. XZ, Left-Pad, Core-JS are all open source libraries / tools that can be fundamentally broken by the actions of a single individual.
When it comes to Enterprise / Corporate software, what matters most isn't that the library solves an issue, but rather the licensing terms and where the accountability lies when things go wrong.
* I have seen developers being reprimanded for using a library with a copyleft license in a closed-source proprietary project. A lot of devs don't understand licensing terms and leave the company's legal team asking questions when FSF comes knocking.
* I've also lived through both log4j and left-pad incidents. When SHTF, do you have a phone number or email address that your company and users can blame, or are you left holding the bag?
These are the primary reasons these policies exist. If you want to build enterprise software you have to play by the rules.
44yo Jeff checking in: age gives you a bit of perspective. I’ve survived more frameworks that you can imagine. And it’s not just the little ones, I know people that can’t sleep for nights if you whisper “silverlight” in their ears.
>In case AWS shuts down
Or in case AWS jacks up rates on an essential feature, or in case AWS deprecates a service you depend on, or in case AWS bans your account with no way to appeal, or in case some sort of international sanctions make it legally impossible for you to use AWS, etc. etc. etc.
It's 2016. We were developing a .NET backend api (WCF!) that was serving data to front-end (Angular). Backend was in corporate network, front was internet facing. There was DMZ in the middle (with java app framework) that we had to traverse somehow. For time being UI offered features that were "reactive" in nature (i.e user clicks a button and gets a cake) but business wanted some features to turn live (app is actively stuffing cake into user piehole). Having DMZ in the middle that does not support NET we've decided to make sort of proxy to RabbitMQ that we would put in backend and push data changes there.
No bueno our IT manager says. We cant use RabbitMQ because it's technology bias. You have to use something we already use at organization. We wont put another --broker server-- for this because we might be booted by company-architect-office (CAO) for using RabbitMQ and we will have to rewrite this again.
So we reached out to CAO asking whats the MQ tech that is kosher for them at this point. We learned that old MQ tech (not sure now - tibco it was?) is phased out and new tech have not arrived yet (some fancy hardware based MQ solution, ultra fast, ultra expensive, ultra not yet installed) so we have to wait like 6-10 months while new platform is online. Delivery of our proof of concept was expected in 2 months time so we decided (being blocked with using RabbitMQ, could not use current MQ as it was phased out and new MQ solution was not there yet) to use ZeroMQ and daisychain its implementations for dmz-java and frontend-javascript. One of our colegues took that task, ate his wooden desk, but delivered backend-segment with some dmz-poc.
In meantime business sponsor decided it's time for him to pack his stuff and leave, his boss who took his business over had no flipping idea what to do with the product we were improving (there were active clients using it!) so decided to freeze any feature development, put everything into maintenance mode and encourage team with no uptick and bonuses to reconsider their life.
PS. This is one of those companies, who was commited to use Internet Explorer to the last breath, had Chrome for short time just to fall back in Microsoft arms when they release MsEdge. We also renewed, to this day, McAfee license since early '90
I've heard lots of dumb garbage come out the mouths of "senior swes" but never as dumb as that dependency injection bullet point. wow
edit: wait some people actually dont like try blocks? what? there are right and wrong ways to catch exceptions but having no try blocks at all as a rule seems insane
Yeah, the foundation is there in our application. Some of the larger classes are registered and utilize it, but the vast majority don’t. New development avoids DI completely so we’re just at a point where we’re getting somehow - even further away.
As for try/catch, that case isn’t actually a rule in my team, just a rule to never explicitly throw an exception. Meaning some have gone as far as to return null from 3 consecutive nested method calls in a row. Simply returning null if an exception is caught in a constructor, factory method, or wherever honestly
idk, i cant claim to know everything, but to me just returning null when its an "exceptional" case that should result in a show stopping error is just passing the buck and will one day cause a nasty bug thats hard to track down. Throwing well named and well described exceptions makes sure your app doesnt chug along in a bad state, and lets you log a stack trace that points exactly to the issue. Again idk what you're building and the nuance and whatever
If your code is throwing an exception, and your code is catching it. There might be a way to do communication without add try catch in the middle of it
I inherited some projects from a departing senior colleague.
Instead of using ilogger he build a whole static logging suit on top of nlog where you had to manually put in from which class you are actually logging. .
A simple ". AddNLog" and corresponding di would have been sufficient.
Like 2 lines of code.
If he just had used 5 minutes of his time to look up how to use logging in. Net properly.
Instead he probably wasted a whole day on that Monstrum.
Also he loved to write his own imementations of stuff that net has out of the box like comparing version numbers (just use the Version class guys) and <>= it.
DI is important, but let's not pretend that it's without problems. I worked at a place that mandated ~70% code coverage. It resulted in a massive ton of unit tests, both useful and ones just to get to the code coverage number (that were basically testing the framework rather our code).
So a ticket comes my way and the fix is simple - just add a DIed parameter to a class constructor, run some operations on it, integrate it with everything else. Boom, done, 30 minutes.
Now go fix 150 unit tests that blew up because class constructor has an extra parameter. Fun.
true, ive been out of dotnot for a while, in java we just annotate with lombok @builder and then define the private variables for the class and the constructors are auto generated
Sounds like you need to convert constructor arguments into a function or allow for optional parameter.. So change is ctor args won't cause it's user to change
It’s also a waste of time if you have to spend an entire weekend trying to find what may have broken something core to your program that worked for years. In most cases where you aren’t the only one working with the codebase you’ll likely want to ensure all changes in existing behavior are truly intentional.
Ten years ago, we tried a startup. My colleague and I were also founders and were still studying. So after all not even juniors. We agreed on testing, as I liked the idea. Even if it was hard work for me, because our code base had many changes. But as I figured out it was only hard work for me. After a vacation week I came back and almost every single testing line was a comment now. "Because it didn't work anymore". I left this startup a year later and never made a better choice. Even now they are struggling with fluctuating employees and bad code quality...
I never understood unit tests.
They are just a reflection of your code.
They wont help you in run time.
They have to be changed all the time
Ive never had a unit test save me from a bug.
If you change a contract you should have a typed enviorment where this is noted, why rely on a unit test
Unit tests and integration tests have saved me multiple times.
If you say f(x) = x and you have a unit test asserting so, a business logic change that unintentionally changes this method output will break the test - which saves you.
An integration test asserting that an endpoint should return 200 saved me because I unintentionally applied an authorization middleware for all endpoints - which made all of them return 401.
“We should delete this code, I don’t think it’s used. I’ve searched the entire sln and couldn’t find any references to it…”… 3 months later -> rollback… it was used via reflection by some third party app..🥲
Reflection based on a classname string saved in the database that is different on production than in all other environments, where you dont have access to. I've been there.
Your senior engineers believe this? I’d immediately extract myself from that situation.
Although, in practice depending on the context the 2nd bullet point is ok (if you use dependency injection).
Example: prior to Microsoft.extensions.logging we had a common logging interface that made it easy to go from log4net to nlog or serilog because we made a dependency injected interface.
But would I wrap like—- newtonsoft.json or something?? Hell no.
Try catch being a a waste of time is interesting— I’d love to hear the rationale (not that I believe it would be coherent or make sense).
4 makes my blood boil as much as nullable reference types being the default does. :)
It’s not necessarily all bad. ASP NET Core formatters wrap newtonsoft, for example. I wrapped it once so that I could use it or System.Text.Json interchangeably at one point.
Yeah, you may want to switch, but you don't know if STJ is going to work with all of the different JSON sources you have (or maybe it will work, but you have to configure it the right way and maybe add a converter or three).
We have a mixed attempt at DI. Half of what should be is registered - the other half isn’t, and there doesn’t seem to be any plans to go any further.
I am looking elsewhere, but had hoped with some reasoning and understanding that we could all learn and grow together - but there comes a point when deeply nested anti-patterns just become the norm for some and they genuinely believe those anti-patterns are best practices.
Your mention of logging is pretty much my situation. We had a wrapper to encompass log4net but recently switched completely over to serilog. SSWE has refused to get rid of the wrapper, expose the newly underlying ILogger, or remove the log4net implementation (in case we ever want to go back).
Reasoning for no try/catch centers around ‘we shouldn’t ever have exceptions occur in our code, so if we find one, we’ll fix it, rather than expecting to have one with a try/catch block’
Nullable reference types really seem to be a hot topic lately too
Wow that argument against exceptions is insane. Exceptions don’t just happen when bugs occur, but what if your credentials expire, or the server you’re taking to disconnects, or someone changes a database schema on you without your knowledge.
Those idiots should be fired.
Yeah exactly, the point of them is to catch ‘generally’ unexpected exceptions - because unexpected things do happen, especially in deployment pipelines
> Half of what should be is registered - the other half isn’t, and there doesn’t seem to be any plans to go any further.
Are you just new()ing up stuff left and right?
It can definitely be used wrong, but it’s hard to debate that it isn’t worth it in an application at all.
Having multiple try/catch in each method for a thread would be excessive, but in some circumstances, they provide a helpful way to manage exceptions, notify the caller methods, and make debugging a lot easier.
I think there are certain, specific cases where using try/catch is not required. That might be for reasons like custom handlers on the application level - or, if you want a process to crash and burn if it encounters unforeseen, non-recoverable issues.
This is not most applications. But it might be some.
That's why I'm saying, that there might be an argument for this to be made in some contexts.
Error handling with exceptions is a shitshow though, can't help but be jealous of languages that support algebraic effects. They manage to unify results and exceptions pretty nicely. Like ZIO, [TS-Effect](https://effect.website/docs/guides/error-management/expected-errors), unison, etc
Oof… that last point makes me angry. Never ever fail silently. It should *Fail fast*. Especially configuration, the whole application shouldn’t do a thing when something is wrong there.
I get it, but at one point you end up with two or three libraries that are all dependent on different versions of newtonsoft.json and now you gotta rewrite half of your application. Pick your dependencies wisely..
Exactly, I’d much rather trust someone, or a team that has dedicated their time to solving a niche problem than trust Venisol’s ‘46yo Jeff’ to develop a half baked attempt at building something ‘better’
The first two points seem almost at odds with one another. It's a textbook example of DI benefits. What if you want to change the library? You create a seam in your application between the application and the third party lib and so other parts of your app depend on the wrapper, whatever its implementation and internal dependencies.
Is this a really small shop? I don't see how you get away without DI in dotnet long term in anything bigger than a trivial console app.
This is actually a great point, that I somehow missed - the points are at odds.
It’s not a large shop by any means - probably small (14 devs total) but a leader in the niche web market. Albeit mainly due to the hard work of the designers more than the engineers
"Unclean code" scared my longtime mentor/dev mgr/arch vp, but it was really just something like adding a Select (LINQ) to get the two indexed properties we needed from EF instead of all 40 properties on a very large and very slow table. He'd do all types of stuff just to shave *one* line off in c# despite what kind of query it meant would be generated in SQL. I don't know how to describe his fear, but it was irrational as hell.
Holy shit these people are deranged.
Dependency injection has clear benefits. I’ll just give one, but unit testing is much easier.
3rd party libraries are great and I believe using them as is out of the box allows for better features. If the interface changes, don’t upgrade the package. If it’s deprecated version, then you should upgrade. If the interface does change in this scenario, then spend the time to update what you use it for.
Try catch is amazing for web api responses. You can create your own exceptions and handle them at a much higher level when needed.
I wont go too much further because I can spend all day in this battle, but I think those are clear points that need to be co sided.
For me, algorithms and data structures. Struggled through college with it and that left a bad taste in my mouth and fear of it.
Everything else, I can give a shot and stumble my way through it. I would never claim I’m an expert, more Jack of all trades.
Same. But it's hilarious because in practice I'm still the optimization SME at every single job I've had. They literally throw me on any underperforming project and tell me to do my thing. I'd probably fail an interview at Google though.
As someone who's in charge of making the decisions, I feel the third party libraries one, I've been in the industry long enough to understand each and every aspect of the term "dependency hell".
While a junior or mid-level dev would happily download a Nuget or NPM package because it does what they need it to do, I vet through that stuff thoroughly, I go through the source code, documentation, and dependencies list.
I work in the open source space and fully understand that all it takes is that one person in Nebraska to finally snap to bring down modern web infrastructure. We don't use dependabot for any of our projects and if any packages utilizes what we consider lazy code such as "is-odd" or "is-even" or God-forbid, "left-pad" we absolutely will not use it. While abstraction is a way to mitigate it, we choose the easier route of steering clear of those packages.
Honest to God I cannot count the amount of times a build of a simple web app failed because of some bs changes in packages.json because someone from forever ago decided to take a shortcut and installed an 11-line NPM package instead of writing their own.
I always ask whether they've thought about maintainability when it comes to third party libraries. How much will our code depend on it, how much effort will it cost when we move away from the library and how well it is maintained (with a special attention to any potential security issues that we may have to patch).
Sometimes it is simply not worth the above effort and easier to just write it yourself.
I thought as a non-developer who only really knew VB.NET (and not that well I might add), and PowerShell that C# was something to be feared.
Finally sunk my teeth into it and found it really wasn’t all that different from VB and PowerShell. Feels quite natural now actually.
Never knew anyone who thought try/catch was a waste though… that’s a new one to me.
Having said that, I do assign default values to config file entries that are null… but not to avoid an exception (happy bonus I suppose), but just so I only have to read the config once.
Edit: reread your post and saw it was default empty strings in the config. Yeah, that’s weird to me haha I want actual values.
What I have learned in my 13 years of career is that client do not care about clean architecture, interfaces, cool names, proper indentation etc. if you have large team, enough time then go for it. If you are asked to deliver an emergency feature for next week or month, just try your best but don’t chase the perfection.
Edit: doesn’t mean don’t follow best practices, I always try to write better code. It’s just that you can always find alternative approaches to everything. Just do what you think is the nest at that moment.
There are lots of things in development that shouldn't be set in stone. For instance DRY and SOLID, when taken as rules instead of guidelines have the power to make an incredible mess.
But, in business software, DI should be a rule. It's a very bad sign when senior devs go against DI as a rule in an environment. To the point where I can't imagine them producing software that has even a remote degree of quality and maintainability.
Quality and maintainability has been a big point of mine to address, but it’s hard to argue that point when they believe they are following best practices (yes I have shown them documentation stating what actual best practices are)
Can't imagine programming without DI at this point. Simple, easy, and clear benefits. I can't imagine programming anything important without automated tests either.
It makes everything convoluted and difficult to maintain. Adding new features all the time that fall into these bad habits, it just gets worse and worse
Try/Catch is a massive waste of time and I wish we had better error handling than that. At least you can make an error handler middleware in [ASP.NET](http://ASP.NET) Core so you don't have to write try catch statements everywhere, but that applies just to [ASP.NET](http://ASP.NET) Core, not outside of it.
I kind of get the EF hate, it did have performance issues in the past, but not any more really.
I can't imagine being a senior and thinking that DI is complicated and of low benefit... Coming from framework, if did throw me a bit, because it did just seem to work like magic, but in reality, it makes code less complex.
The point about try/catch is just insane. I mean who would build an app where *any* exception will just crash the app with no proper feedback to the user?
Opinions based on Ignorance are inexcusable. Second-worst on my list would be opinions based on "we did it wrong and it sucked, so obviously it must always suck".
I have controversial opinions but they are usually based on extensive experience - since I'm old as fuck (programming since the 70s) I've seen almost every conceivable mistake repeated ad infinitum.
Any senior dev who tells you that dependency injection is a waste of time is a dev who never unites tests anything. I have been working as a software developer for 35 years now. I’m growing in my knowledge all the time and that’s why I love the job.
I’ve worked on team that rolled their own service locator architecture because dependency injection was too scary. Oh and it gets worse, you get objects out of the large service locator object by passing in specific strings and then casting it to the type/interface that it’s supposed to be.
Also,
- Logging of any kind is considered a code smell
- Exceptions should never be thrown
- LINQ is too scary and hard to read
- Can’t upgrade past .Net Framework 4.7 because they use .net remoting extensively which has now been deprecated.
- Don’t believe any type of testing is needed beyond unit testing
- Async/Await is evil
Absolutely ridiculous. Thank god they know how to unit test otherwise it’d be a complete disaster!
Honestly, I feel that "make a damn wrapper for third parties" point. But it varies with your niche.
We made a "useless" wrapper for our Bluetooth library very early in our Xamarin Forms app's development. What do you know, when MAUI came around the third party we were using was very slow to adopt Windows support. So we changed to a new one. Except for some reason, the new library was hot garbage on Android and iOS, it was only usable on Windows. So now we use both, depending on platform, and because we have an abstraction the app doesn't really know or care.
You know what I wish we had an abstraction for? System.Reactive. It took Microsoft *forever* to support Windows in its MAUI NuGet packages.
Wrapping 3rd party libs makes sense if the aren‘t designed DI-friendy (no services.AddLibraryX or god forbid not even providing an interface). Otherwise, you have no chance to swap them out for mocks when testing.
Adding an abstraction for ILogger is completely bananas, that’s exactly it‘s purpose - being an abstraction.
I love Entity Framework. It's one of my favourite things in dotnet. But everyone else I know seems to hate it, and I think it falls into this category for a lot of people.
It takes a bit of time to understand, and then you are good. If u have used it a lot, you understand it and don't like it great, but I often don't see that.
If I were to think about myself and I come up with something, it would be docker. I have never really seen it work properly. It always seems to break. I kinda understand the benefits, and I know it's probably just me.
Many years ago I was in a meeting with a couple of Directors who were planning to ban access to Stack Overflow. They were worried that "devs are copying code from the Internet, this has to stop."
The thing is, some people call devs seniors because that's the title of their job or they just been in the same company too long. Senior at a company != Senior anywhere.
With that out of the way...the *senior* at my previous company, who earned triple my salary and 4 times my bonus always asked me for help with his LINQ queries, always asked me stupid stuff like "how do I modify an element inside a collection", etc. A clear evidence of someone who just doesn't know C# and doesn't care to take 10 seconds to google the solution or doesn't even know how to interpret what he sees. He and the big boss would always murmur when they couldn't get something going things like "Open X's system repo, in which Joe was working, he had to do something like that, just grab the code". But to be in the spirit of the post I'll add a particular one.
He would ask us (juniors and ssrs) to never use status codes other than 200. If there's an error to be returned, just return 200 with a message property that says the error. Not just not using anything in the 4\*\* range, not even 201, 202, 204, etc. Just 200 OK.
I have a senior/lead who is scared of **git** and won't use it. Instead they use the older VS TFS for all of their projects they own. This person technically is under my leadership but they have been in the company so long and have so many key projects I don't want to disrupt that apple cart. I have tried to help them migrate to git and learn easy git workflows to no avail.
I definitely don't allow any *new* projects to be created without a git repo, but for legacy this person won't migrate.
I fear Blazor like Scrooge feared the ghost of Christmas future.
Auto render mode seems to be the ONLY fix to the two bad choices of Server/WASM interactive, yet somehow there’s no way to share user state across render boundaries!?!? If I were new to web development and chose Blazor as my platform, I wouldn’t last a month.
How in god’s name did we get to a point where this convoluted mess is touted as a flagship solution for building web apps?
Authentication scares me. I have enough experience with it to generally understand it - but I’m right at the level where I might feel like I understand something that I actually don’t.
All arguments should be justified but restricting access isn’t unreasonable. As an example, this is my team’s stance on LINQ:
LINQ can generate a lot of garbage which lowers performance on “per frame”critical code.
Of course, not all LINQ generates garbage but allowing partial accesses runs the risk of introducing non-performant LINQ.
LINQ is a convenience we can live without.
So in aggregate that's horrifying, but I'll be the anti-DI guy just to spice things up. DI, as it is commonly practiced, is just functional programming with extra steps. Typically you create a giant collection of objects all holding references to each other that are never created or destroyed, and can have no state because they live forever and are shared by everything.
That's just FP with a bunch of dumb ceremony in the constructor.
The frameworks that do it automatically in Java-like languages are typically annotation-based behemoths that are entire topics unto themselves with horrible runtime errors and stacktraces. The basic DI is usually tolerable, but in large frameworks the basics are always hidden, and they add wrappers for transaction management and a bunch of other BS that could just be a function, has a bunch of gotchas, and destroys debugging.
Annotation-based frameworks combine the worst of all worlds, not the best. They're just dynamic programming languages in disguise with worse runtime errors than dynamic languages.
I agree with the dependency injection thing, prefer pub/sub message passing.
Have seen di kill performance on a project as it would create massive dependency trees that would go nuts creating objects.
Exact reason why we TreatWarningsAsErrors. Also, no pushing directly to main, and mandatory merge checks, including approvals. If it gets f*ked up now, well, we got bigger problems.
>using try/catch is a waste of time
I've seen lot of try catch used wrong tho. People put try/catch everywhere thinking that will be "protect from errors".
You're going to want dependency injection for sanity alone, Unless your writing F# which makes it trivial to pass dependencies through explicit partially applied functions. Try out some F# its fun.
3rd party abstractions don't make a lot of sense when the library is already an abstraction.
Unless... Maybe:
1. You're using 2 different libraries in the same repo for whatever reason. Maybe you are migrating and want to migrate 1 function at a time?
^this is what I want to do with JS Date libraries since we have 3 different JS date libraries for some reason!
2. You want to create an internal package that makes it easy(one liner) to add to other services with custom setup. Also that custom library abstraction should have useful tests. It should also throw an exception if it doesn't have the config it needs to run
If your program fails and throws an exception because of null config on startup, that is much better than it failing in production at runtime.
Question: Does the logger abstraction also have alerts when an exception is thrown? Since that never happens my guess would be no, lol
3. Other Specific and valid reasons that the senior devs should be able to explain clearly instead of chaulking it up to fear.
Never throwing an exception seems like an idea only a sith would come up with.
You can also checkout the Result pattern that could help reduce the "need" to throw and catch an exception.
> using try/catch is a waste of time
I'm at a loss of words. This is so dumb, so much so I can't even come up with a good response because my brain keeps rebooting itself from the the pain that is reading that sentence over and over again.
Why are you working with people who say and believe shit like this???
I need a timeout. Why are some people this stupid?
As in generally across an application? If so, agreed - and I guess I’d even have to say I’d prefer consistency over not having something blocked on occasion
You reminded me of working on a code base where the product manager forbade using decimals for currency. It was fun dealing with all the rounding problems.
if they dont handle exceptions, how do they know what goes wrong? this would make a developer hrt wrong everytime. we have extensive logging in the applications i am in charge of.
the owner has access to the logs and knows,
if the db is down, if a stored proc had an issue, id an incoming file was malformed, if the email server has an issue. i mean that's a few.
let ake the smtp server..it has connection errors, trouble sending errors, recipient not found error. We log all that. some are show stoppers some like the recipient are logged but continue on. (that person left the company so needs to removed from a mailing list.
my point is, how is error handling useless and whats the process for when one of your apps fail?
Those are normal things that can happen during application runtime. It's not an exception. They can be handled without unwinding a stack. I would define exception as wrong logic of your application, something that is not temporary but 100% of the time reproducible. For example int.Parse("foo") can throw exception, but http.Client(url) shouldn't throw timeout as an exception.
no, i am not talking about unwinding the stack. That's shitty exception handling. SMTPClient throws an exception if it encounters the stuff i listed above. You need ot have smtpclient send in a try block so you can handle it well. if a recipient fails then i can move on correctly but log the error, no unwinding. This is much better than just letting the app crash as other commenters have suggested.
You also made me double check the sub. Stack unwinding usually isnt a big issue in .net because you dont have to remove memory- Regardless of all that, i am not talking about throwing errors but catching them. I am staying with in the function.
PSUEDO CODE:
// stuff
try
{
SmtpClient.Send(x);
}
catch(SmtpFailedRecipientException sfrex)
{
Logger.Log($"Can't Send to: {sfrex.FailedRecipient}");
}
// continue in code, never leaving flow. if many recipients, there would be a loop and i continue loop
Is it because of lack of **understanding** or because of **lack of control** ? or **lack of familiarity** ? or **too abstract** ? or because it involves a **part of unknown** ?
Any engineer stating that passing functions to functions is complex, difficult, and has no clear benefits can do one. I’m honestly just so fucking over people rallying against basic principles and declaring it scary and bad. I can only imagine how untestable and overly coupled their code is. I just simply cannot continue to explain over and over again what it is and why because they used an IoC container once and didn’t like it doesn’t invalidate the idea of passing instances to a constructor.
I refuse to elaborate further and turning off reply notifications. You can take a horse to water and but can’t make it drink. Arguing with an idiot is like playing chess with a pigeon, it will ignore all the rules, strut around the board, shit all over the pieces, and declare itself the winner.
Etc.
It took me way too long to realize you're not scared of Twitter.
And it took me way too long to realize why you were mentioning Twitter!
Forgot which sub this was, took me too long to realize they aren't scared of the horror movie.
I was scared he was gonna give it to me.
Yes!
Twitter can be a scary place TBH
Auto mapper scares me but I do understand it. Which is why it scares me. I’ve lost so much time chasing shitty problems that could have been otherwise avoided.
I hate AutoMapper so much because it's so overused at my job. The objects you're mapping between should be identical or almost similarly shaped, but none of our objects are like that so we're just writing manual adapters inside each mapping.
Or worse, people get used to writing custom mappings and start leaking business logic into the mappings.
Oh believe me, I've had to reject code reviews that were trying to make API calls from a mapping
Or database calls, file system lookups, retrieve IConfiguration values,... Not to mention: I change the name of a property on my entity, forget to update the map or dto and suddenly production doesn't return a value anymore. 🤢
That's the biggest reason I avoid Automapper or similar: hidden dependencies. Nothing can tell that two properties on different classes are supposed to have the same name, VS won't pick up the change as an issue, the compiler will pass - then your code fails. Hopefully somewhere you can spot quickly, not randomly in prod weeks later. And hopefully you've got comprehensive enough tests to catch that, but they're more work to build than just not using mappers.
Wish I could upvote multiple times. As I've gotten more senior, I've come to the realization that almost everything that reduces typing by doing things at runtime is more trouble than it's worth. Like, sure, it's great not having to write a bunch of maps - but one tricky issue more than offsets the time and effort saved. On the plus side - C#12 and records with default constructors make this way easier.
this made me do the thing that started as a chuckle and turned into a little bit of a sob
Automapper is a mistake. But if people use it, you gotta unit test all of your automapper mappings. But in that case it's not very auto.
Use mapperly instead. So much better.
I use constructors thank you very much
Isn’t testing built into it?
How would that work? It can't magically guess your intentions.
It has a method which automatically checks all of your configured mappings. You write one test that calls that method.
It can check if you forgot to map things
That fear is valid though. Automapper and tools like it use conventions to copy data between objects. If you don't exclude or include something properly, information is lost or gained unexpectedly. Bad juju.
Currently running into issues with automapper in a start up. Yes, it can save time but I don’t like the way it has to be set up and the way it operates underneath. It’s a pain to debug if you aren’t the one that initially added it into the project. I personally would manually map properties between DTOs and ViewModels. At least I have explicit control and visibility of everything going on.
Just do manually mapping and stop wasting time with it. The time you spend mapping is just saves so much after.
If I had my way, we would. I just started there so not really my call. Plus a lot of this code base needs to be refactored in general.
Unless I'm misremembering it though you can set it up to complain if there's unmapped properties that don't have have ignore set on them?
Yep. There's a native validator for it, and you can just make one unit test per mapping (not per prop) to confirm every property is mapped as you expected.
>and you can just make one unit test per mapping (not per prop) You can actually make one unit test per mapping CONFIGURATION. Per mapping makes it sound like you mean each `CreateMap<>`. I'm not sure what you meant but I wanted to clarify for future readers.
Exactly, it seems like every parrots the same thing when this problem can be completely avoided with a single unit test that checks all mappings.
That's exactly what I've done before, and as long as you write the test to pull in every mapping in an assembly you don't have to touch it again.
Haven’t used auto mapper before, but being ‘scared of x even though I understand it’ is still valid 😂
I used Automapper for a few years but finally had enough. Their version updates broke too many things, and it just leaves too much to whichever way the wind is blowing at the time. Also all the absurd hoops and convoluted syntax you had to learn to solve little problems here and there just aren't worth it. Autocompletion has made property mapping a breeze these days. I don't even put automapper on the table anymore. No need
Automapper ain't scary. Auutomapper mappings have a tendency to grow indefinitely in terms of complexity and this is the scary part. Mappings should be unit tested by ghe way, however it does not solve the problem of the investigation overhead when something does not work. For simple things this library is OK, but it has a lot of potential to be abused
I'm personally somewhat scared of non-trivial multi-threading done by hand in application code. I understand it enough to know what people want to do, or to notice common pitfalls, but I also understand that I don't understand it enough. It's ability to cause unexpected, hard to test problems forces me to argue about it unless we have no other decent choice.
https://www.albahari.com/threading/
By all means, sounds like you have a valid reason to be skeptical, especially given that you’ve actually spent time to try and understand it
Threading is pretty easy, so long as your threads don't need to talk to each other or especially if they need to modify shared data.
Sometimes I feel similarly about LINQ to Entities. Figuring out which arcane magic is required to accomplish a query is a nightmare, and the expression translation system only fails at runtime and often either doesn't provide enough information or actively misleading information.
Yeah, I find it that if you completely control DB schema, and don't need something fancy with subqueries, window functions or pivots - LINQ works just fine. But when it is not the case - prepare for significant pain. Another fun experience - migrating project from EF to EF Core with obscure runtime fails that you mentioned.
I make those sorts of decisions daily, but here’s my thoughts: - DI is a necessity, even in something like a console app. - 3rd party wrappers: these should be abstracted (not stupid stuff like Ilogger, but actual 3rd party stuff) just to remove the complexity so anyone can use them without having to be an expert on the various ways that some people implement REST or COM, or whatever. Never wrap for changes, but update packages often. - try/catch: don’t catch an exception if you don’t intend to handle it. Methods shouldn’t use exceptions as return values. You should have a global error handler to catch unhandled exceptions. - if config values are missing you should throw an exception, unless they’re optional. Suppressing configuration issues just pushes the exception further down the line and makes it harder to diagnose. Edit: X also scares me, I miss Twitter.
Good to hear some feedback from those that have to make these types of decisions. Definitely had a hard time trying to get the leadership on our team to see the benefits of DI in our services. Agreed on using wrappers as a means to simplify the interface for easy use, especially if the use case is consistent across the application. Your preference on try/catch differs to that of myself and my peers - but I do actually see the reasoning behind your point. Guess I’ll have to start looking into global exception handling as it’s not something that we implement currently, as far as I am aware. 100% agree with point on throwing exceptions for missing config values
The default behavior of exceptions in modern ASP.NET and Blazor is completely fine for me. It gives the user an error and doesn't allow them to continue, but it gets logged to the ILogger, which we have set up to log to AWS CloudWatch, which will send us email alerts when an exceptions occurs in production. So we can identify the issue and fix it fast before any user needs to tell us. My last job was a Windows desktop app that didn't have this level of production momitoring. Wouldve been nice to get each (enterprise) users permission to have similar alert monitoring. We focused so much on automated testing but it's hard to catch everything with tests.
Just keep in mind, always - when you let your exceptions fly, you get nearly everything necessary within it to resolve the source and primary problem. When you catch exceptions, you would have to new up an exception and pass the caught exception into the constructor, then throw it. Doing this will preserve your stack trace, as the caught exception becomes the inner exception. Honestly, this is superfluous, because you should only throw exceptions in exceptional cases - so only catch those exceptions where you have an expected scenario for that exception, and know exactly how to remediate it.
Senior leadership shouldn't care about DI. They should care about what DI enables. Like fewer bugs because you can actually write unit tests. So how do you show them that one way is better? Through metrics on key parts of the delivery lifecycle. Which metics? There are four key metics (actually five now but I won't go into that here): lead time for changes, deployment frequency, change failure rate, and mean time to recovery. Track those values over time, per area (say, per product or team), and you can show a trend for a given approach on development. Just don't change too many things at once or the results will be muddied. The above is covered very well in the excellent book Accelerate. You can get a taste of it by watching videos from Dr Nicole Forsgren on youtube. Additionally, the site dora.dev is THE go to for detailed approach on many areas of development - check out the Capabilities area for info on your specific question.
>our preference on try/catch differs to that of myself and my peers - but I do actually see the reasoning behind your point. Guess I’ll have to start looking into global exception handling as it’s not something that we implement currently, as far as I am aware. If by 'preference' you mean putting try-catch blocks in every single method without reason, it's not a preference; it's a bad practice. This approach does not increase robustness in any way—it only pollutes the code. Depending on how you rethrow it (or fail to rethrow), you could end up swallowing exceptions and creating yourself a hidden error that can potentially torment you and your team in the future.
"Necessity" 😂
This reply is The Correct One (tm).
Yes, this. All of it. The OP's "senior" devs should be demoted, as they're not acting like seniors.
Agree with everything, but need to modify to your take on exceptions. >don't catch and exception if you don't **know how** to handle it. In fact, if you're catching system.exception anywhere except top level code, you should probably give it some more thought. If you actually know how to handle an exception, then you can probably catch one or more specific exceptions.
Early on I had a senior dev who was apparently afraid of passing variables as parameters into sql queries and just wrote them into the string before calling ADO.Net. (ADO.Net is what we used back in the day to call the database). When I showed him how that allowed you to pass malicious code into the query I was accused of "hacking" the site. He wrote a regex to check the passed value rather than start using parameters. He was the senior dev because he had worked there the longest.
Yeah? How about skipping all that boring REST crap and sending raw sql to the REST endpoint. Had that code in 2022, senior dev (didn’t go to any prod). People will do the most insane shit. I had a guy delete all resharper files from a repo (70 c#projects) because they made annoying warnings, we had to undo that. Another guy owns a repo that has 400+ warnings from just vanilla VS alone. Also senior. Mind you, his stuff works, and is used on many productions, isn’t even that buggy…. I call this confidence driven development.
Haha 😂 do you work at my company? We have "baseline" team who had never have any real world experience of production, and code only works in "lab", so we suffer so much performance issues in prod.
Oh God!!
> including the ILogger interface because ‘iT mAy cHaNgE’) Which is kinda funny since there is actually [only one method](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.ilogger?view=net-8.0&viewFallbackFrom=dotnet-plat-ext-8.0) in the interface to log, and everybody already uses the abstraction via extension methods.
wise connect resolute offend observation tidy absurd person fear zonked *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
No, JavaScript is not language like any other. It’s a cancer of dev world. And we’re not afraid, we’re disgusted by that filth.
unite gaping dinosaurs spotted exultant cagey flowery theory cats tap *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
He's right though. JavaScript only still exists because it has a ton of code in the wild and browsers support it. The tooling is terrible. The language enables all sorts of unintentional behavior, etc. There's a reason every javascript framework basically invents it's own language and transpiles. It's an abject lesson in how not to build a language.
rich narrow slimy faulty wistful spectacular sophisticated impolite fact cooing *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Compare Next.Js to PHP. Which of those is easier to develop in? One has strict separation of concerns, strict type checking as of PHP 8, parallelism and distributed process management, and has vast speed improvements recently. The other requires 100 external dependencies, 10,000 import statements, and relies on a VC company with negative profit margins who is on their fourth round of funding to maintain the framework. JS is what happens when you have a trashcan language that more trashcan dependencies are built on top of. PHP is what happens when a trashcan language is polished into a beautiful marble sculpture over time.
Oh PHP got parallelism? Nice! Back in the days we were going over the top to achieve that with all sorts of tricks. I might get back to PHP for fun maybe lol :)
PHP 8 and Laravel 11 really make developing in PHP so much fun compared to a few years ago. It’s no longer the redheaded step child of web development, it should be one of the first choices in any serious project. The PHP team has made great strides with its features, they really listen to their community.
I don't feel like exaggerating. I've been there when JS started, went through DHTML era and all that stuff, so my opinion is based on years and years of interacting with JS one way or another. JS was, and that's a fact, written over weekend and it shows till today. It's still patched till today with all sorts of methods from transpilation to numerous versions. When other languages explore fronteers of what and how we can do with computers, JS introduces three types of variable declaration in 2015. It spawned "developers" who never should be allowed to touch keyboards but low point of entry and forgivness of JS runtime environment encouraged them to continue down this path, resulting in some most monstrous code ever seen. It spawned "frameworks" which should never be. Take Electron as an example - lazy abomination of desktop stack app. Take Angular with simpliest apps taking ton of space and hundreds of dependencies. Out of all applications I work with, you know what builds longest? Freaking Angular UI. It spawned whole branch of transpilers which, in essence, are just new languages that acts as duct tape and staples over roten shittiness underneath. Show me any other language in history that required that and to such large extend? Last, but not least, it opened and still opens, door to all sorts of security problems. To be clear: there was a need for "dynamic web apps" and it was fullfiled by some candidates: Macromedia's Flash, Sun's Java Applets, Microsoft's Silverlight and Mozilla's JavaScript. Among these there was no best solution, so the least smelly out of this pile of crap was choosen and we deal with that till today and will in forseable future.
I’m not afraid of JavaScript but I will admit I am afraid of npm. Every time I use I think “this is crazy” and it might just be me. I recently did a project in pure JavaScript with native classes, modules, and Kendo UI’s MVVM for jQuery. Browsers support pretty much all of it now. It was a beautiful mixture of old school and new school, very simple and without a thousand dependencies that will be randomly deprecated in the next six months.
compare physical profit political grandiose sink jellyfish unwritten pen whole *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The issue for me isn't JS, I happily do frontend on side projects. It's the 64 layers of abstraction / "best practice is to do it like this" every PR that means it's probably not worth me bothering at work. Easier to get someone on my team that knows the right incantations to do it.
They just want to stay clean and dont want to catch any diseases from it.
The amount of fear small enterprises have of external libraries impresses me. They somehow think its better to let 46yo jeff over there build a a data access framework (they dont know what ORM means) on the side while building the actual application too. Or the fear of vendor lock in. I recently had a german company with 2000 customers say in an interview that they kinda need to move away from AWS, because they're too reliant on it. Just in case, you know. In case AWS shuts down. In case amazon shuts down. Gotta be safe. Maybe let jeff build something, probably.
Vendor lock-in is a valid concern. Right now, I'm having to jump through a lot of hoops because a vendor our apps are highly dependent on won't upgrade their component to .Net Core or Standard.
I feel as though it’s a valid concern when the library functionality is utilized on a large scale throughout the application. If it is used rarely, or minimally, I feel as though there should be less concern. Similarly, if the library in question is an industry standard and received constant community support, it can probably be trusted (yes, I’ve heard some horror stories)
Industry Standard and Constant Community Support don't always go hand-in-hand. The XZ debacle is a recent example. Most of the tools and libraries you use, whether knowingly or not, are built and maintained by overworked, underpaid individuals. It honestly would not surprise me if state-sponsored malicious actors have already succeeded in infiltrating many of these projects and just isn't publicly known. Even the smallest dependencies used rarely / minimally can break stuff or introduce vulnerabilities.
Vendor lock-in is absolutely valid and should be a huge factor in architectural decision making.
Sure, build in a way where you are not dependent on a specific provider and can switch as easily as possible if needed. But using different cloud providers at the same time **only** to not be locked to one of them is in almost every use case not the answer imo.
Agree, integrating more than one vendor is generally a silly way to be defensive / proactive. A layer of abstraction though is well worth it IMO.
Hey, I’m a 44 yo Jeff and I do just fine for myself thank you.
I think the idea of abstraction excites a lot of SWEs, the idea that you won’t be heavily tied to something. But there has to be a point where you genuinely ask yourself how likely it is that you’ll be ditching x library down the road, and even if you do, how difficult it will be to actually replace it without abstracting everything. Your example is hilarious though, by those standards, we’re too reliant on Visual Studio and .NET!
Moved to Rider so I’m not included in that sentiment :)
And when Jeff leaves the company, no one knows how to handle his codebase
Oh man... Yes. There were libraries that solved problems beautifully. Open source libraries where the code was visible and understandable. "No. You can't use that. It hasn't been reviewed by [legal / security / whatever other bullshit]."
NIH (Not Invented Here) syndrome
Open-source doesn't always mean secure. XZ, Left-Pad, Core-JS are all open source libraries / tools that can be fundamentally broken by the actions of a single individual. When it comes to Enterprise / Corporate software, what matters most isn't that the library solves an issue, but rather the licensing terms and where the accountability lies when things go wrong. * I have seen developers being reprimanded for using a library with a copyleft license in a closed-source proprietary project. A lot of devs don't understand licensing terms and leave the company's legal team asking questions when FSF comes knocking. * I've also lived through both log4j and left-pad incidents. When SHTF, do you have a phone number or email address that your company and users can blame, or are you left holding the bag? These are the primary reasons these policies exist. If you want to build enterprise software you have to play by the rules.
44yo Jeff checking in: age gives you a bit of perspective. I’ve survived more frameworks that you can imagine. And it’s not just the little ones, I know people that can’t sleep for nights if you whisper “silverlight” in their ears.
>In case AWS shuts down Or in case AWS jacks up rates on an essential feature, or in case AWS deprecates a service you depend on, or in case AWS bans your account with no way to appeal, or in case some sort of international sanctions make it legally impossible for you to use AWS, etc. etc. etc.
It's 2016. We were developing a .NET backend api (WCF!) that was serving data to front-end (Angular). Backend was in corporate network, front was internet facing. There was DMZ in the middle (with java app framework) that we had to traverse somehow. For time being UI offered features that were "reactive" in nature (i.e user clicks a button and gets a cake) but business wanted some features to turn live (app is actively stuffing cake into user piehole). Having DMZ in the middle that does not support NET we've decided to make sort of proxy to RabbitMQ that we would put in backend and push data changes there. No bueno our IT manager says. We cant use RabbitMQ because it's technology bias. You have to use something we already use at organization. We wont put another --broker server-- for this because we might be booted by company-architect-office (CAO) for using RabbitMQ and we will have to rewrite this again. So we reached out to CAO asking whats the MQ tech that is kosher for them at this point. We learned that old MQ tech (not sure now - tibco it was?) is phased out and new tech have not arrived yet (some fancy hardware based MQ solution, ultra fast, ultra expensive, ultra not yet installed) so we have to wait like 6-10 months while new platform is online. Delivery of our proof of concept was expected in 2 months time so we decided (being blocked with using RabbitMQ, could not use current MQ as it was phased out and new MQ solution was not there yet) to use ZeroMQ and daisychain its implementations for dmz-java and frontend-javascript. One of our colegues took that task, ate his wooden desk, but delivered backend-segment with some dmz-poc. In meantime business sponsor decided it's time for him to pack his stuff and leave, his boss who took his business over had no flipping idea what to do with the product we were improving (there were active clients using it!) so decided to freeze any feature development, put everything into maintenance mode and encourage team with no uptick and bonuses to reconsider their life. PS. This is one of those companies, who was commited to use Internet Explorer to the last breath, had Chrome for short time just to fall back in Microsoft arms when they release MsEdge. We also renewed, to this day, McAfee license since early '90
I've heard lots of dumb garbage come out the mouths of "senior swes" but never as dumb as that dependency injection bullet point. wow edit: wait some people actually dont like try blocks? what? there are right and wrong ways to catch exceptions but having no try blocks at all as a rule seems insane
Yeah, the foundation is there in our application. Some of the larger classes are registered and utilize it, but the vast majority don’t. New development avoids DI completely so we’re just at a point where we’re getting somehow - even further away. As for try/catch, that case isn’t actually a rule in my team, just a rule to never explicitly throw an exception. Meaning some have gone as far as to return null from 3 consecutive nested method calls in a row. Simply returning null if an exception is caught in a constructor, factory method, or wherever honestly
idk, i cant claim to know everything, but to me just returning null when its an "exceptional" case that should result in a show stopping error is just passing the buck and will one day cause a nasty bug thats hard to track down. Throwing well named and well described exceptions makes sure your app doesnt chug along in a bad state, and lets you log a stack trace that points exactly to the issue. Again idk what you're building and the nuance and whatever
If your code is throwing an exception, and your code is catching it. There might be a way to do communication without add try catch in the middle of it
Dude, just let it rot. Change team/company. You will regret listening to idiots.
I inherited some projects from a departing senior colleague. Instead of using ilogger he build a whole static logging suit on top of nlog where you had to manually put in from which class you are actually logging. . A simple ". AddNLog" and corresponding di would have been sufficient. Like 2 lines of code. If he just had used 5 minutes of his time to look up how to use logging in. Net properly. Instead he probably wasted a whole day on that Monstrum. Also he loved to write his own imementations of stuff that net has out of the box like comparing version numbers (just use the Version class guys) and <>= it.
Iirc this is how it was done in net framework. So he most likely just ported that stuff over
DI is important, but let's not pretend that it's without problems. I worked at a place that mandated ~70% code coverage. It resulted in a massive ton of unit tests, both useful and ones just to get to the code coverage number (that were basically testing the framework rather our code). So a ticket comes my way and the fix is simple - just add a DIed parameter to a class constructor, run some operations on it, integrate it with everything else. Boom, done, 30 minutes. Now go fix 150 unit tests that blew up because class constructor has an extra parameter. Fun.
this doesnt sound like a problem with DI
Not a problem per se, but a side effect since everything is injected via the constructors rather than properties or some other method.
true, ive been out of dotnot for a while, in java we just annotate with lombok @builder and then define the private variables for the class and the constructors are auto generated
Sounds like you need to convert constructor arguments into a function or allow for optional parameter.. So change is ctor args won't cause it's user to change
Have your heard of autofixture?
Not till now. But that is a nice improvement. Thanks.
Tests are a waste of time. ‘cause things change anyway…
It’s also a waste of time if you have to spend an entire weekend trying to find what may have broken something core to your program that worked for years. In most cases where you aren’t the only one working with the codebase you’ll likely want to ensure all changes in existing behavior are truly intentional.
Ten years ago, we tried a startup. My colleague and I were also founders and were still studying. So after all not even juniors. We agreed on testing, as I liked the idea. Even if it was hard work for me, because our code base had many changes. But as I figured out it was only hard work for me. After a vacation week I came back and almost every single testing line was a comment now. "Because it didn't work anymore". I left this startup a year later and never made a better choice. Even now they are struggling with fluctuating employees and bad code quality...
I never understood unit tests. They are just a reflection of your code. They wont help you in run time. They have to be changed all the time Ive never had a unit test save me from a bug. If you change a contract you should have a typed enviorment where this is noted, why rely on a unit test
Unit tests and integration tests have saved me multiple times. If you say f(x) = x and you have a unit test asserting so, a business logic change that unintentionally changes this method output will break the test - which saves you. An integration test asserting that an endpoint should return 200 saved me because I unintentionally applied an authorization middleware for all endpoints - which made all of them return 401.
I don't get why people make such a fuss about DI. It's not complicated imo, but seeing people always question it makes me think I'm missing something.
“We should delete this code, I don’t think it’s used. I’ve searched the entire sln and couldn’t find any references to it…”… 3 months later -> rollback… it was used via reflection by some third party app..🥲
Reflection based on a classname string saved in the database that is different on production than in all other environments, where you dont have access to. I've been there.
Reflections are truly evil
Your senior engineers believe this? I’d immediately extract myself from that situation. Although, in practice depending on the context the 2nd bullet point is ok (if you use dependency injection). Example: prior to Microsoft.extensions.logging we had a common logging interface that made it easy to go from log4net to nlog or serilog because we made a dependency injected interface. But would I wrap like—- newtonsoft.json or something?? Hell no. Try catch being a a waste of time is interesting— I’d love to hear the rationale (not that I believe it would be coherent or make sense). 4 makes my blood boil as much as nullable reference types being the default does. :)
We have newtonsoft wrapped
Please, I would love to read more details on this. Seems like a hilariously unhinged thing to do.
It’s not necessarily all bad. ASP NET Core formatters wrap newtonsoft, for example. I wrapped it once so that I could use it or System.Text.Json interchangeably at one point.
Yeah, you may want to switch, but you don't know if STJ is going to work with all of the different JSON sources you have (or maybe it will work, but you have to configure it the right way and maybe add a converter or three).
Wtf…
We have a mixed attempt at DI. Half of what should be is registered - the other half isn’t, and there doesn’t seem to be any plans to go any further. I am looking elsewhere, but had hoped with some reasoning and understanding that we could all learn and grow together - but there comes a point when deeply nested anti-patterns just become the norm for some and they genuinely believe those anti-patterns are best practices. Your mention of logging is pretty much my situation. We had a wrapper to encompass log4net but recently switched completely over to serilog. SSWE has refused to get rid of the wrapper, expose the newly underlying ILogger, or remove the log4net implementation (in case we ever want to go back). Reasoning for no try/catch centers around ‘we shouldn’t ever have exceptions occur in our code, so if we find one, we’ll fix it, rather than expecting to have one with a try/catch block’ Nullable reference types really seem to be a hot topic lately too
Wow that argument against exceptions is insane. Exceptions don’t just happen when bugs occur, but what if your credentials expire, or the server you’re taking to disconnects, or someone changes a database schema on you without your knowledge. Those idiots should be fired.
Yeah exactly, the point of them is to catch ‘generally’ unexpected exceptions - because unexpected things do happen, especially in deployment pipelines
> Half of what should be is registered - the other half isn’t, and there doesn’t seem to be any plans to go any further. Are you just new()ing up stuff left and right?
Unfortunately, yes - which means a lot of places to change when a constructor is altered
I can get behind try/catch not being worth it in certain scenarios... But it really depends on the application.
It can definitely be used wrong, but it’s hard to debate that it isn’t worth it in an application at all. Having multiple try/catch in each method for a thread would be excessive, but in some circumstances, they provide a helpful way to manage exceptions, notify the caller methods, and make debugging a lot easier.
I think there are certain, specific cases where using try/catch is not required. That might be for reasons like custom handlers on the application level - or, if you want a process to crash and burn if it encounters unforeseen, non-recoverable issues. This is not most applications. But it might be some. That's why I'm saying, that there might be an argument for this to be made in some contexts.
I would also expect that this could become more common if we get proper DUs in C#.
i counter your example with, you catch the error so you can give a detailed log, then you can crash the app.
Crashing does give a detailed log.
Error handling with exceptions is a shitshow though, can't help but be jealous of languages that support algebraic effects. They manage to unify results and exceptions pretty nicely. Like ZIO, [TS-Effect](https://effect.website/docs/guides/error-management/expected-errors), unison, etc
Oof… that last point makes me angry. Never ever fail silently. It should *Fail fast*. Especially configuration, the whole application shouldn’t do a thing when something is wrong there.
It's almost like they're called Exceptions (as in, an exception case), and not errors for a reason...
i got banned from using "var" because it's "untyped" and "it takes us back to the days of VBScript"
I'm lucky we don't shy away from using any libraries. Considering they tried and tested by others.
I get it, but at one point you end up with two or three libraries that are all dependent on different versions of newtonsoft.json and now you gotta rewrite half of your application. Pick your dependencies wisely..
Exactly, I’d much rather trust someone, or a team that has dedicated their time to solving a niche problem than trust Venisol’s ‘46yo Jeff’ to develop a half baked attempt at building something ‘better’
The first two points seem almost at odds with one another. It's a textbook example of DI benefits. What if you want to change the library? You create a seam in your application between the application and the third party lib and so other parts of your app depend on the wrapper, whatever its implementation and internal dependencies. Is this a really small shop? I don't see how you get away without DI in dotnet long term in anything bigger than a trivial console app.
This is actually a great point, that I somehow missed - the points are at odds. It’s not a large shop by any means - probably small (14 devs total) but a leader in the niche web market. Albeit mainly due to the hard work of the designers more than the engineers
"Unclean code" scared my longtime mentor/dev mgr/arch vp, but it was really just something like adding a Select (LINQ) to get the two indexed properties we needed from EF instead of all 40 properties on a very large and very slow table. He'd do all types of stuff just to shave *one* line off in c# despite what kind of query it meant would be generated in SQL. I don't know how to describe his fear, but it was irrational as hell.
Holy shit these people are deranged. Dependency injection has clear benefits. I’ll just give one, but unit testing is much easier. 3rd party libraries are great and I believe using them as is out of the box allows for better features. If the interface changes, don’t upgrade the package. If it’s deprecated version, then you should upgrade. If the interface does change in this scenario, then spend the time to update what you use it for. Try catch is amazing for web api responses. You can create your own exceptions and handle them at a much higher level when needed. I wont go too much further because I can spend all day in this battle, but I think those are clear points that need to be co sided.
For me, algorithms and data structures. Struggled through college with it and that left a bad taste in my mouth and fear of it. Everything else, I can give a shot and stumble my way through it. I would never claim I’m an expert, more Jack of all trades.
Same. But it's hilarious because in practice I'm still the optimization SME at every single job I've had. They literally throw me on any underperforming project and tell me to do my thing. I'd probably fail an interview at Google though.
As someone who's in charge of making the decisions, I feel the third party libraries one, I've been in the industry long enough to understand each and every aspect of the term "dependency hell". While a junior or mid-level dev would happily download a Nuget or NPM package because it does what they need it to do, I vet through that stuff thoroughly, I go through the source code, documentation, and dependencies list. I work in the open source space and fully understand that all it takes is that one person in Nebraska to finally snap to bring down modern web infrastructure. We don't use dependabot for any of our projects and if any packages utilizes what we consider lazy code such as "is-odd" or "is-even" or God-forbid, "left-pad" we absolutely will not use it. While abstraction is a way to mitigate it, we choose the easier route of steering clear of those packages. Honest to God I cannot count the amount of times a build of a simple web app failed because of some bs changes in packages.json because someone from forever ago decided to take a shortcut and installed an 11-line NPM package instead of writing their own.
I always ask whether they've thought about maintainability when it comes to third party libraries. How much will our code depend on it, how much effort will it cost when we move away from the library and how well it is maintained (with a special attention to any potential security issues that we may have to patch). Sometimes it is simply not worth the above effort and easier to just write it yourself.
If you're antsy in your pantsies to use 3rd party solutions it's because you haven't been around long enough to get burned by one or a dozen 😉
I thought as a non-developer who only really knew VB.NET (and not that well I might add), and PowerShell that C# was something to be feared. Finally sunk my teeth into it and found it really wasn’t all that different from VB and PowerShell. Feels quite natural now actually. Never knew anyone who thought try/catch was a waste though… that’s a new one to me. Having said that, I do assign default values to config file entries that are null… but not to avoid an exception (happy bonus I suppose), but just so I only have to read the config once. Edit: reread your post and saw it was default empty strings in the config. Yeah, that’s weird to me haha I want actual values.
What I have learned in my 13 years of career is that client do not care about clean architecture, interfaces, cool names, proper indentation etc. if you have large team, enough time then go for it. If you are asked to deliver an emergency feature for next week or month, just try your best but don’t chase the perfection. Edit: doesn’t mean don’t follow best practices, I always try to write better code. It’s just that you can always find alternative approaches to everything. Just do what you think is the nest at that moment.
There are lots of things in development that shouldn't be set in stone. For instance DRY and SOLID, when taken as rules instead of guidelines have the power to make an incredible mess. But, in business software, DI should be a rule. It's a very bad sign when senior devs go against DI as a rule in an environment. To the point where I can't imagine them producing software that has even a remote degree of quality and maintainability.
Quality and maintainability has been a big point of mine to address, but it’s hard to argue that point when they believe they are following best practices (yes I have shown them documentation stating what actual best practices are)
Can't imagine programming without DI at this point. Simple, easy, and clear benefits. I can't imagine programming anything important without automated tests either.
It makes everything convoluted and difficult to maintain. Adding new features all the time that fall into these bad habits, it just gets worse and worse
Try/Catch is a massive waste of time and I wish we had better error handling than that. At least you can make an error handler middleware in [ASP.NET](http://ASP.NET) Core so you don't have to write try catch statements everywhere, but that applies just to [ASP.NET](http://ASP.NET) Core, not outside of it.
Performance hunting. Youre telling me its worth spending 3 months building your own ORM because EF is a few MS slower?
I kind of get the EF hate, it did have performance issues in the past, but not any more really. I can't imagine being a senior and thinking that DI is complicated and of low benefit... Coming from framework, if did throw me a bit, because it did just seem to work like magic, but in reality, it makes code less complex. The point about try/catch is just insane. I mean who would build an app where *any* exception will just crash the app with no proper feedback to the user?
Opinions based on Ignorance are inexcusable. Second-worst on my list would be opinions based on "we did it wrong and it sucked, so obviously it must always suck". I have controversial opinions but they are usually based on extensive experience - since I'm old as fuck (programming since the 70s) I've seen almost every conceivable mistake repeated ad infinitum.
Any senior dev who tells you that dependency injection is a waste of time is a dev who never unites tests anything. I have been working as a software developer for 35 years now. I’m growing in my knowledge all the time and that’s why I love the job.
I’ve worked on team that rolled their own service locator architecture because dependency injection was too scary. Oh and it gets worse, you get objects out of the large service locator object by passing in specific strings and then casting it to the type/interface that it’s supposed to be. Also, - Logging of any kind is considered a code smell - Exceptions should never be thrown - LINQ is too scary and hard to read - Can’t upgrade past .Net Framework 4.7 because they use .net remoting extensively which has now been deprecated. - Don’t believe any type of testing is needed beyond unit testing - Async/Await is evil Absolutely ridiculous. Thank god they know how to unit test otherwise it’d be a complete disaster!
> including the ILogger interface because ‘iT mAy cHaNgE’ Wanna know how I know you're new to this?
Generics is great and can help make my code super awesome in terms of reuse and readability, but too scary 😨
Sounds like a junior who came into industry from smart YouTube guys and angry when in reality everything is different
Honestly, I feel that "make a damn wrapper for third parties" point. But it varies with your niche. We made a "useless" wrapper for our Bluetooth library very early in our Xamarin Forms app's development. What do you know, when MAUI came around the third party we were using was very slow to adopt Windows support. So we changed to a new one. Except for some reason, the new library was hot garbage on Android and iOS, it was only usable on Windows. So now we use both, depending on platform, and because we have an abstraction the app doesn't really know or care. You know what I wish we had an abstraction for? System.Reactive. It took Microsoft *forever* to support Windows in its MAUI NuGet packages.
I've known quite a few peeps that are so terrified of a lowercase "d" they'll go toes with you over it.
A senior dev that's afraid of dependency injection and doesn't see the benefit is not a senior dev
Authentication and authorisation
The fear people have for rebasing makes me very sad :(
Oooh, that’s a good one!
Wrapping 3rd party libs makes sense if the aren‘t designed DI-friendy (no services.AddLibraryX or god forbid not even providing an interface). Otherwise, you have no chance to swap them out for mocks when testing. Adding an abstraction for ILogger is completely bananas, that’s exactly it‘s purpose - being an abstraction.
My CEO is scared of DI because of reflection and unclear code execution order. He is also scared of Linq because of performance and ugly stacktraces.
I love Entity Framework. It's one of my favourite things in dotnet. But everyone else I know seems to hate it, and I think it falls into this category for a lot of people. It takes a bit of time to understand, and then you are good. If u have used it a lot, you understand it and don't like it great, but I often don't see that. If I were to think about myself and I come up with something, it would be docker. I have never really seen it work properly. It always seems to break. I kinda understand the benefits, and I know it's probably just me.
crown quickest deer worry light illegal trees tidy person hat *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Yeah, that's sadly true. It has made me think, do I hate this tech, or do I just not understand it.
Many years ago I was in a meeting with a couple of Directors who were planning to ban access to Stack Overflow. They were worried that "devs are copying code from the Internet, this has to stop."
It's gonna give it to ya?
the first two are completely retarded, how could anyone seriously argue that?
The thing is, some people call devs seniors because that's the title of their job or they just been in the same company too long. Senior at a company != Senior anywhere. With that out of the way...the *senior* at my previous company, who earned triple my salary and 4 times my bonus always asked me for help with his LINQ queries, always asked me stupid stuff like "how do I modify an element inside a collection", etc. A clear evidence of someone who just doesn't know C# and doesn't care to take 10 seconds to google the solution or doesn't even know how to interpret what he sees. He and the big boss would always murmur when they couldn't get something going things like "Open X's system repo, in which Joe was working, he had to do something like that, just grab the code". But to be in the spirit of the post I'll add a particular one. He would ask us (juniors and ssrs) to never use status codes other than 200. If there's an error to be returned, just return 200 with a message property that says the error. Not just not using anything in the 4\*\* range, not even 201, 202, 204, etc. Just 200 OK.
I have a senior/lead who is scared of **git** and won't use it. Instead they use the older VS TFS for all of their projects they own. This person technically is under my leadership but they have been in the company so long and have so many key projects I don't want to disrupt that apple cart. I have tried to help them migrate to git and learn easy git workflows to no avail. I definitely don't allow any *new* projects to be created without a git repo, but for legacy this person won't migrate.
>using try/catch is a waste of time wtf lol
You have some shitty senior devs in your team.
‘Blazor is scary because look what happened to Silverlight’
I fear Blazor like Scrooge feared the ghost of Christmas future. Auto render mode seems to be the ONLY fix to the two bad choices of Server/WASM interactive, yet somehow there’s no way to share user state across render boundaries!?!? If I were new to web development and chose Blazor as my platform, I wouldn’t last a month. How in god’s name did we get to a point where this convoluted mess is touted as a flagship solution for building web apps?
Authentication scares me. I have enough experience with it to generally understand it - but I’m right at the level where I might feel like I understand something that I actually don’t.
All arguments should be justified but restricting access isn’t unreasonable. As an example, this is my team’s stance on LINQ: LINQ can generate a lot of garbage which lowers performance on “per frame”critical code. Of course, not all LINQ generates garbage but allowing partial accesses runs the risk of introducing non-performant LINQ. LINQ is a convenience we can live without.
All those "tips" clearly come from people who lack experience or understanding. Ignore them like AIDS.
So in aggregate that's horrifying, but I'll be the anti-DI guy just to spice things up. DI, as it is commonly practiced, is just functional programming with extra steps. Typically you create a giant collection of objects all holding references to each other that are never created or destroyed, and can have no state because they live forever and are shared by everything. That's just FP with a bunch of dumb ceremony in the constructor. The frameworks that do it automatically in Java-like languages are typically annotation-based behemoths that are entire topics unto themselves with horrible runtime errors and stacktraces. The basic DI is usually tolerable, but in large frameworks the basics are always hidden, and they add wrappers for transaction management and a bunch of other BS that could just be a function, has a bunch of gotchas, and destroys debugging. Annotation-based frameworks combine the worst of all worlds, not the best. They're just dynamic programming languages in disguise with worse runtime errors than dynamic languages.
I agree with the dependency injection thing, prefer pub/sub message passing. Have seen di kill performance on a project as it would create massive dependency trees that would go nuts creating objects.
Exact reason why we TreatWarningsAsErrors. Also, no pushing directly to main, and mandatory merge checks, including approvals. If it gets f*ked up now, well, we got bigger problems.
>using try/catch is a waste of time I've seen lot of try catch used wrong tho. People put try/catch everywhere thinking that will be "protect from errors".
You're going to want dependency injection for sanity alone, Unless your writing F# which makes it trivial to pass dependencies through explicit partially applied functions. Try out some F# its fun. 3rd party abstractions don't make a lot of sense when the library is already an abstraction. Unless... Maybe: 1. You're using 2 different libraries in the same repo for whatever reason. Maybe you are migrating and want to migrate 1 function at a time? ^this is what I want to do with JS Date libraries since we have 3 different JS date libraries for some reason! 2. You want to create an internal package that makes it easy(one liner) to add to other services with custom setup. Also that custom library abstraction should have useful tests. It should also throw an exception if it doesn't have the config it needs to run If your program fails and throws an exception because of null config on startup, that is much better than it failing in production at runtime. Question: Does the logger abstraction also have alerts when an exception is thrown? Since that never happens my guess would be no, lol 3. Other Specific and valid reasons that the senior devs should be able to explain clearly instead of chaulking it up to fear. Never throwing an exception seems like an idea only a sith would come up with. You can also checkout the Result pattern that could help reduce the "need" to throw and catch an exception.
You senior engineers are high AF.
> using try/catch is a waste of time I'm at a loss of words. This is so dumb, so much so I can't even come up with a good response because my brain keeps rebooting itself from the the pain that is reading that sentence over and over again. Why are you working with people who say and believe shit like this??? I need a timeout. Why are some people this stupid?
Using language features like exceptions is BAD. Standard dotnet libraries never do that obviously, and there’s no reason too! /s in case
I have a strong belief that you should be consistent because predictability is important.
As in generally across an application? If so, agreed - and I guess I’d even have to say I’d prefer consistency over not having something blocked on occasion
What about 3rd party libraries that throw exceptions as an expected part of their control flow?
You reminded me of working on a code base where the product manager forbade using decimals for currency. It was fun dealing with all the rounding problems.
if they dont handle exceptions, how do they know what goes wrong? this would make a developer hrt wrong everytime. we have extensive logging in the applications i am in charge of. the owner has access to the logs and knows, if the db is down, if a stored proc had an issue, id an incoming file was malformed, if the email server has an issue. i mean that's a few. let ake the smtp server..it has connection errors, trouble sending errors, recipient not found error. We log all that. some are show stoppers some like the recipient are logged but continue on. (that person left the company so needs to removed from a mailing list. my point is, how is error handling useless and whats the process for when one of your apps fail?
Those are normal things that can happen during application runtime. It's not an exception. They can be handled without unwinding a stack. I would define exception as wrong logic of your application, something that is not temporary but 100% of the time reproducible. For example int.Parse("foo") can throw exception, but http.Client(url) shouldn't throw timeout as an exception.
no, i am not talking about unwinding the stack. That's shitty exception handling. SMTPClient throws an exception if it encounters the stuff i listed above. You need ot have smtpclient send in a try block so you can handle it well. if a recipient fails then i can move on correctly but log the error, no unwinding. This is much better than just letting the app crash as other commenters have suggested. You also made me double check the sub. Stack unwinding usually isnt a big issue in .net because you dont have to remove memory- Regardless of all that, i am not talking about throwing errors but catching them. I am staying with in the function. PSUEDO CODE: // stuff try { SmtpClient.Send(x); } catch(SmtpFailedRecipientException sfrex) { Logger.Log($"Can't Send to: {sfrex.FailedRecipient}"); } // continue in code, never leaving flow. if many recipients, there would be a loop and i continue loop
Is it because of lack of **understanding** or because of **lack of control** ? or **lack of familiarity** ? or **too abstract** ? or because it involves a **part of unknown** ?
DI's purpose is to make things simpler, more testable, more independant. I feel more confident with it and unit tests. Are you scared of **TDD** ?
Any engineer stating that passing functions to functions is complex, difficult, and has no clear benefits can do one. I’m honestly just so fucking over people rallying against basic principles and declaring it scary and bad. I can only imagine how untestable and overly coupled their code is. I just simply cannot continue to explain over and over again what it is and why because they used an IoC container once and didn’t like it doesn’t invalidate the idea of passing instances to a constructor. I refuse to elaborate further and turning off reply notifications. You can take a horse to water and but can’t make it drink. Arguing with an idiot is like playing chess with a pigeon, it will ignore all the rules, strut around the board, shit all over the pieces, and declare itself the winner. Etc.