HN user

hyeomans

165 karma

Software engineer

Posts4
Comments74
View on HN

Location: Mexico Remote: Yes Willing to relocate: No

Technologies / Stack: Golang, Node.js with TypeScript, React, backend APIs, REST and GraphQL, Docker, cloud environments.

What I am looking for: Part time or flexible hours work. I enjoy backend development, API design, web applications, and full stack work when needed.

Website: https://hyeomans.com/ LinkedIn: https://www.linkedin.com/in/hector-yeomans

Why me: • Strong experience with Node.js and TypeScript for backend and full stack development. • Practical experience with React for modern frontend projects. • Proficient with Golang for building reliable and efficient services. • Focus on clean architecture, testing, and maintainable code. • Consistent, self directed, and comfortable collaborating asynchronously.

Feel free to reach out. I am happy to talk about how I can help with your project or team.

José Valim nails it: Remix's concurrent submissions have a fundamental flaw. Without causal ordering, you're stuck with race conditions and stale data, leading to poor UX. They need to rethink their approach or embrace causal ordering to fix this.

I understood nothing of what you said, what is a good resource/starting point to understand the meaning of this?

1x Engineer 4 years ago

Can't read the font, sorry. Here is the list:

* Searches Google, Duckduckgo, Bing, or wherever they like when they're not sure what's up.

* Copy/pastes code snippets from Stack Overflow, Glitch, Codepen, or wherever they find answers.

* Gives credit where credit is due.

* Creates community and shares knowledge.

* Spends time on things outside of engineering, like hobbies, friends, and family.

* Has a schedule that allows them to maintain a healthy work-life balance, and respects others' time-boundaries, too.

* Isn't measured by arbitrary contribution scores on any website, and doesn't judge others for theirs either.

* Writes code that &emdash; gasp &emdash; has bugs.

* Writes code that others can read.

* Reads the Docs.

* Updates the Docs.

* Doesn't need to be passionate about the code they write or the problems they solve, but may be.

* Doesn't act surprised when someone doesn’t know something.

* Is willing and able to collaborate with others.

* Willing to spend time and energy to help teammates get unstuck, when appropriate.

* Publicly celebrates others for their wins.

* Ask questions before providing critical feedback.

* Gives tough feedback privately.

* Treats others how they would like to be treated.

* Provides code reviews and feedback to their peers that are constructive, helpful, and presented tactfully, helping their peers to grow personally and professionally.

* Expresses appreciation for code reviews and feedback from their peers that are constructive and helpful.

* Sometimes feels hurt by critical feedback, but doesn't react destructively.

* Sometimes takes short breaks to clear their head.

* Makes mistakes from time to time, and finds growth in those mistakes.

* Willing to admit when they're wrong, and aren't afraid to say "I don't know."

* May or may not like writing documentation, but does it anyway for future maintainers.

* May or may not like writing tests, but tries to learn to do so if the team or project needs it.

* Thanks others for their time, effort, and energy.

* Can have colorful desktop backgrounds.

* Supports code in production, even if they did not write it.

* Can feel like an imposter at times, and understands others may, too.

* Believes that everyone in the room is equally as smart and capable as they are.

* Will help level-up others, and asks for help when they need it.

* Never stops learning, but can feel totally overwhelmed by the amount of learning there is to do.

* Tries to keep discussions productive and lets others have their say before the team makes a decision.

* Is willing to leave their comfort zone.

* Contributes to the community in their own way when possible, and appreciates the ways that others contribute when they can.

* Can be a slow coder.

* Has productive and unproductive days.

* Doesn't take themselves too seriously.

* Says, "I've never heard of that," in lieu of nodding and pretending.

* Is trustworthy.

* Works to live, rather than living to work.

* Sometimes loses their work.

* Doesn't have to have the entire codebase memorized.

* Respects and upholds community Codes of Conduct.

* May work from home, the office, a coffee shop, or where ever else best works for them.

* Doesn't hate on tools, processes, or languages that they'd rather not use, or that others are using.

* Is not defined by the computer they're using.

* May decorate their laptop and workspace in any way they like, and is respectful of others' decor (or lack thereof), too.

* Isn't defined by myopic Tweetstorms by clueless VCs.

* May have a lot of unfinished personal projects, or no personal projects at all.

* Doesn't riddicule entire professions within engineering, especially not when in a position of leadershi p.

I think people have already made their mind but if you want to share more information, I would suggest being 100% transparent and releasing any internal communication (emails/text/slack) about Bolt.

How to Lose Money 5 years ago

Yeah a lot of comments focused on courses, but they talk about how to make money with courses. “Build a following, then sale”