What the heck is a PE?

A builder

A PE is a builder who has made many mistakes and wants to help you not to repeat them.

A boost for your career

• Free mentoring!
• Support for your ideas
• Recognition that matters
• Challenge and feedback on your design
  • You believe in better, don't you?

What does a PE look after

• Engineering Culture
• Innovation & Excellence
  • Quality of design
  • Ease of evolution
  • Systems that deliver business value
• Cross-team and inter-departments concerns

Get the most out of your PE

Spend time with your PE

• hire a PE for
  • a design session
  • some pair-programming fun
• invite him/her to showcases
• tell him about your pet project
• coffee? lunch?

Load his/her brain with your stuff

• current design and arch
• pain points
• ideas & wishes
  • refactoring and design
  • technical bar and high standards
  • learning new skills
  • staying abreast of the tech world
  • building a truly amazing tech community
  • long-term thinking

Don't forget…

• Your PE sits on your side.
• He/She represents your team in the outside world.
• You probably code more than him/her.
  • He/She calls that a sacrifice.
• The Emperor will show you the true nature of the Force.

• Aren't you a Skywalker?

2 Kinds of PE

• in breadth
• in depth
  • eg: high-throughput low-latency distributed systems

Me in 2 minutes

What have I built

• a scheduling policy for Linux in O(1)
• an annotation-driven bytecode enhancer to persist POJOs
• a training series from CI to clustering servers
• various J2EE apps / frameworks and some maven plugins
• a highly available portal platform for a swiss pension
• an ERP for the private banking industry as a single-page webapp against a Restful stateless Java backend
• a social e-commerce platform in Scala
• a community of Scala enthusiasts in Lausanne
• few bits of design for Amazon Retail pipeline
• so many POCs or half-started projects…

Invent On Principles

• Simplicity
• Data (Metrics!) Driven Engineering
• Draw conscious lines
  • Don't mix the what and the how
  • Segregate reads and writes
  • Design systems top-down
  • Program bottom-up
• DDD, work with the grain, eat your own dogfood
• Naming is hard, keep trying
• Scale or fail
• Math matters
• Value prior art
• Insist on highest standards
• Favor programming languages with a S name

• Thou shall sacrifice lines of code to Alan Kay

Thanks!

I am looking forward to drinking building great things with you all :-)

Questions?