[joshxyz]

maybe anecdotal but in my experience there is no saturation in devs who are doing things properly.

im in a multinational company in a billion dollar industry yet our frontend code is reactjs without typescript, eslint misconfigured, stylelint not used, bad practices on use of react hooks, and many more.

there are teams and devs that are out of touch on maximizing what tools are available out there. im not even saying they are incompetent, what i mean is most are just unable to keep up.

[happytoexplain]

My perception is that the vast majority of employers are lacking either the will or the experience to recognize skilled developers and the value of their skill. In other words, skill depth is borderline meaningless in job-hunting, as opposed to skill breadth. Do you think that perception is exaggerated/pessimistic?

[willsmith72]

Skill depth is hard to test in an interview, and arguably less valuable in the long run for an organisation than other skills (communication, learns quickly, takes ownership etc.).

Skill can be taught

[joshxyz]

i think of it as being a character with stats

having depth in technical skill is maxing out one stat

but there are more stats

- how you communicate, persuade, negotiate, and sell ideas

- how you work with the team, how you navigate office politics

- how you meet your kpi's, how relative your efforts are in capturing business value for the company

sometimes it's not our technical skills that determine our satisfaction and dissatisfaction.

personally i enjoy my technical skills more when i work on my personal projects. pure enjoyment lol.

[nassimsoftware]

How would you go about demonstrating that you're a dev that do things properly in your resume?

Considering the code I wrote for work is in private repos, would you have to create an open source project to demonstrate this to future employers?

[bern4444]

Put the projects on your resume along with the associated impact.

In interviews you'll be asked about them. If you're not mention them or refer to them in your answers to other questions! Discuss your approach to the design of those projects, considerations, performance tradeoffs, how you approached testing, how deployments were handled etc.

Mention the tools you used that made a big difference - maybe swapping compilers led to faster build times and smaller bundles. Swapping test runners led to improved test times. Maybe you tried to swap test runners and that increased test times and so you went back to the previous one. Maybe you led an effort to automate deployments!

Discussing migrations from old patterns to newer ones demonstrates that you know what good tools are available and you know how to leverage them.

[jimmychoozyx]

"yet our frontend code is reactjs without typescript"

I don't blame them. I hate Typescript. Worked on projects at a major gaming company, no typescript necessary.

[frfl]

Of course your opinions are your opinions.

However, if the JS build system was actually sane, TS would be the default choice. It's a superset of JS, so saying no typescript necessary is like saying a horse gets me from a to b, no need for cars. TS is objectively better for many use cases and situation if you spend an hour learning it without all the build tooling nonsense getting in the way.

It's equivalent to a company using assembly when they could choose to port to C because assembly gets the job done.

[jimmychoozyx]

Eh, I just didn't need it.

I learned it but never saw the need for the extra overhead.

It's full of these situations. And I'd rather just see less code due to "Attention Economy" issues-- the more things to focus on, the less focus each thing receives. It's easier on the big picture, if there's less things going on. TS has a ton of terms and concepts that I just don't need to make my business logic work.

const cat Cat cat<T Cat> = cat

vs.

const cat = cat

dto? iterface? i can define those without typescript. Just plain objects with comments about what they do and what they are.

Anyway, yep it's just my personal opinion of course.

My opinion is basically... I think in some cases there's a desire to make things overly complex, sometimes even as a way to gate keep--

I'm not saying that's what is happening here.

But sometimes I feel that way about Typescript leaking into all of the Javascript ecosystem.

[frfl]

Fair enough. Idk who downvoted me, but based on your reasonable response, doesn't seem like it was you.

Ultimately, TS enforces those implicit comments you mentioned and adds some explicitness to the code.

Whatever works for you and gets your job done

But it's worth mentioning, TS with some of the strict settings disabled is basically JS but with some added benefits, primarily due to the TS type checker still being available. No need to go fully in, you can just as easily add explicitness and overhead where necessary and write JS everywhere else to avoid the overhead.

[jimmychoozyx]

Nah twas not I.

While working with TS in VS Code, I liked the intellisense of TypeScript + VSCode... it was able to piece itself together better than vanilla JS-- it predicted which objects, functions, or files I would reference quite well. So, I'll give it that.

I totally see a reason for it in the corporate realm of developer churn and in the vein of keeping projects very structured and stable. I might give it another go eventually.

For my own projects where I try to keep mental overhead low, and reduce focus on anything over than the main business logic, I prefer plain JS (e.g. within an ExpressJS or ReactJS project)

[joshxyz]

you're right i hate the damn overhead too.

i despised typescript for years until i tried it again recently. these days the developer tools are better.

prettier now formats it very well. eslint now lints it very well. tsx and ts-node now lets me run my ts files without compile step to js before i can run it with node. on frontend, vitejs has templates for react with typescript projects.

im a performance freak too, i currently use uwebsockets.js instead of express/fastify/hapi/koa. i wrote my own redis client instead of node-redis and ioredis. i fucking hate overhead too, haha.

i think my strongest preference on typescript stems from my frustration on very large projects. say thousands of commits every month, at that scale typescript really helps a lot in catching bugs before we even run our code.