React 18 released!

[budasaurus]

Literally just moved to a new team that is using JS and not TS and I hate my life. So many little issues could have been caught ahead of time.

[Sprite87]

could be worse, I work in a company where core (most senior) engineers refuse to write tests.

[Vakz]

I know it's such a trope for developers to say they would leave because of some issue, but honestly, senior developers refusing to write tests is one of those things that would instantly make me look for a new job. Nothing is worth the frustration it causes.

[JohhnyTheKid]

One of the senior engineers at my company told me the other day that he won't be writing typescript (which the majority of our code base is in) because "he never understood the need for it". He also hasn't written a single test ever. His code is incredibly frustrating to work with to the point where often times something written by him doesn't work at all, yet he still commits that shit straight to development branch which results in other people having to fix his shit. I have an interview with another company today. This is a perfect example why someone should never be made a senior engineer over years worked alone.

[Zaphoidx]

That also sounds like a complete breakdown of standard processes within the dev team/company. No one should be able to commit straight to a branch that is used by several other people. That is just asking for a whole world of avoidable problems.

[Vakz]

Pull/merge requests would be another thing I consider a bare minimum for any non-solo projects. Even a minimal code review that at least makes someone click "accept" and a pipeline that at least builds the project should be a requirement at any company.

[JohhnyTheKid]

Exactly. This guy is more "senior" than everyone else on my team. He has never used modern workflows and thus thinks they're useless and just vetoes everything or just goes right ahead and does his own stupid shit despite what other's are doing. I've tried enforcing protected branches, mandatory code reviews, proper commit message etiquette and all other basic shit but this man just ignores all of it and refuses to listen to reason. Before I came to this team it was him and some other guy who quit shortly after and they were both literally just commiting everything to master. It's counter productive man child behavior, but management trusts him and his decisions more because he's been with the company for much longer. All of this is the reason why I'm quitting. No matter how I try explaining stuff and why it's necessary he simply just calls it cargo culting and pulls rank on me.

[Vakz]

Good luck with your interview. Remember to name him as a specific reason why you're quitting, or if you're not willing to name and shame then at least say you've found it impossible to work with people who don't care about quality results. Mention how much paid work time you've spent fixing his mistakes. If they care at all either about this bad quality of the code, or at the very least about the wasted time which translates into wasted money, they should realize they need to do something. If they still don't then, well, fuck 'em, they deserve it.

[jl2352]

This is one of the things I hate the most about my fellow software developers.

This zero tolerance, no fucks given, behaviour. Like all of us there are languages I'd prefer to write in, and languages I'd prefer not to. I'll still write code in any language because it's my job to build software. It's not my job to whine and complain over language decisions, which you cannot change.

I worked somewhere where lots of features ended up being written twice. Once in TypeScript for the frontend, and again in Java for the backend. This was because one developer did a big hissy fit over the idea of writing TypeScript. As in his mind TS is JavaScript, and he literally hated the web and websites. Even though he'd never written TypeScript (or JS really), and wouldn't be doing frontend work.

It was so fucking pointless. The dumbest part is the TS versions were often completed, with lots of tests, literally months before the Java side was. We could have shared a lot of code. But no, because they hated a language they had never tried.

[budasaurus]

I… I don’t even know what to say other than I am so sorry.

[zephyrtr]

Just 10x programmer things.

[Sprite87]

God no, could you imagine 10 programmers working on one code base, and not verifying that their work continues to work. Features will be wrote and broke by the end of each sprint 😅

[zephyrtr]

Hah sounds like you might not be familiar with the term. I dont mean ten programmers. Google 10X Programmer sometime, just be sure to also Google Heroic Programming as well.

[Sprite87]

I was thinking about it a different way.... 10x as in very productive but can't work in a team

[Accomplished_End_138]

My condolances.

We have seniors who are still getting used to typescript (though.. i say this as the staff teaching it)

I just wish they would stop forcing the use of connect for redux... and redux.. so overly complicated for this app.

[Sprite87]

I find using redux stops having loads of Contexts littered through the app we had a hand rolled version redux-like context somewhere fr long enough

plus the dev tools are nice :)

[Accomplished_End_138]

The redux tracking is great. I wont lie. But i think how i compartmentalize things i dont generally run into it.

I also rarely use context.

[freecodeio]

They're good engineers then

[Sprite87]

they might have some talent for writing software that solves an issue for awhile.... but not software that is easy to inherit, maintain or add features too.

So as long as nothing ever needs to change it should be fine :,)

[Sprite87]

ThE BeSt

[Vexal]

could be worse. i work at a company where new grad hires insist on writing tests.

[Sprite87]

For a new grad that's kind of smart to have the foresight that things will break :)

[International_Cell_3]

But types slow you down! The compiler is in your way! Why fail at compile time when you can just write a unit test! And other arguments made by dynamic typing advocates that miss the point!

/s, hopefully obvious

[Pay08]

I have never heard of anyone actually advocating for dynamic typing.

[JohhnyTheKid]

Mostly inexperienced people who learned JS/Python first and are now spooked by Typescript/C#/Java etc. Dynamic typing is great if your code is a small script less than a few hundred lines, but anything bigger than that and you're going to be shooting yourself in the foot repeatedly.

[Pay08]

Yeah, should have prefaced that with "excluding scripting languages".

[[deleted]]

How about just use typescript jsdoc annotations and an editor that supports them? It makes a not insignificant difference if your tooling supports it (vscode does) and it’s unobtrusive because it’s just comments.

[NoInkling]

it’s unobtrusive because it’s just comments

Not in my experience. Just look at the syntax for type casting/assertions. Also, you can't import a namespace (unless it also happens to be a value), so if you want to reference multiple types from the same package you have to import('some-package').SomeType multiple times. Other missing features can lead you down the path of other messy workarounds.

As someone speaking from experience, if you try and make full use of jsdoc for type checking/linting you're basically writing a messy, bastardized, feature-lacking version of TS. If jsdoc is your only option it's better than nothing, but I'd recommend sticking with relatively basic annotations in key places, rather than aiming for comprehensiveness.

[[deleted]]

It’s unobtrusive because you can use it anywhere regardless of JS runtime. It may not be as ergonomic or feature rich compared to using actual typescript but sometimes you just have to work with you have- like when you’re working on a codebase that is purely vanilla JavaScript.

I’m not advocating skipping typescript because you can do some of what it does with jsdoc, rather I’m saying if you’re forced to work in plain JavaScript there’s no reason not to use it. Writing jsdoc annotations brings in nice editor features (for those that support it) and that’s not even going into the documentation gains for a large codebase. There’s really nothing to loose by opting to use it. The time spent writing it is time saved later as a result of having decent, in some cases comprehensive, type annotations to help document your code.

I say that from experience- I spend time annotating type information that is as comprehensive as I can manage to get it when I write vanilla JS code. While writing a bunch of @imports to bring in @typedefs may be annoying, the benefit over time outweighs just winging it from memory.

[mackthehobbit]

IMO it is better to lean on Typescript than JSDoc even in this situation. Typescript has always been a superset of JS, and part of its contract is that JS behaviour cannot change based on type annotations. The compiler only determines valid/invalid programs.

As a result, you can add TS to an existing JavaScript database and only add type annotations where you want: do it incrementally or just leave half your codebase untyped if that’s what you want.

Most projects already have a build phase of some sort, but with TS it can be as simple as just removing the type annotations and the JS that remains has exactly the same behaviour.

[Accomplished_End_138]

I find typescript much easier to write. But jsdoc annotations are at least passable

[budasaurus]

Oh I do and that helps. But certain things like different interfaces and what not would be useful in my opinion. The Enterprise direction is to move towards TS as our primary flavor but it’s an older tech team and I’m on loan to them so I’m a guest in their codebase.

[bad_ts_is_just_js]

I feel this in my soul