Skip to content

Latest commit

 

History

History
21 lines (11 loc) · 1.25 KB

File metadata and controls

21 lines (11 loc) · 1.25 KB

Coding

The easiest way to learn how to code is to code.

The hardest way to learn how to code is also to code.

In other words, if you want to get better at coding, you should be coding. This is one of the pillars of this accelerator program.

What to code: Interpreting the requirements.

You should first agree on exactly what it is that you're going to build. The requirements document you were provided is only a beginning, a first step. Your interpretation of those requirements will end up determining what the final product will look like.

Interpreting and deciding on requirements is a group activity for software developers. There is no "official version" of the interpretation. You are free to interpret requirements however you wish.

Who should code it: Task assignment.

Now that you have come to an agreement about what exactly it is that you are going to build, you will have to split the tasks up in a way that makes sense. Each developer should choose tasks they feel comfortable with tackling. The best tasks are those which require the developer to learn new things in order to complete them.

When NOT to code: Avoiding pull request conflicts.

Try not to work on the same files at the same time. Conflicts are usually annoying, and are best avoided.