Hey Michelle! Hope you're doing well! I started with Codecademy maybe 7 or 8 years ago (well actually Dreamweaver more like 10+ years ago but that's beside the point). I learned HTML/CSS and some JS. The deep, deep intricacies of JS still elude me but I've learned more while using Vue and more recently React over the last 4-5 years. I don't know of a great place to start besides picking up HTML/CSS and starting to build things you want to try to build. It also depends heavily on your learning style. I'm happy to do courses/articles but can't stand tutorials or "code a task app with me to learn React" type content. So I think knowing how you learn and finding ways to embrace that is best. For me, learning to build the various iterations of Clinic has worked well since I have such a high motivation to just figure it out. I do use a lot of AI tools as well but I wouldn't recommend a beginner try them out. Once you have some experience it's a huge help to do the mundane, repetitive, and somewhat esoteric stuff, but if you don't understand the language/syntax then it isn't going to be a great way to learn. However, it will definitely help you accelerate once you know the basics - I rebuilt the entire Vue app in React in about 3 weeks using AI (mind blowing). The resources I'd recommend: www.codecademy.com/ - For the basics designcode.io/ - Designer-focused (I did this one too many moons ago) If you get into it and are a bit lost or need guidance feel free to hit me up on LinkedIn. Always happy to offer more specific guidance if you need it.

Oh also, I'd recommend trying to build things in a tool like Webflow. Since it's a visual builder you'll have an interface that will be familiar but you'll get to know the underlying mechanics of how the web works with regards to HTML/CSS/JS. In the past, I've skipped prototyping in Figma and just prototype in Webflow instead.

@@rbrtflyd thank you for sharing those resources and offering to help with more specific guidance! That's super super kind of you. I know some HTML/CSS already but I'm definitely still pretty new to it so I'll keep digging in there. I built my portfolio in Webflow! I've built a couple versions actually 😅but this is great advice, I agree that building in Webflow has helped me understand much more than simply designing things in Figma has. I also just finished a course on Maven called UI Engineering 101. They use Tailwind CSS in that (which I'm not familiar with) but it was a fun way to learn some foundations of basic component building.

Thanks for watching! I use a combination of Font Awesome and Heroicons!

I really appreciate you watching, it means a lot! However, I am not an engineer so I can't promise any of these things are best practice or industry standard. There are many more knowledgable people around here than I if you need that level of expertise. Best of luck to you!

Thanks for watching! In all honesty, I'm trying to find the balance between it and lower fidelity design methods. Loving the journey so far!

Thanks for watching! So far I'm pretty happy with React! I think it'll prove to be quite powerful over the long term and I'm looking forward to the day I can collaborate with people far more talented and knowledgeable than I on this front.

That does not even make sense, how does something become a foot gun unless you have a large amount of devs? React is a lot more popular than svelte for a reason.

Miss you too! Thanks for watching!

Hey there! Thanks for watching and for the kind words! Your question is a wonderful one and echoes a lot of the thoughts I've had as well. The Sync Engine as it stands is really just a file that queries supabase for the data that I need to populate the calendar view (since that is the "first" page anyone lands on). My goal is to expand it in the future to be a bit smarter about fetching the right data initially and then performing other async fetches to populate the rest of the data. It's also only one directional so I need to figure that out as well. However, this is all speculation and it's still very much something I'm trying to explore and learn more about.

@@rbrtflyd thanks for your detailed answer! I think this is a good approach for views that need pretty much all the data up front, like the appointments/calendar view you mentioned. I guess for anything else it might be either one of these two scenarios: you don‘t have much data, which leads to a fast initial load, but because it‘s not much data, loading data in general should be fast, so it‘s probably not worth the effort to implement a sync engine; when there is a lot of data where a sync engine would make sense, loading all the data up front would take too much time. I think a good approach would be to write a frontend caching middleware that intercepts all server requests and responses and saves all individual entries by their uuid. However this method would require all responses to share the same general schema and each get request to be split in two: one for getting all required entity IDs and another one to get the actual data. From the response of the first request, the middleware would be able to determine if these entities already exist in the cache and if their stale time has been exceeded.

Thanks Ben! It's been fun working through both.

Thanks for watching! I've been using TipTap since they were a very small team so I suppose there is a bit of loyalty there. I've learned their API enough to where I feel I can handle most challenges. TipTap is a block based editor too just a bit less showy about it I think.

Not right now but I appreciate the excitement!

The "Why I chose React" section in the video could be easily relabeled to "Why I migrated from Vue." I do think that Vue is a much better devex and easier to pick up. But I felt that if I wanted to be competitive with hiring at some point in the future, having the codebase be in React/Next would be the best/safest route. Also using shadcn/radix and some other libraries in React has been a gamechanger.

Thanks for watching! It's all home grown! I tried most of the major React calendar/scheduling libraries and felt none of them had the behavior/styling I wanted, so I hand rolled my own.

@@rbrtflyd It would be a great idea to release it as open source! The design is impressive, and I think you'll attract a lot of stars and potentially earn sponsorship revenue. Alternatively, you could consider making it a paid product.

@tomaszhofman7745 Now that is an idea! It would be quite a lot of fun! Although I don’t know if I’m ready for another project to maintain when I haven’t even launched this one yet! But I love the thought.

All very good questions! 1. CUD functionality is actually next up so I'll let ya know how that goes. 2. Sync engine is currently single direction and I plan to add bi-directional support at some point in the future. 3. That is probably worth it's own video once I get it a bit more refined. But currently the best way to describe it is as a wrapper for a few queries that generalize fetching a particular resource from a table. 4. I am gonna learn about that more as I do it more! No specific plan right now! 5. The calendar is all hand-rolled!

I am certain it won't be that seamless. But that's a problem for future Robert! Thanks for sharing that link. I've watched it a bit but need to dig in deeper.

I've got plans to release it in some form Soon™ but won't share much more at the moment. I guess at this point it'll be a race between me and Rockstar 😉

@@rbrtflyd ahah nice!

I appreciate you watching and your encouragement! If you'd ever like to give feedback/thoughts live, I'd love to chat with you!

Thanks for watching! A couple thoughts: "Specializing" isn't a one and done thing. I think everyone needs to adapt and change as the market changes. I know engineers who were super specialized in different subjects and went on to start companies in completely different areas. Just because you are interested in healthcare, that doesn't mean you have to only do healthcare. Healthcare is a meaty, complex, mind-boggling space to work in for everyone. Engineers who work in the space need to be ready to understand HIPAA, FHIR, and many outdated and difficult to understand data standards that they need to integrate. Interoperability is the name of the game pretty much anywhere in clinical healthcare tech. If you're interested in the space check out Brendan Keeler on LinkedIn/Twitter and follow his blog Health API Guy: healthapiguy.substack.com/ - I don't think anyone knows more about this stuff than he does. He's also a very kind human. Healthcare moves very slowly. I don't think traditional models of product building apply as well in healthcare. Move fast and break things is not a good model when people's lives are on the line. Buying cycles are very long in healthcare (often 2-3 years). It's extremely difficult to sell into enterprise healthcare organizations (big hospitals or insurance companies). So for a lot of people, it's not as easy as "I have a great idea and the ability to build it." There has to be a high level of clinical acumen involved in developing the solution. This isn't a bad thing! But it requires a lot of intricate human-level work that some engineers, product people, or even designers may not be interested in doing. As an example, I give many of the docs I work with my phone number so they can text me and I can send them thoughts. It keeps the feedback cycle shorter and gets me closer to the "right" solution. I also think patience is the name of the game. There are very few, if any, over night successes in healthtech. Last thought: "Healthtech" went through a boom and bust cycle between 2020 and 2022. ZIRP and Covid played together to make it really really attractive for companies to raise money. However, very few of those companies could make money and many of them closed between 2022-2023. That's not me trying to slam the founders or people who worked there, it's just an observation that for a time it was relatively easy. Anyone wanting to get into health-tech needs to carefully evaluate and vet the companies they talk to to understand not just the product but also the business and how they make money. I hope this helps!

Thanks for watching and for the kind words! I use Figma to do the designs but tend to copy them over to FigJam to present them as it's a bit easier to organize things one-off for specific videos.

I like his videos and his thumbnails are great, why should he change them?

Hi there! Thanks for commenting. I'm not interested. I quite enjoy where things are right now. Best of luck to you!

Thanks for watching! I use www.screen.studio/

Thanks for the thoughts and for watching! Definitely some good thoughts on UI improvements! So far those things haven't caused any issues with users but it's good to keep an eye on it!

I think we definitely need more product designers specializing in health and wellness products! Whether that is the only thing that a designer specializes in is up to them and their passion. Many of the things I've learned while designing in healthcare have been applicable to other industries as well. Your second question is a bit more than I can answer in a comment but I quite enjoy designing in healthcare. Since I'm also building my own product, I get the opportunity to engage directly with clinicians of all types and from all different areas of the care spectrum. It's a lot of fun and I always feel energized after talking with them and learning a bit more. I find that clinicians are discerning people and have high standards for their tooling. It's a fun challenge to meet :)

Just a prototype at the moment: demo.alloy.health/ But yes I do intend to ship it as a product some day. Either in this form or in another :) Thanks for watching!

If you're a course-taker, I can't recommend Sophia's Udemy course enough!

The n (n:n) notation is used to describe the relationship between two objects in object-oriented UX (OOUX). In this context, n specifies how many instances of one object can be associated with instances of another object. For example, in the 0:1 relationship between Patients and Messages, means that a Message can be related to no (0) or one (1) Patient. This notation helps in understanding how different objects in a system can interact with each other. If you're interested in learning more about this concept, you might want to look into Object-Oriented UX (OOUX). I work in healthcare UX and its really helpful to think this way when you're designing!

@@milkydropz Thank you so much for the excellent explanation and reference to Object-Oriented UX!

I will update the square to say CUD! Just for you!