-
-
Notifications
You must be signed in to change notification settings - Fork 2
/
README.html
executable file
·165 lines (165 loc) · 6.76 KB
/
README.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="generator" content="ReText 5.0.1">
<title>README</title>
</head>
<body>
<p>These are notes for the Apprenticeship Programme.
Distributed under Creative Commons Attribution Sharealike International 4.0</p>
<h2>Preface</h2>
<p>This programme intends to embed the same baseline knowledge into a new person, to avoid discovering holes in their knowledge later.</p>
<p>This programme needs a one-to-one pairing of apprentice with a senior developer. It must be implemented within existing team structure, already working on some project. The reason for such requirements is to present the apprentice with real-life problems. Because of the above it works best with long-term assignements, where you invest in a person and your team dynamics up front to get the work quality you need.</p>
<p>Recommended timeframe for covering the topics below is 3 months, however can be shortened/made longer depending on the progress of the apprentice.</p>
<p>Tested on several mentor-apprentice pairs, always with local pairing. No remote experience here, would probably need adjustment for remote settings.
Have such experience - please contribute !</p>
<p>If you have experience being an apprentice or a mentor - feel free to add a pull request here, however small !</p>
<p>Don't want to create a pull request ? Starting an apprenticeship programme and unsure how it should be run in practice ? World seems bleak and stripped of joy ? Contact me: email/jabber/xmpp: cyplo@cyplo.net</p>
<h2>Goals</h2>
<ul>
<li>for the apprentice to be able to learn on their own</li>
<li>baselining knowledge - this allows other, equally trained, people to expect knowledge of the subjects below when working with the apprentice</li>
<li>for the apprentice to feel comfortable when asking questions</li>
<li>allows the apprentice to formulate a plan of approaching a problem on their own - do not hand over a complete plan of actions</li>
</ul>
<h2>General</h2>
<p>Before apprentice starts: </p>
<ul>
<li>decide on the mentor</li>
<li>make sure that everyone understands that we're investing the time now to iron out all of the issues today - this means that the whole team is taking a performance hit by accepting the apprentice, and they do want to do it anyway.</li>
<li>make sure to announce when the apprentice starts to everyone involved.</li>
</ul>
<p>Starting</p>
<ul>
<li>look through this document</li>
<li>look through other materials available<ul>
<li><a href="https://github.com/joebew42/study-path">study paths</a></li>
</ul>
</li>
<li>discuss your experience, come up with a plan for first week <strong>together</strong></li>
<li>after the week come up with the plan for the next week and so on every week</li>
<li>treat this document as a rough sketch of a overarching plan/list of goals</li>
<li>revise the progress on the bigger picture every week</li>
</ul>
<p>What's where </p>
<ul>
<li>office supplies
*</li>
</ul>
<p>Who's who</p>
<ul>
<li>show the apprentice how to locate subject-matter experts using in-house tools</li>
<li>introduce people when working on particular problems [X might know about this, let us ask her !]</li>
</ul>
<p>Office tech</p>
<ul>
<li>email setup</li>
<li>email groups</li>
<li>IM setup + testing</li>
<li>VPN setup + tests</li>
<li>WiFi</li>
</ul>
<p>Company network</p>
<ul>
<li>intranet</li>
<li>distribution lists</li>
<li>Wiki</li>
<li>Task management</li>
</ul>
<p>Project infrastructure.
* Build servers</p>
<p>Knowledge sources</p>
<ul>
<li>schedule slots for reading - make Friday the day of learning</li>
<li>Fowler's "Refactoring"</li>
<li>RSS feeds [share people's feeds - see .opml files in the repo]</li>
</ul>
<p>Noting stuff down</p>
<ul>
<li>introduce to 'note everything, sort later' aka 'post mortems and time management for free' approach</li>
</ul>
<p>Learn to learn</p>
<ul>
<li>review mistakes and sucesses every Friday</li>
<li>open discussions with your peers, and not being afraid to ask stupid questions</li>
</ul>
<h2>Tech</h2>
<p>commandline:</p>
<ul>
<li>bash/zsh [cygwin if Windoze]</li>
<li>pipes, redirects</li>
<li>when in doubt use the simpliest, most brute force tools possible, i.e. grep and find. introduce grep as a tool to check for mistakes during refactorings, etc</li>
<li>involve grep and find for finding places in legacy code</li>
</ul>
<p>SCM</p>
<ul>
<li>share configs, especially diff tool setups</li>
<li>spend some real time explaining basics of centralized vs distributed solutions</li>
<li><a href="http://nvie.com/posts/a-successful-git-branching-model/">good branching model reaching</a></li>
<li><a href="http://pcottle.github.io/learnGitBranching/">interactive git tutorial</a></li>
<li>always look at diffs before commiting</li>
</ul>
<p>project setup -> ability to deploy</p>
<p>Algorithms:</p>
<ul>
<li>RSA</li>
<li>hashes and dictionaries/hash maps</li>
</ul>
<p>Memory management:</p>
<ul>
<li>mapping between native memory and JVM/CLR memory</li>
<li>GC</li>
<li>heap</li>
<li>stack</li>
</ul>
<p>Computer bootup process </p>
<ul>
<li><a href="http://www.randomhacks.net/bare-metal-rust/">Bare metal Rust</a></li>
<li><a href="https://github.com/alex/what-happens-when">What happens when you type</a></li>
</ul>
<p>Networking:</p>
<ul>
<li>ssl/tls</li>
<li>C10K problem, implement singlethreaded low level server on raw sockets</li>
</ul>
<p>IPC</p>
<p>Multitasking:</p>
<ul>
<li>OS-level threads vs green threads</li>
<li>async io</li>
<li>immutability of your data and multithreading - functional programming vs object oriented</li>
</ul>
<p>Working with code </p>
<ul>
<li>codetiquette - remember that in most cases you are not the only one working on this code</li>
<li>code standards - the more boring the better, the more uniform the better</li>
<li>ability to read code</li>
<li>working with legacy code [freeze with tests + cut out approach]</li>
<li>negate condition -> decrease indentation </li>
<li>guard clauses at the beginning </li>
<li>ifs/switch -> dictionary </li>
<li>when to refactor ? <ul>
<li>symmetry broken </li>
</ul>
</li>
<li>continuous refactoring - improving your codebase rather than regressing it</li>
<li>error and exception handling<ul>
<li>do not use exceptions for flow control</li>
<li>talk about the difference in execution paths, how exceptions affect stack etc</li>
<li>introduce monadic error handling</li>
<li>care about what you can handle, pass all other stuff upwards</li>
</ul>
</li>
<li>always reproduce a bug with fully automated test first</li>
<li>good naming: what it does, not how it does it</li>
<li>introduction to TDD</li>
<li>inner TDD loop vs outer, acceptance-tests driven TDD loop</li>
<li>spikes in TDD</li>
</ul>
<p>META</p>
<ul>
<li>Recommend changes to the apprenticeship programme</li>
</ul>
</body>
</html>