One of my favourite pastimes is to find ways to highlight what a mess JavaScript is.

New day. New legacy project that needs triage.

The project has existed since before 2000 so it all "works" and has no known business logic bugs. It does however have performance issues which sure I can have a look. It can actually be quite fun and rewarding to optimize performance.

This is a titanic dotnet framework leviathan consisting of over 12,000 cs files using razorpages, entity framework, and... nhibernate? I have my gripes with both EF and NH but they are both fine if used correctly, like any other tool. I've never seen them used together however.

As It Turns Out™, NH was implemented first and at a time when NH did not support async operations. It made sense if you look it up and it's meant to delegate commands via a separate layer, but different story.

Then for... reasons... EF came in and gradually took over.

Because of the way this is all set up, everything will faceplant if you try doing anything async, even if it has nothing to do with calling the db. Any attempt in making this work leads you down a slippery slope of having to rewrite the entire thing, which is out of the question in terms of their budget and expectations.

Sometimes it's a detriment when it works in spite of its issues.

Stop trying to fix n+1 lookup performance by piling on indexes!

Does it count as a learning experience if I have still not yet fully learned it? Then it's estimating tasks.

Fix this bug where the modal is rendered underneath the message-count-badge on your profile? Heh should be easy, 10 mins to set a higher z-index.

Final cost: two weeks, where I needed two status meetings and drawing on the whiteboard to explain why this happens and why it needs a major restructuring.

A couple of years ago I was working on a fairly large system with a complex (by necessity) access control architecture.

As is usually the case with those projects, it's awkward for developers to repro bugs that have to do with a user's accesses in production when we are not allowed to replicate production data in test, let alone locally.

We had a bug where I ended up making myself a new row in the production database for a thing I could have access to without affecting real data to repro it safely. I identified the bug so I could repro it in dev/test and removed the row and ensured everything worked normally, whew scary.

Have you ever walked into the office one day, and everyone is hunched over in a semicircle around one person's workstation, before one turns around to look at you and says - after a pause - "... ltlian?.."

Turns out I had basically "poisoned the well" with my dummy entity in a way where production now threw 500 for everyone BUT me who had transitive access to this post-non-entity. Due to the scope of the system, it had taken about a day for this to gradually propagate in terms of caching and eventual consistencies; new entities coming in was expected, but not that they disappear.

Luckily I had a decent track record for this to be a one-off. I sometimes think about how I would explain testing in prod and making it faceplant before going home for the day, other than "I assumed it would be fine". I would fire me.

6 hours of meetings and I can't remember a damn thing of what was discussed.

The task: Catch and log this specific error in this one function.

Me: While I'm here, let me just -

git: 12 files changed

Could people kindly stop trying to expand upon the native DI in dotnet!

This is my third project where "you don't just" add new services because you have to carefully conform to hundreds of lines of boilerplate while "remembering to" whatever it demands because someone spent weeks hacking the builtin functionality in order to make it easier and shorten the startup file.

I'm trying to swap out one of the implementations that are used by one other class via DI and so far I've changed 12 files. It's literally more work to do the thing DI is designed to solve compared to not using DI because they "improved" upon it.

Sure, it might be that I'm not using your thing correctly, but that's not much better, is it. Everyone already knows how to use dotnet's DI. Literally noone knows how to use your improved version aside from yourself.

I liked how one of the team members put it after one of the former devs apologetically explained how this was some long-gone dev's baby: The only thing this code does for us is that it needs a diaper change every time we deal with it.

You're kidding. You know how React, GraphQl, and Jest are made by facebook. You would think that Jest then would be framework of choice for mocking gql queries and responses for a React app. And you would be wrong. You "can, but-", depending on your implementation - ours being based on official sources - not without contorting and duplicating everything related to the query implementation at which you are barely even testing the app itself. We're using named imports from .gql files, for those familiar.

Don't you hate it when it turns out the guy going "nah tests were too hard, we didn't bother" was right.

Forced choice between two options which both seemingly have irreversible and potentially destructive consequences. Tapping back or outside the modal doesn't dismiss it. No 'Read more' type link for the first option.

Laws and regulations against dark pattern design when?

edit: okay the readmore link is passable but I still want to be grumpy about it.

Ever have to put your work on hold due to being called into a 2 hour meeting to discuss how important it is that we need this thing finished asap.

Ever have an issue you easily know how to fix while still having exactly 0 patience for it on a monday morning

One user could report that the data they saw didn't make sense. Turns out there was a one-off hardcoded caching detail for one of our services that cached based on a search query (yes, the entire query was the key) and before any auth checks. The system would return the results owned by whoever asked first, no matter who asked after that point.

There's "Oh dear but we all make mistakes" and there's surrender cobra. This is what PRs are for.

One of the biggest reality checks you will run into when starting your first dev related job - and which they don't teach you about in school - is that a lot of the time will be spent working with other people's code, and rewriting it into "your own" is rarely an option.

You might be super into making things, but not everyone manages to maintain that same spark while taking over a 15 year old project with fundamental issues that have to be triaged "for now" because you need a hotfix on this other specific thing out in prod before lunch.

There are no gods now. They left the company years ago and nobody knows why they used the windows registry as a user repo.

The bug: Some string values for an identifier property in the data objects are being sent from our frontend prefixed with a '0'. Sometimes. When it happens, it usually gets stripped away again by the time it's passed to our backend. But not always.

This 0 is never explicitly set anywhere. I even searched for a few variants of " = 0" in both the frontend and backend projects without receiving any results. You might already be suspecting where this is going.

So it turns out.

The data object which holds this value is being initialized in the aspnet (don't ask) backend and passed to the frontend, which then hydrates it. This value is always an integer number, albeit incidentally so which is why string is used as the actual type. When this object is initialized, it's hardcoded with an anonymous type where this property is set as int because I guess someone figured "it's always an int though". Being a typed language, primitive scalars can't be null objects which means the property's value becomes the concrete int 0.

Okay weird. I can think of better ways of doing this but let's just set it to string as I can't start overhauling things right now. Let's just go find where this value is somehow concatenated into the incoming parameter.

You see, this happens because at the point where the frontend sets this value, it may be an int or string depending on where it came from, and I guess someone figured that in order to cast it to string you just go prop += arg seeing as the prop is empty string and all. Because explicitly casting it or - as much as I get a rash whenever I see it - going prop = "" + arg would be too verbose and unoriginal.

Bonus round: How come the 0 only sometimes made it all the way to our backend? The thing is that this bug has been fixed before. The fix is that because this string is "always" an int, you can parse it to int before passing it to the backend in case it has leading zeroes. This path is only taken in certain views because someone forgot to copypaste their fix into all the places this is repeated.

Sometimes you find a bug and you are just somehow more grumpy after fixing it.

My biggest influence on coding style is working with other people's code. I know the temptation to write "clever" code and I've been (and probably still occasionally am) guilty of it myself, but it's not until you have to debug someones oneliner iterator which has !(i-j) as the stop condition that you start to appreciate dumb, boring, obvious code.

If having a series of if checks in a long list makes it readable, keep it that way. If it makes it more readable to rewrite it into a nested switchcase with a couple of ternary bits, go ahead. Just don't spend half a day wrapping it up into two layers of abstraction that will require an onboarding process for the rest of the team.

The Missing Button Paradox: The time it takes for a presenter to find a button on their screen increases based on the amount of participants who can see the button and try to help the presenter find it.

I've been using dotnet and aspnetcore for years. I've heard people complain about MVC but I never really saw the problem. The controllers are easy to set up for basic endpoints, I have my domain models and DTOs, and our views I guess is our standalone webpage just consuming jsons.

Only now I'm having to work with an *actual* aspnet MVC stack - server-rendered cshtml and all - and it's dawning on me like a truck what people were actually referring to.

Out of all the issues I've had so far, they have all been due to black box enigmatic voodoo because don't worry about it, the framework takes care of it - it should just work. But what if it doesn't? I have no idea because the trail ends at the bit that should just work.

I should know better than to criticize an entire framework and paradigm made by devs with vastly superior experience and expertise than me, and my issues are absolutely due to being new and unfamiliar with this, but imagine coming up with an architecture to obsessively separate the MVC concerns, then you make cshtml.

If I kept track of all the hours wasted on issues due to overloads of functions called ToList() it would probably make up a sizable portion of the project budgets.

If I call ToList on a query object, it looks like I'm trying to serialize the query definition into some kind of array. That's what it *should* do with that name. Bonus if the object implements some generic enumerable interface, ToList makes it call your database, you can just toss the query into some json serializer that blocks while calling ToList for you, and people end up doing exactly this because the code turned out so much neater.

Because that's the thing. It's like people implement it because it's "neat" and the user shouldn't care about its internals. How many tears would be shed by just calling it ExecuteAsync?

One of my first projects involved a python server. This was before I even knew about CD/CI, so we were updating by ssh-ing in, pulling, and killing the process.

My solution? Make an endpoint that pulls the repo and intentionally crashes the server to restart it. We used it for two years.

Okay, which one of you goofballs made IIS?

Not the worst, but deserves a mention due to how common it is.

Say your whatever object has a method called Configure. You can infer a lot from the configuration parameters or type that it takes, but for whatever reason something is unclear or doesn't work.

Tooltip from xml comments: Sets the configuration.
Official guide: Sets the configuration <br />.
Technical API reference: Sets the configuration.

I would create a support ticket explaining how this is unclear if I wasn't half expecting the suggested solution to be "you know what I mean".

One of my greatest personal challenges has always been to try and balance "good enough asap" and "but I know how to do this better if I spend a few more days on it". I like to think I've gotten better at it; Leaving things be if they are to spec and keeping my implementations consistent with existing work even if I disagree with it being ideal.

Which makes this new project we're taking over my trial of fire. The combination of the codebase - a Vue app from a previous rant where Vue is mostly used as a callback function to alter the dom using the document api in plain js - and the expectation for us to implement new features and minor tweaks to a user base of literally 4 people is like a charicature of the type of work I struggle with.

Even writing all this I'm evaluating if I'd be able to remake it all from scratch fast enough to sneak it in without anyone noticing.

It's an uh, "opportunity" for me to learn how to handle these situations, I suppose. Have mercy.

This Vue project I took over uses document.getElementById(...).innerHTML = stuff in its async created method.

That's the rant.

The adventurous world of javascript and typescript never ceases to amaze me.

I'm investigating some paths to take for migrating this legacy project which has incurred some technical debt. Because of... reasons... even the frontend Vue project needs to be built on a Windows system. No, you can take your hands down, even wsl or docker aren't alternatives here. It's a long story and ties in with said debt.

I'm keen on rebooting the entire frontend using a newer Vue cli and scaffold up all the essentials like eslint and typescript which is currently not used. This is gonna be sweet.

Except, typescript (BY Microsoft) doesn't play well on a Windows (BY Microsoft) filesystem because of a recent change to support - get this - wsl. I can't decide if it's hilariously ironic or genius.

This response about sums up my current mood. https://github.com/Microsoft/...

Of course, further digging in other repos like node only turns up issues closed due to it being on Windows' end.

So now my readme has a troubleshooting section describing how to make changes to your filesystem if you run into issues in Windows and I want to go home.

I was late with getting into programming and only started considering it after completing an education in animation before (unwillingly) working jobs outside of that field for a few years.

I had to really dig to try and figure out what I'd enjoy doing, and it's when I asked myself what I enjoyed about things in the past like railroad tycoon that I got on the track (eh?) of putting stuff together and making it work.

I remember seeing my friend play and I was screaming internally at his "who cares it works" solutions. When we later played ottd I would try to set up my stuff so that it was readable and because I realized how annoying it is when I can't figure out what my friend's tracks are supposed to do without asking him.

I was basically a developer all along. It's just that my only programming language was railroad tracks and signals.

My build has been lagging behind due to the 8 year old mobo, so I grabbed one with a newer chipset that was a bit discounted and oh jeez the swag that comes with it.

Who is the target audience here? 12 year olds who build their own pcs? This literally makes me - albeit marginally - less likely to buy Asus things in the future. Even teenage me wouldn't want to be caught dead flashing this stuff.

And yes, the mobo itself is rgb. I've literally stopped trying to avoid it since it would put an unreasonable limit on your options with how common it is.

Out of all the actions you could provide for this error.

The feature was to parse a set of fairly complex xml files following a legacy schema. Problem was, the way this was done previously did not conform to the schema so it was a guideline at best, which over the course of many years snowballed into an anarchy where clients would send in whatever and it was continuously updated per case as needed. They wanted to start enforcing their new schema while phasing out the old method.

The good news is that parsing and serialization is very testable, so I rounded up what I could find of example files and got to work. Around the same time I asked our client if they had any more examples of typical cases we need to deal with, and sure enough a couple of days later I receive a zip with hundreds of files. They also point out that I should just disregard the entire old set since they decided to outright cut support for it after all if it makes things simpler. Nice.

I finish the feature in a decent amount of time. All my local tests pass, and the CD tests pass when I push my branches. Once we push to our QA env though and the integration tests run, we get a pass rate of less than 10%.

I spend a couple of days trying to figure out what's going on, and eventually narrow it down to some wires being crossed with the new vs. old xml formats. I'm at a loss. I keep trying to chip away at it until I'm left with a minimal example, and I have one of those lean-back moments where you're just "I don't get it". My tests pass locally, but in the QA environment they fail on the same files.

We're now 3 people around my workstation including the system architect, and I'm demonstrating to the others how baffling and black magic this is. I postulate that maybe something is cached in my local environment and it's not actually testing the new files. I even deleted the old ones.

"Are you sure you deleted the right files?"

"Duh of course -- but let me check..."

I'm still on a regular basis reminded of how I might be wrong despite the absolute certainty in how obviously wrong the other person is.

Lately I've been working on setting up this API with a fairly intricate database integration. One request can lead to multiple db calls if we're not careful, so we have been polishing up the implementation to guard against ddosing ourselves and dealing with thread-unsafe concurrency.

Someone on the team could happily report that they got rid of all async use so there should no longer be threading issues. "You mean it all runs sync now?" "I guess. It works at least".

I'm just internally pulling a surrender cobra. If this was pre-dev me I would have let him and everyone know what a stupidpants he is and that I thought he had some experience in api development. But let's not make an exception to the rule; I might be wrong. I mean I'm not, but let's pretend I could be. Let's pull down the changes and maybe set up a minimal example to demonstrate how this is a bad idea.

Funny story. He got rid of explicit calls to the database entirely. When resolving data, the query is instead constructed virtually and execution is deferred until the last step. Our functions are sync now because they don't call the database, and threading isn't an issue since there's only one call per request context.

Thank god I've learned to keep my mouth shut until I can prove with absolute conclusive certainty that they are wrong. Here's to another day of not making an ass of myself.