> Better when you have experiences to relate back with.
100% this. I've been teaching software design since the 1990's and it's so much easier when the audience has enough experience that I can wave my hands and say "you know when things go like this ... ?" and they do, and then we can get on with how to think about it and do better.
Without that, it's tedious. Folks with less experience have the brainpower to understand but not the context. I try to create the context with a synthetic example, but (again, waving hands...) you know how much richness your current system has compared to any example I can put on a page or a slide.
I have a groups like feature requests and backlog for catch-all tasks. Then for deadlines I use "Mid January" or "End of January" and move tasks into them, based on a rough hour estimate. Story points doesn't matter because I'm not quantifying complexity across a team members. It's just me working on it.
I work on the tasks that have the highest priority, build locally, test them in a QA instance, and then ship them to prod. I usually run smoke tests in prod just to make sure I don't break something.
I used to use GitHub tickets and JIRA, but over time I needed organization that didn't cause a lot of busy work. For myself, Todoist (paid plan) works.
If I need to add members in the future, I'll go back to using GitHub (kanban, labels, milestones). Most likely my marketing team will need a Kanban before I add another developer.
Other notes:
Use tools that get objectives done and don't create micro tasks.
Finally, create tasks during off time like during lunch, while working out, or on a walk break. I generally plan 2-3 days in advance on the exact work I need to get done. Don't over work yourself.
Right now most chatbot widgets are scripted and require forethought from the admin or business owner. So it's pretty hard figuring out the comment questions on your own or formulating them over time. Even harder when you don't know your customer journey or haven't solidified the ideal customer fit.
This is exactly why I created a bot [1] that blends chatbots and Stack Overflow together. You can have an automated first-line support system without scripting or conversational dances.
- Instead of conversations, you can reuse previous question/answers.
- Instead of guessing FAQs, you can let your users define them for you.
- When questions don't exist, they get catched in the traditional support flow (email). Then overtime, this effort declines.
What's the value-add to using SSR React as compared to a framework purpose-built for server-side rendering to begin with if you're starting a "new project"?
Value-add is for engineers who use React day to day already or want to use a minimal API to work to build their UI.
Don't take my word. Checkout the popularity of React, it's proliferation into the marketplace, and it's use on production environments. Also Vue is another popular alternative that UI engineers like to use, which also has SSR.
>Checkout the popularity of React, it's proliferation into the marketplace, and it's use on production environments.
How is this a valid methodology to picking a framework for your web product for your new business / project? If the idea is to reduce training/recruiting/onboarding costs and sacrifice domain-specificity to attempt to utterly commoditize your developers, I can sort of understand that reasoning at larger scales. I just don't understand why a new business/project would choose this weird circumstantial path for new development initiatives.
I also don't understand why I can't seem to get any React enthusiasts to explain to me the business value prop of using React for a _new_ business started today. I'm only guessing that there are elements of cost reduction in training/onboarding/continuing education, but nobody will even go as far as admitting that much of it, let alone give a decent technical reason for using React.
Does all of this really just boil down to "It's javascript, and I know javascript. And not only that, but it's React, and I've used React before to work on this website that I thought was pretty cool, so I might as well just use React again because so many other people use it."?
I don't even think that is that bad of a business reason, I just don't get why people are so cagey about it and try to invent weird technical reasons for why your enterprise document store needs to have a reactive, fully-fledged javascript application running in the client browser just to show a document and expose basic CRUD actions.
This is what happens when you use a frontend framework and a backend framework.
EDIT: To clarify,
> as compared to a framework purpose-built for server-side rendering
If you use ANY framework purpose-built for server-side rendering, the second you need to do some client-side rendering you're now using two frameworks.
If you're raising 1M+ in the midwest, it's straight forward. Get a meeting with a VC associate in the region (Chicago: HP VC, Origin, OCA) and they will tell you exactly what they're looking for in a Series A.
I've never had any success with getting institutional money at the seed stage, but if you do get it, it's even easier to bypass some of the troublesome checklist items you get in the A round.
All VCs are willing to give you a checklist of what they're looking for. I've never seen a VC actually willing to fund solely based on a checklist of objective metrics. This doesn't change based on region.
