undef1nd / apprenticeship Goto Github PK

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

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: [email protected]

• 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

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

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