Project: Green Field

Overview

This project is focused on rapid iteration and continuous deployment. Far above the viability of the application as a ‘product’ or your team as a potential start-up.

You will work with your team to generate project ideas, delegate roles, and build something awesome.

In a real work environment, you’ll rarely have the opportunity to choose all of the people you collaborate with.

Your success as an engineer will, in large part, be determined by – how well you’re able to integrate with varied groups of engineers. The ability to contribute to a shared vision and iterate towards it effectively among peers is extremely valuable.

This sprint will help you hone that skill. This will be a 1 week project so make sure you manage your time well so you can finish the most important parts on time.

Learning Objectives:

  • project documentation

  • group dynamics and collaboration

  • product implementation

  • project architecture

  • product design

    PS: During the greenfield project, you must document your code, syntax styling, git workflow and feature roadmap in sufficient detail so that it can be handed to an arbitrary team with virtually no explanation.

Project Infrastructure

In order to support your current team and future contributors to your project, you’ll need to document your project as you build it. It should be the case that, without any intervention or additional explanation from you, the next team of collaborators (or yourself in six months) can dive in and figure out how to start hacking easily.

Document your project and codebase to the point that if you decide to push it to hacker-news, anyone with a solid understanding of JavaScript can (after reviewing your documentation and comments) start submitting pull requests. Plan on not having any face-to-face interaction with the next team of collaborators. The most effective and efficient way to accomplish this is to do it right from the very start.

Don't wait till the last minute. That will never work.

Heavily comment all aspects of your code.

Group Formation

Each member should spend 10 minutes answering the following questions:

  • What are my 2 greatest technical strengths?
  • What are my 2 greatest technical challenges?
  • What are my personal goals for this project?
  • Discuss your answers with your group in a discord call. Get to know each other.
  • Begin brainstorming with your group for the idea of the project.

Team Communication

  • Your team should communicate new ideas for features or report important bugs through github issues or whatever tool you use to manage github issues, that way everyone on your project can see what important things are happening and there is always a repository of further work to be done.

  • To introduce new code into your project, your team should always make pull requests – never make commits and push directly to master.

  • After you make a pull request, at least one other member of your team should do a thorough code review of the changes and you should have a good back and forth where the code is refactored and improved before being merged in. This will guarantee a higher degree of code quality and will prevent careless errors from being merged into your application.

  • Read this excellent (and brief) article about pull requests

  • With continuous integration, you will benefit even more from a pull request based workflow because you will always know that you are never merging breaking code into your master branch.

Speaking to each other

You may want to use a persistent chat service like discord, to communicate as a team so that you can have efficient asynchronous communication. This will make your team more accountable and efficient, so you don’t have to stop everyone else’s work to discuss small issues or request code review.

GitHub Workflow:

  • The Scrum Master must Create a new GitHub Organization account for your team. This ensures that all members share equally in the glory of the project. Don’t worry too much about choosing a name at this point. You’ll likely refactor it several times anyway.

  • Add a new repository to your organization.

  • Invite all your team-mates to join the organization.

  • Create a branch for each team member with their names.

  • Ask the team members to fork and clone the repo.

  • When any team member finish a task, they need to create a pull request.

  • Make sure to review the code before merging them back to your main branch.

  • Each time you need to get the new changes added by other developers you need to do git pull <remote-name> main.

Happy Hacking 🙂

Leave a Reply