Explore our extensive collection of courses designed to help you master various subjects and skills. Whether you're a beginner or an advanced learner, there's something here for everyone.
Join us for our free workshops, webinars, and other events to learn more about our programs and get started on your journey to becoming a developer.
For all the self-taught geeks out there, here is our content library with most of the learning materials we have produced throughout the years.
It makes sense to start learning by reading and watching videos about fundamentals and how things work.
Data Science and Machine Learning - 16 wks
Full-Stack Software Developer - 16w
Search from all Lessons
Curated list of small interactive and incremental exercises you can take to get better at any coding skill.
Curated section of projects to build while learning with simple instructions, videos, solutions, and more.
Guides on different topics related to the technologies that we teach in our courses
The hardest thing to do in software is not coding – it is designing the system! And we are NOT talking about graphic design…we are talking about architecture, data modeling, customer requirements, etc. Some of those things are harder than others, but doing a list of requirements is probably one of the trickiest arts.
What is a Feature? It is a functionality that the application has! For example: sign-up, sign-in, vote, buy, etc.
Describing a feature seems easy, but it can be challenging: Where should you start? How detailed should it be? How technical can you be? But, don’t worry…"user stories" have come to the rescue!
User stories have become very popular as a feature-based-documentation-standard because they cut all the fat from the process. The are straightforward, easy to understand by everyone involved (not just the developers), and easy to test.
A user story is like having a conversation with your future user. They must be written in standard non-technical English for 12 year old kids with a low attention span:
13#### Here are some Examples:
It is so simple that it becomes tricky…the most important thing is to: (1) Maintain simplistic language, (2) Keep it short, and, (3) Specify:
As a [role], I can [feature] so that [reason]
Let’s look at another example:
Pretty easy right? However, in some instances we find that the "so that" suffix reads redundantly, so go ahead and make that optional, if you wish.
Feel free to use slight deviations of this template using synonyms:
There tons of tools; we have Googled some: click here to access. Some are free, and some cost money, but throughout the years we have decided to do them ourselves using index cards. If you insist on using something digital, you should use this document template that we have prepared for you.
The theory is simple – if you use any larger than a 3" x 5" index card, you will write too much. Likewise, if you use anything smaller than a marker (such as a ball point pen) – you will write too much.
User stories are suppose to be short and sweet. They are suppose to aid in further communication and not tell the entire long-winded version of the story. Sticking to these physical constraints will help.
At the end you will have a huge "to-do list," with the stories moving from "To-do" to "Doing" and, finally, to "Done." Each story will be assigned to one developer at the beginning of each planning meeting.
If stories are short and sweet – how are we supposed to know all the different acceptance criteria? On the back of each story we will have to enter some "acceptance criteria" that we can check at the end when the developer thinks the feature is done.
To write great acceptance criteria, we need to think not only about the usual expected behavior in the application, but also about any cases where the app should fail (for example: When you specify a wrong password, when your credit card is rejected, etc.).
User Story: "As a music lover I want to be able to pay for my album with my VISA card"
Examples of Acceptance Criteria (specific for this story):
Please, this is a course about full-stack web development. You don’t have to write the best stories ever made. Perfect does not ship! Take some time to think about your stories, but don’t get stuck during the process.
You will be using user stories a lot, but, as a developer, it is not your responsibility to write them. There are people certified for that (Requirement Analysts). Your job is to read them and follow them.