Hi, I have an idea of an application, I'm excited about it, I'm a junior, I'm good with my stack so I have no technical problems, the problem is, h...
For further actions, you may consider blocking this person and/or reporting abuse
You could use what are called "user stories" to generate a list of things that need to happen to bring it to life without having to nail every single thing down beforehand. Think of a statement "As a <role> I want to <action>" which applies to your idea. Add it to an issue tracker like trello or just write it down if you don't want to set up infrastructure just yet. Build up enough of those that you can get going. Add more as they occur to you. If it becomes more than a side project and you start working on it with other people look into agile methodologies such as eXtreme Programming (XP) and Scrum and adapt as necessary.
Epics and User stories are two topics I feel I am weak with. Really need to spend more time learning about them. I tend to just grab a note book and start jotting everything down from class structure to database tables. Then I quickly become overwhelmed. Going to start trying this out. Hopefully I will get more projects done.
Nice answer. I also recommend Lean startup techniques to validade If users would buy your product and the lean inception agile technique to really get to know your product, what it does best, how is it different from the competition, and how to choose tasks and prioritize them. The point being: don't build it before you validade that users are willing to pay for it
Caveat: this is only relevant for the sorts of projects where you want to sell the end result.
Thanks for these valuable tips, very helpful to start a project without distraction
Dont get hung up on the details right now. Get a prototype done as embrace the mantra of "perfect is the enemy of good". You will learn more by actually shipping something, even if it is very flaky.
Thanks Chris!
This is how I do it. There's no substitute for excitement, so during the initial excitement about the project it's good to quick-code a whole bunch of stuff that you can refine later.
The best advice I could give is to start small!! We all know that you have the most amazing idea that will allow users to launch themselves on a rocket into space (or whatever) but before you can build a rocket ship you have to build a skateboard. Try to identify what your "minimum viable product" is--the simplest version of what you ultimately want to build. Keep a separate list of features that you want to add, and your product will grow organically over time. But start by focusing on one thing! After all, it doesn't help you to have an app that users can almost log in to and almost invite their friends to use and almost etc. It does help to have an app that does one thing really well, and grow it from there.
This! I find that it’s easy for me to get overwhelmed trying to do too much at once. Simplifying helps a lot. Sketch out one feature. Implement that one feature. Rinse, repeat. :)
This answer definitely resonated with me; sometimes you just need someone to put the words in the right order. Thank you.
I always start sketching and building the UI. It becomes more and more clear what needs to be done on the backend to support that UI with the required db and other code.
The most important thing is to not get hung up on details in the UI dev like shadows or background colors. Also things like profile pictures, I usually just put placehold.it there.
Good luck with building your app!
Thanks, I like this idea!
I usually start building the core feature without even thinking about the whole app with user authentification etc.
Once the core feature works, I quickly design a landing page and the few screens I need to allow users use the core feature (I use Sketch for this). Then, I create a Rails app (you can pick up the stack you prefer here) and build the app according to my sketch design.
My philosophy is to launch as quickly as possible the first version of your app. Then, you can iterate and talk to your first users in order to make it better.
I'm fan of this philosophy too 👋. Thanks!
Start with a very simple domain model as a strawman to help you understand and iron out the first complexities of the problem you are trying to solve. If you can explain the structure of the idea it will make it much easier. Then as Dian says start to break that model down using user stories or feature lists. This will help take that domain model to the next level.
Once you have that in place, focus on the problems that don't have easy answers. This should be obvious now that you have a model in place as they will be the parts you are struggling to describe. If you sort these first you won't get caught at the end with an unfixable problem :-)
Hope that helps...
Thanks, this will help me begin the project without distraction.
this might not work for you, but it works for me since my thinking is very unconscious and loose and unstructured.
i think first about what i want to do. i then try to put it out in front of my eyes hypothetically to see exactly what the user should see. for example, if im writing a REST API, i will write out a few endpoints and responses on my whiteboard e.g. i will write
GET https://app.io/resourceand then underneath it writeas a json response.
if i want to write a react-powered ui, i might first write it in vanilla js and write really specific functions to get it done. if it involves a
<Modal text="bla" link="bla"/>i will write an onclick declaration in a button and everything to simulate it.its similar to what other people do. empathize with the user!!
what this has to do with me processing things unconsciously is that as i do this kind of work and force myself to work in limitations, scoping, or goals, i end up churning smaller details more effectively, such as what kind of data type to give a particular piece of information, or what headers to respond back with, or if i should use Oauth2, or whatever. this is very efficient because im working AND mulling over something at the same time
Assuming that my idea is too complex to be solved just by myself, and I would need to gather a group of other people in order to even start, I would be interested to hear how I can protect my odea from being stolen and taken to some other more powerful company. NDA? PoC? It is not only about how we start but how we start wisely.
That question is a good candidate for #discuss.
I was actually going to write this.
dev.to/allanjeremy/but-what-if-the...
Feel free to join in the discussion
Just a small tip that I like to do, I tend to rely on Trello to keep my user stories organized. I can access it anywhere and can easily keep track of what is finished and what needs worked on.
Edit: Just saw someone else just recommended Trello, did not intentionally repeat the idea.
I love using story maps. When done properly, they literally lay out a product and development roadmap before you. I was going to describe it in my own words, but it's probably best to quote a great article on the subject:
Another very important guideline for early-stage projects, is to have a strong understanding of why it's worth implementing specific features or doing things a certain way. Usually it's easy to justify this why (or why not) if you've done the research :).
Paper + pencil = start drawing bubbles that are features. Build a dependency diagram. This helps to show you where to start building and what the important parts of your application are.
The more you plan, the less you re-program. Some papers I have read state that planning and validation should take approx. 30% of the project total initial build time.
User stories are a good start as well.
Copyright the idea first, for legal coverage; then talk to target users and get feedback.
Research, has anyone do it already, or anything similar?
Don't get stuck on 'it has to be perfect'. Get is done. Having something done is better than a billion best wishes.
@ think about the flow of your idea (quick and general)
@ draw it! (Don’t think about the details yet)
@ start build the ui.
@ keep track of the activities that you do, and the pending things.
@ create a prototype. And another but better, and another but better... and so on, you get it :)
Start messing around and putting together what seems to be the basic stuff, start getting lost in all things you found you don't yet know, decide that you need a different stack, rewrite everything, spend a month getting authentication down, write those user stories in the meanwhile because smart people told you so, get completely overwhelmed, continue working on three different things at a time because they are all connected to one story, get some people on your team, change half of the stack again, write down all specifications, let some test users in, fix bugs for a month, rewrite half of the code............ in a year you will be far from a junior developer, that's for sure. Don't be afraid to make mistakes. Good luck! :)
I like to break any project into 3 steps: why, who, how
Why
Why are you building the project? Determining this in advance helps you to maintain the motivation when you feel side tracked/bored, which will eventually happen.
Writing this down and reading it when you feel like quitting can help reignite the initial spark/feeling.
Why would anyone use my product over another? (This especially matters when you are creating a product to be used by others and helps define your competitive advantage). Plus it helps you innovate more. In the case of a portfolio website, this could be asked as: "why would they choose me?" Or better yet "why do I stand out?"
Who
Who would use this? (Again, matters if you are creating a project for someone other than yourself to use). In the case of a product, this is also where you determine your target market. There can be multiple usrt groups that serve as your target market. For example, an ecommerce project may have buyers and sellers as your target users. You will then write two different sets of user stories.
This part helps you determine the features you need. You can then write user stories based on the target users you have discovered above. In the aforementioned example, we would have two sets of user stories. Where the buyer and the seller interact, we can try to optimize for both but in individual cases we can optimize for the different target users
This really helps you from having unnecessary features
How
How will you build it?
You figure out the architecture and design of the software you are making based on the previous steps.
This is where you pick a stack/tech to use. Guessing you already figured this part out, seeing as you already have a stack.
Finally
You have done ample planning & figured out how everything is generally going to work before writing a single line of code.
Anyway. This is where you create your MVP (minimum viable product). Get your product out in the hands of users (if any) as soon as possible. They will guide your future iterations
Remember that your assumptions about users may mostly be wrong, so don't waste too much time building an overly complex product behind closed doors
Could write a lot more on starting a project (might as well convert this comment into a post) but this is simplified and seems to work.
Tools that can help
Only mentioned a few that have almost no learning curve
Google keep - user stories/taking notes. Free
Trello - planning. Freemium. You can use it for free and can pay for extra features
Bootstrap studio - rapid ui prototyping. About 25$ for an annual license and 60$ for lifetime
Adobe XD - UI/UX prototyping. Supports mobile prototyping
@ben Notice me senpai
I usualy carry a notebook with me. I write all ideas i have for my projects. Don't make this hard and something that you have to do. Make it a game, plesure something fun to do
Th here are tools for quick prototyping an idea. Take a look at this one maybe: justinmind.com
Thanks all for the great tips, really appreciated and helpful!
Hey bro! Really inneed of suggestions for this post. Ping me if you have found a solution for this!!!! Really desperate to own a content for me!!
Mind Maps come to mind.