jdevera

  Location: Europe
  Remote: Yes, exclusively, either in EMEA timezones or async
  Willing to relocate: No
  Technologies: Python, PostgreSQL, Flask, FastAPI, Elasticsearch, Docker, AWS, GitHub, C++, Java, MySQL + React, React Query, Zustand, Typescript, Styled components + Figma, Framer, Miro, Midjourney, Dovetail, ChatGPT, Lyssna, Hotjar, Maze, Optimal Sort, Mixpanel, Google Analytics, Tableau, Notion, Google G-Suite
  Résumé/CV: https://docs.google.com/document/d/16Uke75qskVTnbTZTEINHNZwYUtJowwjZvgSa5AQ6zrU/
  Email: [email protected]

We're a pre-formed team looking for a product company to join. We've all worked together at Hotjar, and we're pretty good at it! We're a combo of engineering management/backend-dev, product design, and frontend dev, which means we can handle a lot.

What we bring to the table: - Full-stack experience: We can cover everything from back-end architecture to front-end implementation and product design. - Proven collaboration: We've got a history of working well together and delivering results, especially in fast-paced environments. - User-focused approach: We are all about building products that users actually love. - We can help with strategic planning, team structures, and career growth. We also like to automate tasks.

Key points to consider: We're looking to be hired as a team, not individually. We're not a company, just a group of folks who love working together and have a proven track record of success. We want to work at a product-focused company where we can make a real business and user impact.

If you need a team that can hit the ground running and help you grow, get in touch! We’d love to chat about how we can contribute to your success.

Maybe you can cook something quickly with Spotify's Pedalboard: https://github.com/spotify/pedalboard

Native Spanish speaker here: it was very interesting to me to read this way of explaining the difference. I always thought about it as ”ser" for essence and "estar" for state, but reading the comments below made me realise this isn't fully accurate either, but I'd still argue it's closer.

I also use those. They came from here: https://eli.thegreenplace.net/2013/06/11/keeping-persistent-...

My point is that having 80 characters as a hard limit sometimes imposes some linebreaks that negatively affect readability. My mention of the screen sizes comes from the fact that the 80 character limit originally was set to fit the code in a 80x24 character terminal without non-explicit line wraps.

"Might" being the key word. You might, if you are writing a simple script, but if you are writing some more complex code, class and method already take two levels, and that is your base line, I don't see how having two more levels is a readability problem.

I see both points but regarding (2), there are common cases where you are not necessarily doing anything wrong but the 80 character limit will make your code less readable, especially when using four spaces or more for indentation. For example you might end up in the fourth level of indentation wanting to write a list comprehension that would be perfectly readable in one line but have to break it down because of this rather short hard limit.

I think having a soft and a hard limit makes more sense, if anything, I would make 80 characters the soft limit and perhaps 100 a hard limit, although I'd prefer them to be 100 and 120.

Why oh why the 80 character limit? It's the 21st century, screens are huge! I'm not saying let's put the limit in 300, but 100 or 120 is good enough to fit side by side diffs in one screen.