undef1nd / apprenticeship

Notes for apprenticeship programme, to be used by mentors and apprentices alike

These are notes for the Apprenticeship Programme. Distributed under Creative Commons Attribution Sharealike International 4.0

Preface

This programme intends to embed the same baseline knowledge into a new person, to avoid discovering holes in their knowledge later.

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.

Recommended timeframe for covering the topics below is 3 months, however can be shortened/made longer depending on the progress of the apprentice.

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 !

If you have experience being an apprentice or a mentor - feel free to add a pull request here, however small !

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: [e-mail]

Goals

• for the apprentice to be able to learn on their own
• baselining knowledge - this allows other, equally trained, people to expect knowledge of the subjects below when working with the apprentice
• for the apprentice to feel comfortable when asking questions
• allows the apprentice to formulate a plan of approaching a problem on their own - do not hand over a complete plan of actions

General

Before apprentice starts:

• decide on the mentor
• 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.
• make sure to announce when the apprentice starts to everyone involved.

Starting

• look through this document
• look through other materials available
  • study paths
• discuss your experience, come up with a plan for first week together
• after the week come up with the plan for the next week and so on every week
• treat this document as a rough sketch of a overarching plan/list of goals
• revise the progress on the bigger picture every week

What's where

• office supplies

Who's who

• show the apprentice how to locate subject-matter experts using in-house tools
• introduce people when working on particular problems [X might know about this, let us ask her !]

Office tech

• email setup
• email groups
• IM setup + testing
• VPN setup + tests
• WiFi

Company network

• intranet
• distribution lists
• Wiki
• Task management

Project infrastructure.

• Build servers

Knowledge sources

• schedule slots for reading - make Friday the day of learning
• Fowler's "Refactoring"
• RSS feeds [share people's feeds - see .opml files in the repo]

Noting stuff down

• introduce to 'note everything, sort later' aka 'post mortems and time management for free' approach

Learn to learn

• review mistakes and sucesses every Friday
• open discussions with your peers, and not being afraid to ask stupid questions

Tech

commandline:

• bash/zsh [cygwin if Windoze]
• pipes, redirects
• 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
• involve grep and find for finding places in legacy code

SCM

• share configs, especially diff tool setups
• spend some real time explaining basics of centralized vs distributed solutions
• good branching model reaching
• interactive git tutorial
• how to revert anything in git
• always look at diffs before commiting

project setup -> ability to deploy

Algorithms:

• RSA
• hashes and dictionaries/hash maps

Memory management:

• mapping between native memory and JVM/CLR memory
• GC
• heap
• stack

Computer bootup process

• Bare metal Rust
• What happens when you type

Networking:

• ssl/tls
• C10K problem, implement singlethreaded low level server on raw sockets

IPC

Multitasking:

• OS-level threads vs green threads
• async io
• immutability of your data and multithreading - functional programming vs object oriented

Working with code

• codetiquette - remember that in most cases you are not the only one working on this code
• code standards - the more boring the better, the more uniform the better
• ability to read code
• working with legacy code [freeze with tests + cut out approach]
• negate condition -> decrease indentation
• guard clauses at the beginning
• ifs/switch -> dictionary
• when to refactor ?
  • symmetry broken
• continuous refactoring - improving your codebase rather than regressing it
• error and exception handling
  • do not use exceptions for flow control
  • talk about the difference in execution paths, how exceptions affect stack etc
  • introduce monadic error handling
  • care about what you can handle, pass all other stuff upwards
• always reproduce a bug with fully automated test first
• good naming: what it does, not how it does it
• introduction to TDD
• inner TDD loop vs outer, acceptance-tests driven TDD loop
• spikes in TDD

META

• Recommend changes to the apprenticeship programme