├── .gitignore ├── README.md ├── before-arrival.md ├── code-reviews.md ├── foundation.md ├── house-rules.md ├── journey.md ├── mvps.md ├── pair-programming.md ├── part2.md ├── projects.md ├── schedule.md ├── teaching.md ├── teams.md ├── templates ├── README.md ├── mvpdone.example.js ├── mvpdone.js ├── mvpstart.example.js ├── mvpstart.js └── snippets │ ├── mvpdone.sublime-snippet │ └── mvpstart.sublime-snippet └── workshops.md /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | #Founders & Coders Playbook [![contributions welcome](https://img.shields.io/badge/contributions-welcome-brightgreen.svg?style=flat)](https://github.com/foundersandcoders/playbook/issues) 2 | 3 | This playbook repo is intended to be a reference on how we do things at [Founders & Coders](http://www.foundersandcoders.org). 4 | 5 | **All pull requests welcome** (remember to update the [contents section](#contents) of this readme as part of your PR). 6 | If you submit a PR, please **assign one of the following people to review & merge it** as they have all volunteered to peer-review PRs: [@rorysedgwick](https://github.com/rorysedgwick), [@FilWisher](https://github.com/FilWisher), [@besarthoxhaj](https://github.com/besarthoxhaj) [@sofer](https://github.com/sofer), [@iteles](https://github.com/iteles) or [@nelsonic](https://github.com/nelsonic). 7 | 8 | If there is **something you think should be here, but you don't have time to write it**, please _open an issue_. Someone will get to it eventually! 9 | 10 | ##Contents 11 | + [Before you arrive](/before-arrival.md) 12 | + [House Rules](/house-rules.md) 13 | 14 | ###The programme 15 | + [Weeks 1-8: Part 1 - Foundation](/foundation.md) 16 | + [Weeks 9-16: Part 2 - Projects](/part2.md) 17 | 18 | ###The classroom 19 | + [Student teams](/teams.md) 20 | + [Schedule](/schedule.md) 21 | + [Projects](/projects.md) 22 | + [Code reviews](/code-reviews.md) 23 | + [Pair programming](/pair-programming.md) 24 | -------------------------------------------------------------------------------- /before-arrival.md: -------------------------------------------------------------------------------- 1 | #Before you arrive 2 | 3 | ### Get a laptop 4 | 5 | If you do not yet have a laptop, get one. If you want something inexpensive, a ChromeBook with at least 4GB of RAM is a good option. 6 | 7 | ### Set up a dev environment 8 | 9 | Get your computer set up for software development. 10 | 11 | If you have a Mac, you are more-or-less ready to go. 12 | 13 | If you have a ChromeBook, you will want to install Linux, using [crouton](https://github.com/dnschneid/crouton). If you want help, then just [try google](https://www.google.co.uk/search?q=crouton). There are several decent tutorials out there. 14 | 15 | If you have a Windows PC, you may want to consider also installing Linux on it. It can be a bit of a pain, but is probably preferable (at least, in our experience) to trying to work with Windows. Good luck. 16 | 17 | ### Get familiar with the command line 18 | 19 | We are going to be spending a lot of time working on the command line. If you don't know anything about the command line, then try Zed Shaw's [CLI Crash Course](http://cli.learncodethehardway.org/). 20 | 21 | ### Learn the basics of HTTP 22 | 23 | Here's a [pretty good introduction](https://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html). 24 | 25 | ### Git 26 | 27 | Work through our [Introduction to Git and Version Control](https://github.com/NataliaLKB/learn-git-basics). 28 | 29 | ### READMEs and markdown 30 | 31 | This document is a README. We are going to use them a lot on this course. 32 | 33 | Read [Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) and then, if you do not already know markdown, complete [this short tutorial](http://markdowntutorial.com/). 34 | 35 | 36 | *Dan, April 24.* 37 | 38 | 39 | -------------------------------------------------------------------------------- /code-reviews.md: -------------------------------------------------------------------------------- 1 | # Notes on code reviewing 2 | 3 | > "*Programs are meant to be read by humans, 4 | > and only incidentally for computers to execute*." - Donald Knuth 5 | - - - 6 | 7 | > “*Any fool can write code that a computer can understand. 8 | > Good programmers write code that humans can understand*.” 9 | > ~ Martin Fowler 10 | - - - 11 | 12 | ![code quality cartoon](http://i.imgur.com/IC3cJde.png "code quality cartoon") 13 | 14 | Our goal is *zero* surprises ("WTF" moments) during code review. 15 | 16 | ## Why review code? 17 | 18 | Reading other people's code is the ***fastest way to learn***, 19 | not only do you gain insight into how other people solve a problem, 20 | you also gain experience in what makes code ***readable*** (*and thus* ***maintainable***). 21 | 22 | While it may *feel* like the focus of your first 8 weeks of Founders & 23 | Coders is on learning to *write* code, as a coder you will spend *considerably* more time *reading* other people's code than writing your own. (*get used to that idea... embrace it! if you can write less code by reading other people's modules and using existing solutions, you save everyone time!*) 24 | 25 | In many cases the **cost** of ***maintaining*** **software** ***can vastly exceed*** the **initial cost** of **development**. 26 | 27 | ![Software Life-Cycle Costs](http://i.imgur.com/ehEmfA1.jpg) 28 | 29 | Granted, this diagram refers to the "old" ("waterfall") way of writing software, the amount of time spent maintaining code still often exceeds 30 | the time spent initially developing it using a modern "agile" methodology. As such learning to read code is at least as important as learning to write it. 31 | 32 | We must *practice* reading code and paying ***close attention to detail***. 33 | 34 | ## How we conduct code reviews 35 | 36 | ### 1. Locate the GitHub repository you are planning to review 37 | 38 | The first step is locate the repository for the code you are going to be reviewing. If you can't find the code, you don't have much hope of reviewing it... (* this is obvious but you would be surprised how many times people have requested code reviews and failed to provide a link to the repo*...) 39 | 40 | ### 2. Overview of Files in the repo 41 | 42 | Have a quick read through the list of files in the repo. 43 | 44 | + is there a **README.md** or other documentation? 45 | + Follow the instructions in the README. 46 | + Does the project have a "manifest" file 47 | (e.g. package.json or component.json or bower.json) 48 | + Clone the repo and attempt to run the code e.g: 49 | `npm i && npm test` 50 | 51 | if either of these two files are not present, go straight to the issues section of the repo and check if someone else has already raised this as an issue. If no issue exists highlighting the lack of documentation, raise one. 52 | 53 | ### 3. Quick Check or Detailed Review? 54 | 55 | Gauge what level of review is required. 56 | Are you doing a detailed review prior to delivering a sprint to a client or deploying a major version to many 'users'? 57 | Or is this an small/incremental change small enough for you to understand everything that has changed in 20mins (or less) of reading? 58 | 59 | Do you have access to the "user" stories / acceptance tests, to know if the code has solved the problem as it was originally identified? 60 | 61 | ### 4. Large Project? > Focus on the files that are changing the most 62 | 63 | If you are new to the project, it can be overwhelming and you might not know where to start looking in the codebase. If the project organisation is not *obvious* after 5 minutes of inspection, call for help. 64 | If the code author(s) are available, try to pick their brains and request a walk-through (either in person or remote. e.g: google hangout) 65 | 66 | ### 5. Raising issues 67 | 68 | The main branch of a repository should be "*stand alone*". 69 | By this we mean it should be self-explanatory (without further clarification from the original creators). 70 | 71 | Raise issues if you spot any gaps in clarity in the code or documentation. 72 | 73 | #### Etiquette 74 | 75 | As the person reviewing code, always phrase your issues in an open-minded way (*avoid "this is bad code" type issues, they are useless*) use questions and *seek to understand*. 76 | 77 | If you (*think* you) know a "better way" of solving a problem, phrase the issue as a question: e.g: 78 | "*Would you consider using `this` here instead of `that` because of xyz reason...?*" 79 | 80 | If you are referring to a section of code, provide a full link to the line(s) including the branch/commit id. e.g: https://github.com/foundersandcoders/beekeeper/blob/e92ef2d3625ea5e5f7cf29e7daa11c86fa3741bd/test/auth.test.js#L20 81 | 82 | Tip: if you want to keep links short, use http://git.io/ 83 | 84 | If you are reviewing a Pull Request add line-comments: https://help.github.com/articles/commenting-on-the-diff-of-a-pull-request/ so that your feedback is contextual. 85 | 86 | #### Guide: Ask yourself (*the code author*) the following *Questions* 87 | 88 | + Does the commit history tell a coherent story? 89 | + Does this pass the "everyone on the project gets abducted by aliens" test? 90 | + Does the repository have tests? (*if not, red-flag it*) 91 | + Do the tests pass? (following the instructions in the repo's readme) e.g: `npm i && npm test` (*for node.js based projects...*) 92 | + Are all ***dependencies explicitly declared***? 93 | + Are installation instructions complete? 94 | + Are instructions for running tests complete? (*try running the tests!*) 95 | + Is `npm start` script defined in `package.json` (*node.js projects*) 96 | + Do you understand the *point* of all the tests? (are there are any "tests" without assertions?) 97 | + If the *code coverage* is incomplete, why is that? 98 | + Does all the code pass "lint" checker? (see: [jshint](https://github.com/docdis/learn-jshint)); 99 | + Is the file/project structure clear? 100 | + Are any of the **files** ***too long*** (~200+ lines); 101 | + Is the code "[***DRY***](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself)" 102 | (*i.e: limited repitition*) 103 | + Could the code be more modular? 104 | + Are any functions poorly/confusingly named? 105 | + Could a comment be removed if your function was better named? 106 | + Do any of your functions do more than one thing? 107 | + Will factoring out any of your code make yout functions easier to read? 108 | + If any of the functions look hard to test (*or* ***are untested***!); 109 | + Are any variable names not being declared at the top of the block in which they are used (why is this important?) 110 | + Is the code appropriately commented? 111 | + Is indentation consistent? 112 | + Is the flow of the program clear? (are there too many branches?) 113 | + Are any callbacks without error checking? 114 | + Are any functions too-deeply nested (any signs of "callback hell")? 115 | + Are there any username/password or secret/api keys or credentials in the code? Flag these! 116 | 117 | ## Background Reading 118 | 119 | + Is code for computers or humans? 120 | http://stackoverflow.com/questions/522828/is-code-for-computers-or-for-people 121 | + Writing code for humans: https://medium.com/@ilyothehorrid/writing-code-for-humans-5b80a89f439c 122 | + ***Maintainable*** JavaScript: 123 | https://github.com/jasonzhuang/tech_books/blob/master/js/Oreilly.Maintainable.JavaScript.May.2012.pdf 124 | + JavaScript the ***Good Parts*** Notes: 125 | https://github.com/iteles/Javascript-the-Good-Parts-notes 126 | + Writing code for humans: 127 | https://medium.com/@ilyothehorrid/writing-code-for-humans-5b80a89f439c 128 | + Curly's Law: Do One Thing: 129 | http://blog.codinghorror.com/curlys-law-do-one-thing/ 130 | + Write/Read-only Code: http://en.wikipedia.org/wiki/Write-only_language 131 | + Spaghetti Code: 132 | http://en.wikipedia.org/wiki/Spaghetti_code 133 | + Code Refactoring: 134 | http://en.wikipedia.org/wiki/Code_refactoring 135 | + How To Write Unmaintainable Code (*ensuring job security*): 136 | https://thc.org/root/phun/unmaintain.html 137 | (*this is informative not instructional*...) 138 | -------------------------------------------------------------------------------- /foundation.md: -------------------------------------------------------------------------------- 1 | # Web Development Foundation course 2 | 3 | ### Outline syllabus 4 | 5 | ####Week 1: Introduction to software development for the Web 6 | Introduction to HTTP and the Web, HTML and CSS, UX, wireframing, the JavaScript programming language, testing, TDD, paired programming, problem solving, using online resources effectively, agile development, Git and GitHub, website hosting, lean product development and MVPs. 7 | **Role groups:** vanilla CSS (mobile-first CSS, CSS positioning, @media queries), UX (wireframes), testing, GHPages (deployment) 8 | **Expected learning outcomes:** _TBC_ 9 | 10 | ####Week 2: Web APIs 11 | APIs, AJAX, JSON, all with vanilla Javascript (with jQuery stretch goals). 12 | **Role groups:** Testing, front end devs (HTTP requests and AJAX), architect group (code and file structure), repo owners (git best practices and git flow). 13 | [Expected learning outcomes, week 2](https://hackpad.com/Week-Two-Expected-Learning-XFTPVTmz91p) 14 | 15 | ####Week 3: Intro to Node.js 16 | npm init, install, start, test. The fs and http modules. 17 | 18 | ####Week 4: Node.js modules, frameworks, databases and deployment 19 | Modules, build tasks, databases, deployment, frameworks 20 | 21 | ####Week 5: The hapi framework 22 | Introduction to the Node.js Web framework 23 | 24 | ####Week 6: Front-end JavaScript 25 | 26 | ####Week 7: The GitHub API 27 | 28 | ####Week 8: The missing workshops 29 | 30 | As usual, all content is subject to change. 31 | -------------------------------------------------------------------------------- /house-rules.md: -------------------------------------------------------------------------------- 1 | #House Rules (Work in Progress) 2 | 3 | + **Whilst you're a student, arrive on time & let people know in advance if you're going to be away**. Lots of people are giving freely of their time and knowledge to make FAC possible and giving up other commitments to be here. 4 | 5 | + **Tidy up after yourself** (at least!). With so many of us in the space, it's easy for the kitchen area to get dirty really quickly - wash up your crockery rather than forgetting about it in the sink and wipe down the counter area you've been using it and we'll all be a lot happier :blush: 6 | 7 | + **Clean desk policy**. We have a clean-desk policy. Please leave your desk clear before you leave each day. 8 | 9 | + **Hot desking**. Please sit anywhere downstairs when you arrive each morning. 10 | 11 | + **20-minute rule**. Struggle is good, but not too much of it. As a general rule, if you cannot solve a problem within 20 minutes, then stop and talk to somebody about it (there should be a timer on your desk) 12 | -------------------------------------------------------------------------------- /journey.md: -------------------------------------------------------------------------------- 1 | # Developer journey 2 | _Signed off by F&C CIC on [28th April 2015](http://tinyurl.com/m3q4dll)._ 3 | 4 | **In this document:** 5 | + [Developer levels](#levels) 6 | + [The Panel](#the-panel) 7 | + [Why do this?](#why-do-this) 8 | + [FAQs](#faqs) 9 | 10 | 11 | ##Developers at Founders & Coders 12 | We have five kinds of developer at Founders & Coders. 13 | 14 | + Student 15 | + Graduate 16 | + Apprentice 17 | + Developer 18 | + Lead Developer 19 | 20 | > It is important to note that this is a **technical distinction only**. Founders & Coders as an organisation has a completely flat hierarchy and all _members_ have equal say and voting rights. 21 | 22 | **Student** 23 | During the [8 week foundation course](https://github.com/foundersandcoders/playbook/blob/master/foundation.md), you are a _student_. You can't work on F&C client work but you can and _should_ dedicate your time to learning the material and asking as many questions as you can! 24 | 25 | **Graduate** 26 | After completing the 8 week foundation course, you are officially a *graduate developer*. You can work on MVP projects and follow-up work for your **MVP clients**, internal projects and your own projects. Only once a student becomes an apprentice, can they be apprenticed to a developer, on a project-by-project basis. 27 | 28 | 29 | **Apprentice** 30 | After completing an *apprentice panel*, you become an *apprentice developer*. Apprentices can join a *developer* as a **member of a two-person development team** and work on **all F&C client work** (non-MVPs as well as MVPs). 31 | 32 | **Developer** 33 | After completing a *developer panel*, you become a *developer*. Developers can **take on an apprentice** and work on **all F&C client work** (non-MVPs as well as MVPs). Apprentice-developer teams will be expected to undertake regular (i.e. weekly) code reviews for other teams. 34 | 35 | **Lead Developer** 36 | After completing a *lead developer panel*, you become a *Lead developer*. Lead developers can continue to pair with developers or apprentices but can also lend their expertise on an ad-hoc basis to other projects. [requires more detail] 37 | 38 | 39 | ## The Panel 40 | 41 | To achieve each level, candidates will be expected to submit the following to the panel: 42 | 43 | + A **fully-documented repository** of a project or software module that you have worked on; 44 | + A **case study of a project** (for the F&C website), using our case study template; 45 | + A **teaching resource** in the form of a GitHub repository with an associated README; 46 | + An **accompanying blog post** for the F&C website; 47 | + A **screencast of the teaching resource** for the F&C YouTube channel (a colleague can do the voiceover, if preferred); 48 | + Demonstrate your contributions to colleagues' work, through a history of **issues raised on GitHub**; 49 | 50 | In certain cases, alternatives to these requirements can be accepted as a panel submission, but this will need to be discussed with a member of the panel in advance. 51 | 52 | Candidates will also verbally present their teaching resource (and reasons for their choice of subject) to the panel and answer a few short questions. 53 | 54 | ###The teaching resource 55 | The teaching resource could take the form of a project "starter kit" for a project or some similar resource that could be used on the course or for a workshop, such as a full tutorial on a given subject. Please discuss your intended resource with a member of the panelbefore starting on it. 56 | 57 | ###What the panel will be looking for 58 | + Explanation of **Why** your chosen subject is important/interesting 59 | + **Provide context**: How does this fit into our existing body of knowledge? (any prerequisites?) 60 | + Use a logical structure; 61 | + Make it **beginner-friendly** (terminology and examples); 62 | + Include an associated repo with **example code that people can clone and play with**; 63 | + Explain **how to resolve problems** when things go wrong, not just a resource of when everything goes your way; 64 | + Split into **various steps where people can checkout a branch** in your repo at every step and play with the code you have set up. 65 | 66 | ###Before submitting to the panel 67 | Candidates will consult with one of the panel members to ensure that they and their resources are ready for submission. Only once the panel member thinks the candidate is ready can the candidate submit to the panel. 68 | 69 | The panel will all provide feedback in the form of GitHub issues (and face-to-face discussion). When the panel is satisfied with the quality of the material, the candidate must present both pieces to an open forum of members at which anyone may ask questions. 70 | 71 | ###Further Notes 72 | The process is the same for each level, but the level of craftsmanship required will be expected to be significantly higher for each successive level. 73 | 74 | Some implications of these proposals: 75 | + Graduates can put themselves forward to be apprenticed only when they and the panel think they are ready; 76 | + There is a clearly-defined journey from less experienced to more experienced developer; 77 | + Everyone in F&C takes the quality of their work and their contribution to learning seriously; 78 | + We build up some high-quality open source learning materials that we and others can re-use. 79 | 80 | ## Why do this? 81 | There are a few reasons you might want to progress through the levels: 82 | + **[Graduates and Apprentices]** Opportunity to pair with someone more experienced on projects 83 | + **[Developers and Lead developers]** Opportunity to pair with someone less experienced and become a mentor 84 | + **Improved developer reputation** - all of the materials you create for you panel will be used and publicised by Founders & Coders, providing a lot of exposure for your work (and hopefully a few starred repos ;)) 85 | + **For Graduates**, taking the Apprentice panel also allows you to move away from working solely on MVPs and into fuller projects. 86 | 87 | ## FAQs 88 | 89 | *What happens to somebody who has finished the course, but is not yet an apprentice?* 90 | They are considered a graduate and can continue to work on MVPs, follow-up work for MVP clients, internal projects and their own projects. 91 | 92 | *What sorts of support will graduates get before they are apprentices?* 93 | Less than we would like. They need to make sure that they are working together with other graduates and are regularly submitting their own work to peer review as well as peer reviewing other graduates' work. 94 | 95 | *What happens if somebody fails the panel submission?* 96 | This should never happen. It is the responsibility of the panel members to make sure a candidate is ready before they submit to the panel. 97 | 98 | *Where and when will the presentations take place?* 99 | Downstairs, possibly on Fridays, with drinks afterwards. 100 | 101 | *What is the point of the presentation?* 102 | It is a rite of passage. It is a reminder that we take the quality of our work and our teaching seriously. And it is something for students to aim for. 103 | 104 | *Will there be a presentation every week?* 105 | With 16 new students every four months and apprentices graduating to developers, there will probably be at least one pass presentation per week and sometimes more. 106 | 107 | *Who is going to sit on the appointment panels?* 108 | For now, the panel consists of our two company directors, [Ines](https://twitter.com/iteles) and [Dan](https://twitter.com/dsofer), and our resident expert, [Nelson](https://github.com/nelsonic). 109 | 110 | *How much work have we got coming in?* 111 | Check the projects board or come to the Friday projects meeting to find out. 112 | 113 | *What will apprentices be paid?* 114 | We are a freelance co-operative. We are all self-employed. We set our own rates of pay. But we are aiming for a starting rate for apprentices of £10/hour. 115 | -------------------------------------------------------------------------------- /mvps.md: -------------------------------------------------------------------------------- 1 | # MVP projects 2 | 3 | After completion of the foundation course, students can continue with a further period of study, consisting of four projects completed over up to eight weeks. 4 | 5 | Each project will consist of a complete minimum viable product (MVP). The first round of MVPs can be for the students' own projects or will be suggested by us. [Subsequent projects](http://foundersandcoders.org/mvp) will usually be for external clients or potential employers. 6 | 7 | ##Guidelines 8 | 9 | ### Project selection 10 | 11 | + After a project is posted on the MVP projects board, students can add their names to it. 12 | + We generally recommend teams of 2-4, with 3 usually being the ideal number. 13 | + Occasionally more than 4 people sign up for a single MVP. The situation normally resolves itself through conversation or people moving to other MVPs that catch their eye but as a last resort, we can draw straws for who stays on the the MVP. 14 | 15 | 16 | ### Before starting 17 | 18 | The project team will be expected to meet with the client well in advance of starting on a project to agree the scope of the MVP and to get sign off from the client on a *minimum set of deliverables*. After the deliverables have been agreed, we will raise an invoice, which the client will usually be expected to pay before we start work. 19 | 20 | ### Process 21 | 22 | + Each project will normally start on a Monday. 23 | + Projects will usually last for one week with a minimum of two weeks between projects. 24 | + **Note:** The main MVP will be 1 week (as communicated to clients) but team may want to work on them a little longer to round them off for case studies or if they are of particular interest so should _always_ give themselves 2 weeks 25 | + Each team will use PivotalTracker to manage the project. 26 | + Each project will consist of two one-week sprints. 27 | + The client will be invited to join the team on the first Monday to agree the scope of the project and to participate in a sprint planning meeting. 28 | + The client will be invited to join the team on the second Monday for a sprint review and planning meeting. 29 | + The client will be invited to join the team for a project review on the final day of the project. 30 | + It is also the team's responsibility to coach the client through the project process, especially if they have never worked with the notion of user stories and sprints before. 31 | 32 | 33 | ### UXer 34 | 35 | + Each team will appoint a UX lead who will work with the client to produce wireframes and user stories. 36 | + The UX lead will also train the client in the role of the *product owner* and the use of PivotalTracker. 37 | 38 | ### Client liaison 39 | Each project team will appoint a client liaison, who's job it will be to communicate with the client throughout the project. 40 | This includes: 41 | + Arranging meeting times with the client. 42 | + Notifying the client of any changes to schedule or personnel. 43 | + Delegating any of these tasks if they are not available to carry them out. 44 | 45 | ### Communication 46 | 47 | + It is the responsibility of all team members to notify their colleagues of any changes to their own availability. 48 | 49 | ### Documentation 50 | 51 | + Each team will maintain a GitHub repository for the project with a README. 52 | + This is where a project should _start_ and the README should **always** be up to date. 53 | + Unless the client requests otherwise, the repo will be public. (But the repo and the README should usually not refer to the client by name to give their project some sort of anonymity.) 54 | + No sensitive client information should be included in the repo. 55 | + Each team will complete a screencast for the client to accompany the README, describing the project and how to install and use it. 56 | 57 | ### Pay 58 | 59 | On successful completion of a project, all income received for these MVPs will be divided equally between the students. It is the responsibility of students to raise their own invoices addressed to Founders & Coders so they can be paid. 60 | 61 | ### On completion of four projects 62 | 63 | After completion of four projects, graduate developers may decide to prepare their submission to the [apprentice panel](/journey.md). They can also continue to work on MVP projects, as they become available. 64 | 65 | We also encourage graduates to continue with any follow-up work for the client after the completion of an MVP. This will be charged at a higher (non-MVP) rate. 66 | -------------------------------------------------------------------------------- /pair-programming.md: -------------------------------------------------------------------------------- 1 | # Pair programming 2 | 3 | ## Our favourite pairing exercise 4 | 5 | **Ping pong.** One student starts by creating a single failing test and then each student takes it in turns to first write code to make the test pass and then to write a new failing test before passing the keyboard back to their partner. 6 | 7 | ## Three other kinds of pairing exercise 8 | 9 | + Pair for up to 30 minutes 10 | + Swap roles after 15 minutes 11 | + If in doubt, follow the coding questions crib sheet 12 | 13 | **The driving test.** One student sits at the computer and the other student acts as examiner. the student being examined should explain their thinking as they work. Whenever the examiner thinks the other student is being too quiet or does not understand something, she can ask for more information, but otherwise should offer no advice nor provide any feedback. 14 | 15 | **The back-seat driver.** This is similar to the driving test, but in this case the examiner sits at the keyboard and follows the instructions of the other student. Again, the examiner should provide no advice, but can request clarification or an explanation of why she is being asked to do something. 16 | 17 | **The driving instructor.** In this case, the person not at the keyboard should lead a discussion about the code through a series of questions. If desired, she can use the coding questions crib sheet for assistance. 18 | 19 | ##Coding questions crib sheet 20 | 21 | + When defining a new function, are we using sensible names? 22 | + Is it obvious at first glance what the procedure is for? 23 | + What are the inputs for the function? 24 | + And are these inputs reflected in the arguments? 25 | + What do you expect the function return value to be? 26 | + What's a sensible first test for a function? 27 | + Is this the simplest possible test that you can think of? 28 | + As you work through the problem, are all your passing tests still passing? If not, why not? 29 | + Are you adding tests as you go? 30 | + What test are you going to add next? 31 | + Are you using sensible names for all your variables? 32 | + Is it obvious at first glance what each of them is being used for? 33 | + As you work through the problem, are you working from the outside in or are you trying to solve the problem in a linear sequence from top to bottom? (try working from the outside in, always thinking about the inputs and outputs of the code block you are working on) 34 | 35 | -------------------------------------------------------------------------------- /part2.md: -------------------------------------------------------------------------------- 1 | # Part 2: Projects 2 | 3 | ### Outline syllabus 4 | 5 | ####Weeks 9-10: React and reusable components 6 | Learn to use Facebook's front-end framework. 7 | 8 | ####Weeks 11-12: Member projects 9 | Four projects; four pitches; four product owners. FAC members get their own projects built by the students. 10 | 11 | ####Week 13-16: Client projects 12 | The beginning of commercial work. 13 | -------------------------------------------------------------------------------- /projects.md: -------------------------------------------------------------------------------- 1 | #Projects 2 | 3 | **First, agree the scope** 4 | Before you do anything, agree the scope of the project. 5 | 6 | **Second, create the README** 7 | Next, create a repo with a README to describe the project. 8 | 9 | **Third, create the wireframes and user stories** 10 | Use Google Slides for wireframes and PivotalTracker for user stories. 11 | 12 | **Fourth, create acceptance tests** 13 | Don't start work on the project until you have created a set of failing tests that reflect the user stories. -------------------------------------------------------------------------------- /schedule.md: -------------------------------------------------------------------------------- 1 | #Classroom schedule 2 | 3 | **Start each day at 10am with a coding challenge** 4 | Start the day with a 30-minute paired programming session. 5 | 6 | **Start each week with a new project** 7 | And get each team to start their project with a README, user stories and failing tests. 8 | 9 | **Spend Monday working in roles** 10 | Our Jigsaw classroom day. 11 | 12 | **Role presentations on Monday afternoon** 13 | Each role group presents their research findings at the end of the day on Monday. 14 | 15 | **Early evening talks and pitches** 16 | Talks and MVP pitches generally take place at 5.30pm Tuesday to Thursday. 17 | 18 | **End the day by reviewing someone else's code** 19 | Before going home each day on Tuesday to Thursday, select a different team's project, follow the README, and leave feedback in the form of GitHub issues (if you prefer, you can review all three projects in one go, but make sure you review and leave issues on every other team's project every week). 20 | 21 | **Review the week's learning on Friday afternoon** 22 | Do a *Stop, Go, Continue* session at some point after lunch. 23 | 24 | **Project reviews on Friday afternoon** 25 | Review each team's projects as a group on Friday afternoon. The review consists of a run through of the README, a review of issues raised, running tests, a review of the code, and a presentation of the application. 26 | 27 | -------------------------------------------------------------------------------- /teaching.md: -------------------------------------------------------------------------------- 1 | #Teaching at Founders & Coders [Work in Progress] 2 | At Founders & Coders, _each week is led by a different group of people_ (depending on their expertise and chiefly on their availability). 3 | We operate as a **collaborative learning environment** encouraging students to try new (to them) things, teach each other and rapidly iterate. We do a lot more **providing direction** and a lot less **teaching/lecturing** than a traditional classroom environment. 4 | 5 | **This is a collection of our thoughts on what has worked so far when teaching and is intended mainly as a resource for people leading any given week of the course**. Weeks follow [the schedule set out here](/schedule.md). 6 | 7 | ![different types of learning](http://www.learning-knowledge.com/teachlearn/cooperation1.gif) 8 | 9 | ###Content Guide 10 | + [General structure](#general-structure) 11 | + [Checklist for the week](#checklist-for-the-week) 12 | + [Role Groups](#role-groups) 13 | + [Clients](#clients) 14 | + [Tips](#tips) 15 | 16 | ###General structure 17 | Each week requires: 18 | + **1 or 2 people to lead the week** - this doesn't mean they do all the work, it just means that there is someone to make sure that there is an established structure for the week (for anything outside of the routine tasks) and things are running [on schedule](/schedule.md) 19 | + **3-4 people to be role mentors**, one for each group (this can include the person leading the week) 20 | + **3-4 people to be clients** on weeks where this is required 21 | 22 | **Weekends are for consolidating the previous week's learnings**, so _resist the urge_ to give students 'homework' or preparation work for the following week. 23 | 24 | ##Checklist for the week 25 | + [ ] Established 4 role groups & what they will present on 26 | + [ ] Defined who the role mentors/clients for the week will be 27 | + [ ] Prepared 5 minute introductions to anything important/interesting that might not be covered in detail by role groups 28 | + [ ] Provide an idea of what the week will entail on Monday (no driving blind) 29 | + [ ] Update the week's calendar with any talks or activities specific to the week 30 | + [ ] Have a list of **expected learning outcomes** ready to give student at the end of the week so they can ensure they learnt what they need from the week 31 | 32 | ###Role Groups 33 | Originally we carried the same 4 role groups from week to week, but we have found it best to have **different role groups from week to week, according to the key knowledge required to form a solid foundation for that week**. 34 | Each group has a mentor who: 35 | + Explains the task for 5-10 minutes in the morning (for testing, this is more involved and in the first week may require a full day's collaborative teaching) 36 | + Checks in withe the role groups throughout the day to field questions and re-direct learning if they wander too far off track. 37 | 38 | ###Clients 39 | _To be written_ 40 | 41 | ###Tips 42 | When asked a question: 43 | + What did you google for? 44 | + Have you asked the other members of your team? 45 | + Have you asked other students outside of your team? [If you know a team that has worked through the same problem, point them to that team] 46 | 47 | -------------------------------------------------------------------------------- /teams.md: -------------------------------------------------------------------------------- 1 | #Student teams 2 | 3 | (quotations below are from http://www4.ncsu.edu/unity/lockers/users/f/felder/public/Papers/Oakley-paper(JSCL).pdf) 4 | 5 | **Four-student teams** 6 | *"With only two people on a team, there may not be a sufficient variety of ideas, skills, and approaches to problem solving for the full benefits of group work to be realized... On the other hand, if a team has more than five members, at least one is likely to be relatively passive...Many cooperative learning authorities believe that five-member teams are likely to experience the same problem. Our recommendation is therefore to form three- and four-person teams, making more of them teams of four if early dropouts are common in the course."* 7 | 8 | **Diversity** 9 | Form teams that are diverse in ability and background. 10 | 11 | **Don't let teams self-select** 12 | *"Instructors should form teams rather than allowing students to self-select. Left to their own devices, the stronger students in the class will tend to seek one another out... Groups containing all weak students are likely to flounder aimlessly or reinforce one another’s misconceptions, while groups composed entirely of strong students often adopt a divide and conquer policy, parcelling out and completing different parts of the assignment individually and putting the products together without discussion."* 13 | 14 | **Encourage co-operation between teams** 15 | Team members should not hold back from sharing ideas and insights with other teams. 16 | 17 | **Discourage competition between teams** 18 | The weekly projects are not a competition. They are a learning process. 19 | 20 | **Every team member has a role** 21 | Make sure that each team member has a defined role in the team, for which they can, with the help of other experts from other teams, develop domain expertise (see Jigsaw Classroom https://www.jigsaw.org/). 22 | 23 | **Rotate the roles** 24 | Re-define and rotate the roles each week. 25 | 26 | -------------------------------------------------------------------------------- /templates/README.md: -------------------------------------------------------------------------------- 1 | #Templates 2 | 3 | Here you will find a number of templates for various purposes. Inside `/snippets` are a number of snippets for use in your text editor to make filling out these templates simple. Each template has an accompanying `template.example.md/js/txt` file, to show how it should be used. 4 | 5 | If you want to preserve indenting, use `.js` or `.txt` as a file extension. 6 | 7 | ## Submissions 8 | Alongside the template, provide an example of how it is used in a `.example.md` file. 9 | If possible, include a snippet for 1+ text editors too. 10 | Porting snippets to other text editor formats is always welcome. 11 | -------------------------------------------------------------------------------- /templates/mvpdone.example.js: -------------------------------------------------------------------------------- 1 | # MVP finished example email 2 | --- 3 | 4 | Hi Joe, 5 | 6 | Below we have outlined the feature specification for the MVP, along with the outcomes of our work. We hope this is to your satisfaction. If you wish for ownership to be transferred from the team to you, please let us know and we will get back in contact with the necessary steps. 7 | 8 | MVP Specification: 9 | 10 | Agreed essential features: 11 | 12 | Feature 1: Central data storage 13 | Solution provided: 14 | - MongoDB Database 15 | - Users & Posts collections 16 | - Create, Read, Update and Delete capabilities 17 | - User-specific database access 18 | 19 | 20 | Feature 2: Responsive, mobile-first blog UI 21 | Solution provided: 22 | - Single-page app 23 | - Mobile-first design 24 | - Cross-browser & device tested 25 | 26 | 27 | Feature 3: User-submitted content 28 | Solution provided: 29 | - In-browser markdown editor 30 | - .md uploads 31 | - Content associated with a particular user 32 | 33 | 34 | Other features: 35 | - Video & Picture uploads to S3 bucket 36 | - Ranking algorithm for popular posts 37 | - Tags for user-categorisation of content 38 | - Rating system 39 | - Comments section 40 | - Social media links for sharing 41 | 42 | Application deployed to Heroku at: https://heroku-cms.herokuapp.com/ 43 | Code & tests located at: https://github.com/someorg/somerepo 44 | Pivotal Tracker board at: https://www.pivotaltracker.com/n/projects/123412412412 45 | 46 | Dates contracted: 47 | 12 Aug 2015 - 24 Aug 2015 48 | 49 | Team: 50 | John Snapper - johnsnapsy@gmail.com 51 | Tina Table - tableshaveturned@live.com 52 | 53 | Regards, 54 | John & Tina 55 | -------------------------------------------------------------------------------- /templates/mvpdone.js: -------------------------------------------------------------------------------- 1 | # MVP finished email 2 | To be sent after the final meeting with the client, to conclude the MVP phase of business. 3 | Any other matters concerning the MVP should have been dealt with in prior discourse. 4 | --- 5 | 6 | Hi ${1:Client name}, 7 | 8 | Below we have outlined the feature specification for the MVP, along with the outcomes of our work. We hope this is to your satisfaction. If you wish for ownership to be transferred from the team to you, please let us know and we will get back in contact with the necessary steps. 9 | 10 | MVP Specification: 11 | 12 | Agreed essential features: 13 | 14 | Feature 1: ${2:These should be the same features as were agreed upon by email before the project started} 15 | Solution provided: 16 | - ${3:Generic solution} 17 | - ${4:Generic feature of solution} 18 | - ${5:Less generic feature of solution} 19 | - ${6:Extra feature descriptions as necessary} 20 | 21 | 22 | Feature 2: ${7:Reuse as much client wording as possible for your solutions} 23 | Solution provided: 24 | - ${8:Generic solution} 25 | - ${9:As above, list of features of solution, ordered from generic to specific} 26 | 27 | 28 | Feature 3: ${10:Avoid using pronouns, keep this as impersonal and professional as possible } 29 | Solution provided: 30 | - ${11:Generic solution} 31 | - ${12:Don't get into too much technical detail} 32 | 33 | 34 | Other features: 35 | - ${13:Completed stretch goals} 36 | - ${14:Only put down important things} 37 | 38 | Application deployed to ${15:hosting service name} at: ${16:deployment url} 39 | Code & tests located at: ${17:github repo url} 40 | Pivotal Tracker board at: ${18:pivotal tracker url} 41 | 42 | Dates contracted: 43 | ${19:DD MMM YYYY} - ${20:DD MMM YYYY} 44 | 45 | Team: 46 | ${21:Full name} - ${22:Email} 47 | 48 | Regards, 49 | ${23:} & ${24:} 50 | -------------------------------------------------------------------------------- /templates/mvpstart.example.js: -------------------------------------------------------------------------------- 1 | # MVP start example email 2 | --- 3 | 4 | Hi Joe, 5 | 6 | We'd like to confirm that the 4 essential features to the MVP that we discussed in our prior meeting are as follows: 7 | 8 | MVP Specification: 9 | 10 | Feature 1: Central data storage 11 | Essential parts: 12 | - Users & Posts collections 13 | - Authenticated access: 14 | * Users must log in before they can submit content. 15 | * Admin & User roles. Admins can edit anything, Users only their own content. 16 | 17 | Feature 2: Responsive, mobile-first blog UI 18 | Essential parts: 19 | - Looks good on mobile & desktop 20 | 21 | Feature 3: User-submitted content 22 | Essential parts: 23 | - Inline editing and creation of blog posts 24 | - Blog posts 'belong' to a particular user 25 | * Their name is displayed underneath the blog post as the author 26 | 27 | For the period: 28 | 12 Aug 2015 - 24 Aug 2015 29 | 30 | Team: 31 | John Snapper - johnsnapsy@gmail.com 32 | Tina Table - tableshaveturned@live.com 33 | 34 | If you feel that any part of this specification is not detailed enough, we have missed something, or got anything wrong, please let us know and we will get back to you with a revised edition. 35 | 36 | Regards, 37 | John & Tina 38 | -------------------------------------------------------------------------------- /templates/mvpstart.js: -------------------------------------------------------------------------------- 1 | # MVP start email 2 | To be sent after the first meeting with the client, to confirm the deliverables for the MVP phase of business. 3 | The intention is that after meeting the client to discuss the scope of the MVP and its essential features, you go away and fill in this template. 4 | Once the template has been filled in and sent to the client, they have the opportunity to tweak it and send it back. 5 | After the client has tweaked it and you have reviewed it, send the revised version back to the client as final written confirmation of the deliverables. 6 | At this point, if the client accepts these features, you're good to go. 7 | --- 8 | 9 | Hi ${1:Client name}, 10 | 11 | We'd like to confirm that the ${2:num} essential features to the MVP that we discussed in our prior meeting are as follows: 12 | 13 | MVP Specification: 14 | 15 | Feature 1: ${3:These should be in priority order, from highest- to lowest-} 16 | Essential parts: 17 | - ${4:First essential part}: 18 | * ${5:More detailed clarification of what is meant} 19 | - ${6:Second essential part}: 20 | * ${7:} 21 | 22 | Feature 2: ${8:Try to reuse the client's words for these } 23 | Essential parts: 24 | - ${9:}: 25 | * ${10:} 26 | 27 | Feature 3: ${11:These are only the essentials for completion of the MVP - extras should only be included in pivotal tracker or the concluding email } 28 | Essential parts: 29 | - ${12:}: 30 | * ${13:} 31 | 32 | For the period: 33 | ${14:DD MMM YYYY} - ${15:DD MMM YYYY} 34 | 35 | Team: 36 | ${16:Full name} - ${17:Email} 37 | 38 | If you feel that any part of this specification is not detailed enough, we have missed something, or got anything wrong, please let us know and we will get back to you with a revised edition. 39 | 40 | Regards, 41 | ${18:} & ${19:} 42 | -------------------------------------------------------------------------------- /templates/snippets/mvpdone.sublime-snippet: -------------------------------------------------------------------------------- 1 | 2 | 45 | 46 | 47 | 48 | 49 | 50 | -------------------------------------------------------------------------------- /templates/snippets/mvpstart.sublime-snippet: -------------------------------------------------------------------------------- 1 | 2 | 37 | 38 | 39 | 40 | 41 | 42 | -------------------------------------------------------------------------------- /workshops.md: -------------------------------------------------------------------------------- 1 | # Workshops 2 | 3 | ## Publicity 4 | 5 | ### Use [Tito](https://ti.to/founders-coders/) 6 | - [ ] We accept payments by Stripe and Paypal 7 | - [ ] Start with 4 single tickets and 2 pair tickets 8 | - [ ] Price points are £225 and £350 9 | - [ ] Add £50 discount codes for our mailing lists: FACFRIENDS, LADIESWHOCODE 10 | 11 | ### Website 12 | - [ ] Add the workshop to the website (under training) 13 | - [ ] Link back to Tito 14 | 15 | ### Mailing lists 16 | - [ ] Our mailing list on MailChimp 17 | - [ ] Ladies Who Code (contact through @iteles) 18 | 19 | ### Twitter 20 | - [ ] Tweet using @founderscoders 21 | - Tweets should always include a good photo of a previous workshop environment in which you tag people or relevant groups who might be interested, such as @LNUG, @ladieswhocode or @codebar) 22 | - [ ] Pin the tweet 23 | - [ ] Get everyone to retweet 24 | 25 | ### Individual emails 26 | - [ ] Participants of past workshops (use an email template) 27 | 28 | ## Staffing 29 | - Student:staff ratio of < 4:1 30 | - Ensure the staff know well in advance who they are & how much they'll forseeably need to to 31 | - Organise a run-through with the staff a day or two before the workshop 32 | 33 | ## Catering 34 | - [ ] Ask Bes, otherwise the pizzas from the Co-op on Roman Rd are quite nice 35 | - [ ] Supply fruit, snacks, treat and drinks 36 | 37 | ## Feedback 38 | - [ ] Get participants to complete a survey before they leave (see e.g. https://founderscoders.typeform.com/to/wMiTnS) 39 | 40 | 41 | 42 | --------------------------------------------------------------------------------