Wait until you start groaning involuntarily when sitting down.

This happens all the time, and what other people are saying is right: It's perfectly valid to declare it as unmaintainable and communicate that the alternatives are to either invest time into fixing it or that it will continue to be a time bandit that easily breaks.

In my experience, this often comes down to the rest of the team simply not being aware of the state of things. In this case it might even be your responsibility to raise the issue.

We're all stuck with js. Trying to convince someone that it's bad won't change anything. Just use ts or jsdoc with checkJs:true, and learn to avoid these pitfalls.

Also, arrays can have properties.

Phase 1: Learning about the concept of testing
Phase 2: Thinking everything must be tested and people who don't have 100% coverage or only develop in TDD are dumb
Phase 3: Oof we lost control of our insanely complicated and bloated tests that need you to mock http contexts and a particular database vendor so we haven't used them for 5 years
Phase 4: Let's just write useful, simple, maintainable unit tests for the important bits

The trick is to not slip back into 3 when you thought you were in 4.

I once got in touch with the maintainers of an API that did this, and their response was essentially "Rest is useless because nobody follows it". It's sort of poetic.

Rust as a language is fine, but I haven't found a use case for it to write shippable production code when comparing it to the alternatives. Woe the junior who has to fix an api made in rust 8 years ago because the new VMs can't run it after updating the CICD makefile.

I occasionally have this thought as well for development environmens in general, but the steps required to make it work far outweigh the benefit. It would be portable, but only for hosts that have been set up to accommodate it. Compare this to a vimrc dotfile that you can have at a public url and polish over time.

I did sort of do this for a project that needed a very specific version of node and python, and I didn't want to start messing with nvm and venvs. One of the issues I ran into was that the editor was not able to connect to the language server as "localhost" in a docker context can be ambiguous, and it was more than a day to make that work. I was also not able to clone the repo from the container as the repo is only accessible from vpn, and it was not obvious how to allow the container to use the host's virtual network device. I ended up cloning to the host and setting that as the remote from the container.

This is all fixable and viable if the requirement is there, but it's not a way to streamline a general way of making IDEs portable.

That all said, it's still fun and a good incentive to learn about docker if that's your goal.

We provide solutions for customers

As long as they trust that I'm working to fix it asap and I can tell myself that it's going to take as long as it needs to, it's fine.

If I can't work because I am being continuously told how important it is to fix this thing until it is fixed, I switch jobs and it's also fine.

Common, but definitely not ideal. We have this problem on small/medium projects where the people who have worked on it the longest feel they don't need to be reviewed, so this becomes the standard for others as well.

Aside from the obvious sanity checking, my justification for needing a review process is how it makes it safer to suggest changes. If you have people who are anxious about causing issues, they might spend a ton of time trying to make their trivial fix waterproof when they would otherwise push it right away for someone to LGTM it.

Ask them to make the site a little more modern

I've had to integrate with an api that replied with jsons that had duplicate properties, but that's pretty funny how it's not even syntactically valid.

For our case it worked on accident as long as the correct property occurred first as that's what the library would parse. When we mailed them about it they wrote us a guide - with code snippets - on how to fix it using string replace before parsing it. Bonus how it would break if they ever got rid of the duplicates.

I can't resist being the first to mention that this is usually due to the analyzer skipping lines with certain symbols, or getting confused about lambdas broken up over multiple lines.

But you already know this and I still groan at this myself since it still becomes unclear which line it's actually pointing at.

As we love to say in this field: It depends.

ideally I'd try to find the reason first. One thing I've noticed after the pandemic is that some people just don't function as well alone. It's not that they are slacking, they just benefit more from being in an environment that provides momentum and routine.

Or they could be hating having to work with IIS and jquery and it makes me feel like I'm stagnating.

I'm responsible for one smaller elmish project that's built in blazor. It has its advantages, but it's still way too early to justify for larger, long term projects.

The overall bundle size is and memory allocation needed to perform rudimentary html update/render tasks is in the order of 100x compared to vanilla js, though actual performance and cpu usage is on par.

Debugging it is a nightmare since it's hit and miss if you can attach to the wasm process and if it manages to map the compiled app. On several occasions we have had bugs after compilation due to flakey optimization; skipping an array copy, reusing a reference that we explicitly clear, that sort of thing. Hot reload breaks easily and we sometimes just live without it for periods of time.

I'm clamoring for an alternative to JS for webapps as much as anyone else, but blazor and wasm in general just isn't there yet. I hope it will be one day.

My first job was fullstack, and ever since then I'm that guy who can take over that project from the person who is leaving or has already left.

It's definitely love/hate. It's fun to just get this entirely new stack in your lap and be exposed to not only new tech, but new methodologies and practices that keep you from slipping into that "my way is the best way so I have no reason to learn other ways" bubble. It's why I am a religious follower of keeping things not only simple, but as standard and default as possible.

The worst part is definitely when there is an expectation that because you've worked with tech X before, you should be able to hit the ground running for this 6 year old monolith project that uses X version 0.103-preview with thousands of lines of custom unneccessary indirection and a dependency on the windows registry. Now give an estimate for this new feature without sandbagging it.

@tosensei We considered it, but their requirement was vague where they sort of wanted a generic search endpoint. You can query multiple types on it, it's just never used that way.

I rant because I love my job and want to produce quality work

This stuff is one of my greatest pet peeves and I had two cases like it the past few weeks.

I was setting up an integration on a server controlled by a third party, and I immediately notice the port we need (and which we told them we need) isn't open. Keep in mind that we are logging in to the VM and have full control of the machine itself.

Two weeks. I spent two weeks PROVING that the port wasn't open. 5 people were in the mail thread asking me if I was sure I did it right, if I'm typing the password correctly, and if I'm connected to the internet.

I am very particular about always being in a problem solving mode and not involving emotions, but it's times like these where I seriously wonder if things would get resolved faster by cussing people out, or using caps to highlight sentences they missed in my previous mail.

I started my bachelors when I was in my 30s, including a couple of years where I had to basically redo high school since I dropped out.

I don't know what the culture is like over there, but here in norway they are screaming for devs of any skill. Being able and willing to figure things out weighs more than an existing skillset.

I would maybe look at creating a simple (and I mean bordering-on-pointless grade simple) project which you could point at and talk about during interviews. Imagine having two candidates with no experience, they both say they have a passion and an eagerness to learn, but one of them made a basic react app hosted in some cloud service while expressing curiosity, not mastery.

Anything that's not default just ends up being a chore to maintain and keep consistent. I'll eat my words if I see a 7 year old project with commits from 10 different devs where this formatting was kept consistent and provided tangible benefit at no cost.

They still missed one of my favourites!

The benefit is if the consumer applications have wildly different and unpredictable requirements, and your data is composed from different sources.

In our case we had a larger company with their set of 30+ consumer applications that were fetching data from us. Some of the data was in our local database, while some had to be fetched via queries in realtime on demand. With graphql we could just assemble this as needed, of course taking care to optimize the queries with caching and making sure the database is queried as few times as possible per resolve via joins and projections. It varies how well the different libraries help you with this.

It's completely pointless if you are consuming from your own dataset with 1 client and the datacontract rarely/never changes.

I message coworkers on slack about stuff as a means of personal notekeeping. I have an agreement with a couple people where we do this almost as a form of rubber ducking.

If I have to run in the middle of a change without wanting to commit or stash I might leave an #error TODO or some intentional syntax error.

Trick question because it depends on the context. Posix/unix time is ideal for sorting and agnostic storage.

I have never seen mongodb be a technical fit as the main/general database for a larger solution. I can envision scenarios where it's a better choice for specific data within an application, but at that point you may as well just make a table with a json column in your existing db.

I have had good experiences with mongodb when eventual consistency is ok and we have a ton of r/w to the same "table", but the tradeoffs always bit us in the ass in a people-want-off-the-project kinda way.

Deep objects was one of them. It only takes that one change by someone who doesn't know it's a bad idea, and reversing it after it's released is a much bigger task than implementering it.

Honorable mention to how you can try to enforce a schema, but one day you suddenly have half your _ids as objectid and the other half as guid, either in binary or string. Try to explain to whatever management why you need to put everything on hold despite things working fine in order to fix it or this will be a permanent time sink to manage.

I worked on a project where this was done a lot. var result = arg0 + arg1; return result;

The reason was that it was easier to debug because then you could use breakpoints and look at the intermediate results.

I don't think that was a very good reason.

I had one interview where they wanted to test me on the pitfalls of parsing ints in JS, and I mentioned you should provide the radix as the second argument to avoid ambiguity, and to use IsNaN to assert the result since NaN is never equal to NaN. Then I got a little unsure about whether it was Int.Parse or parseInt, but wait JS/ES doesn't have an "Int" type, so I'd need to look it up. The interview would not continue until I could confirm my final answer without googling.

Maybe their business was focused on making web based solutions without access to the web. I don't know.

I love prettier and eslint. I love consistency and sticking to defaults above striving for a "best" ruleset.

But holy mother of god if for SOME REASON there is a mismatch in the rulesets between the two, or that ONE PERSON has a better idea of what's more correct.

If there's only a couple blocks like that then it's no big deal. If it's a large application where this goes on in dozens of files, you start seeing the benefits of some action/effect approach. Whatever makes it more readable and manageable; Good ol "it depends".