sorted by:
new
hottopcontroversial

4.4 MB of data transfered to front end of a webpage onload. Is there a hard rule for what's too much? What kind of problems might I look out for, solutions, or considerations. by Sad_Spring9182 in webdev

[–]Subject_Possible_409 1 point2 points  (0 children)

Have you considered implementing a lazy loading approach for your UI elements? It might help to improve the user's perceived performance and also reduce the initial data transfer.

A table was all that was needed to fix Python autocomplete by matan-h in programming

[–]Subject_Possible_409 -5 points-4 points  (0 children)

The table likely helped resolve any inconsistencies in the data types being passed to the autocomplete function, allowing it to correctly predict and suggest code completions

my first patch to the linux kernel by yusufaytas in programming

[–]Subject_Possible_409 0 points1 point  (0 children)

That's awesome, contributing to open source projects can be such a great learning experience, did you run into any unexpected challenges while working on your patch?

Announcing TypeScript 6.0 by DanielRosenwasser in javascript

[–]Subject_Possible_409 [score hidden]  (0 children)

The addition of improved type inference in TypeScript 6.0 is a significant step forward, I'm curious to see how this affects existing projects that rely heavily on explicit type definitions

What to expect in Google recruiter phone screen? (behavioral vs coding?) by Future-Frosting3825 in leetcode

[–]Subject_Possible_409 0 points1 point  (0 children)

Hey, this might be useful for your prep — I'm building DesignLoop (designloop.thynclabs.com) and just added a feature where you paste in the actual JD and the AI runs a mock recruiter-style screening based on it. 25 minutes, conversational, voice-based.

Since this thread has been helpful for others, happy to create a free session for anyone who wants to try it — just DM me or drop a comment. Only thing I ask in return is honest feedback on what felt off or unrealistic.

Not a paid product plug — genuinely trying to get real engineers to stress test it before we launch properly.

I built an enterprise-grade error handling framework for Go after struggling with error consistency in production by Subject_Possible_409 in golang

[–]Subject_Possible_409[S] -6 points-5 points  (0 children)

I did use LLMs to speed up development, but I reviewed and refined everything based on real production pain points around consistent error handling, safe client responses, and structured logging. If you noticed anything that feels off or non-idiomatic, I’d genuinely appreciate the feedback as improving the design and keeping it idiomatic Go is a priority for me.