Engineering Culture
What is it? What makes it great?
Wednesday, October 9, 13
What I learnt in college
artificial intelligence
graphics
java data structures
algorithms
calculus
C++
databases
networking
how to write code
Wednesday, October 9, 13
...What I didn’t learn
how to write code
*for a company*
communication
code reviews
conventions release process
testing
post mortems
documentation
onboarding
Wednesday, October 9, 13
Different goals
College Company
Prove that we
understand a concept or
mastered a skill.
1. Create a product that makes users happy.
2. Create a codebase that’s maintainable
and not fragile.
3. Be intellectually excited by what we’re
working on.
4. Do it with limited time and resources.
As fast and lean as possible.
Wednesday, October 9, 13
That’s a lot to achieve...
1. Create a product that makes users happy.
2. Create a codebase that’s maintainable and not fragile.
3. Be intellectually excited by what we’re working on.
4. Do it with limited time and resources. As fast and
lean as possible.
And that’s why culture matters.
Wednesday, October 9, 13
Why should culture matter to you?
Wednesday, October 9, 13
Are you about to enter the job market?
Don’t join a company just for their product.
Join for their culture.
Wednesday, October 9, 13
Are you a founding engineer?
You are shaping the culture for all the engineers
that will come after you.
Make it a good one.
Wednesday, October 9, 13
Are you in an established culture?
You still have the power to change the culture.
Nothing is set in stone.
Wednesday, October 9, 13
My Experience
Wednesday, October 9, 13
Joined when Google was X years old.
Spent 5 years in developer relations
Wednesday, October 9, 13
Joined when Coursera was 5 months old.
1 year as Frontend Engineer
Wednesday, October 9, 13
Joined when KA was 2 years old.
2 months (so far!) as engineer/educator.
Wednesday, October 9, 13
What makes a culture?
Wednesday, October 9, 13
The Engineering Lifecycle
Onboarding
Writing Code:
* Understanding existing code
* Planning your code
* Writing consistent code
* Testing your code
* Improving your code
* Releasing your code
* Monitoring your code
* Learning from bad code
while(1) {
writeCode();
}
Wednesday, October 9, 13
Onboarding
Bad culture: Treats your first week as “initiation”.
Good culture: Values getting everyone over the
beginners hump with as many resources as possible.
Wednesday, October 9, 13
On-boarding
Monday:
Morning:
- Talks: Overview, HR
- Take Photos for Team Page
Lunch: Show & Tell
Afternoon:
- Talk: Backend Architecture
- Talk: Frontend Architecture
- Talk: Code Review Process
- Deploy first change together!
- Meet your team
Tuesday:
- Work on a small change
- Deploy small change
Wednesday-Friday:
- Pick first big project
- Brainstorming meetings
with designers
- Begin working on it!
Wednesday, October 9, 13
On-boarding
https://sites.google.com/a/khanacademy.org/forge/for-khan-employees/-new-employees-onboard-doc/developer-setup
Self-paced on-boarding:
On-demand help:
Wednesday, October 9, 13
Understanding
the current code
Bad culture: Expects everyone to just “figure it out.”
Good culture: Values over-communication about what
the code does, and why it does it that way.
Wednesday, October 9, 13
Comments
# Deprecated - this is true if the problem was done while in
# context-switching topic mode, which has since been removed from the site.
# TODO(benkomalo): Remove when all references are dead
topic_mode = db.BooleanProperty(indexed=False, default=False)
def consume_optional_goog_info(self, goog_user):
"""Assigns user information from Google to this UserData.
Does not call put() on this entity and expects callers to do so.
Args:
goog_user An instance of google.appengine.api.users.User
Returns: whether or not fields were consumed and this entity was modified
"""
import feature_flags.infection # sad circular dependency fix :(
"""Holds UserData, UniqueUsername, NicknameIndex
UserData: database entity holding information about a single registered user
UniqueUsername: database entity of usernames that've been set on profile pages
NicknameIndex: database entity allowing search for users by their nicknames
"""
module
function
TODOs + deprecation
Sadness
Wednesday, October 9, 13
High-level Docs
http://blog.pamelafox.org/2013/07/rewriting-django-admin-in-backbone.html
http://blog.pamelafox.org/2013/03/rewriting-our-forums-with-backbone.html
http://www.youtube.com/watch?v=hgZWMSDl0P8
Wednesday, October 9, 13
Writing consistent code
Bad culture: Doesn’t care how the code is written, as
long as it works.
Good culture: Values a codebase where the code
looks the same and seems to all belong together.
Wednesday, October 9, 13
https://sites.google.com/a/khanacademy.org/forge/for-developers/styleguide
>> git commit
Linting...
LINT OKAY: No lint problems
Guides
Tools
+
Language Style
Wednesday, October 9, 13
Design Style
• coursera: com
•
http://khanacademy.org/style
Guides Re-usable CSS+
// Typography
@baseFontSize: 13px;
@baseFontFamily: MuseoSans300,
"Helvetica Neue", Helvetica, Arial, sans-
serif;
@baseLineHeight: 22px;
@textColor: #444;
@lightTextColor: #898989;
@fontSizeTiny: 11px;
@fontSizeSmall: 12px;
@fontSizeNormal: 14px;
@fontSizeMedium: 16px;
@fontSizeLarge: 18px;
@fontSizeExtraLarge: 24px;
@fontSizeHuge: 36px;
// Buttons
@primaryButtonBackground: #89b908;
@primaryButtonBorder: #76a005;
@buttonTextColor: lighten(@grayDark,
15%);
@buttonBorderRadius: 3px;
Wednesday, October 9, 13
Best Practices
http://blog.pamelafox.org/2013/07/a-guide-to-writing-backbone-apps-at.html
http://blog.pamelafox.org/2013/08/javascript-ui-library-design.html
Architecture
Tools/Libraries
APIs
...and tons more.
Wednesday, October 9, 13
Writing consistent code
Do you follow standard conventions for every
language in their stack?
Do you have your own conventions for the
frameworks you use?
Wednesday, October 9, 13
Testing your codeTesting your code
Bad culture: Expects you to write “safe” code, that’s
magically free of bugs because you’re all so smart.
Good culture: Realizes that tests are the key to a
stable and maintainable codebase.
Wednesday, October 9, 13
Backend: Python/Django unit tests
Testing Code
http://blog.pamelafox.org/2013/06/testing-backbone-frontends.html
Frontend: Mocha/Chai/JSDom
Integration: Selenium*
Manual: QA Process, Engineer, and Team
Automated tests CI
+
Wednesday, October 9, 13
Testing Code
Test education
Test engineers
http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html
https://www.google.com/about/jobs/search/#!t=jo&jid=35182&
Wednesday, October 9, 13
Testing your codeTesting your code
Are there any tests?
What kind of tests?
How often are the tests run?
Is there a testing requirement for new features?
Is there a testing engineer or testing team?
Wednesday, October 9, 13
Improving your code
Bad culture: Gives you no feedback on your code or
gives you non-constructive criticism on your code.
Good culture: Recognizes that code reviews are a
great way for everyone to learn from each other.
Wednesday, October 9, 13
Code Reviews
http://phabricator.org/
>> arc diff
>> arc land --onto master
Tools
Wednesday, October 9, 13
Code Reviews
https://sites.google.com/a/khanacademy.org/forge/for-developers/code-review-policy
+ Docs
Wednesday, October 9, 13
Improving your code
Are code reviews a part of the engineering process?
Are code reviews *required*?
What tool do you use for code reviews?
Wednesday, October 9, 13
Releasing your code
Bad culture: Makes it hard to release code early and often.
Good culture: Enables everyone to release their code
with minimal time and pain.
Wednesday, October 9, 13
Release Process
http://betacs.pro/blog/2013/07/06/wayland/
8 minutes to deploy
2 minutes to rollback
Wednesday, October 9, 13
Releasing your code
How often is code deployed?
How fast is the process?
How fast is the rollback?
Who's in charge of a deploy?
Wednesday, October 9, 13
Monitoring your code
Bad culture: Releases code without paying attention to
how it fares in the wild.
Good culture: Recognizes the value of logging, alerts,
and user feedback mechanisms to ensure code validity.
Wednesday, October 9, 13
Monitoring
Backend
monitoring
+
Alerts
Wednesday, October 9, 13
Monitoring
Frontend
monitoring
User feedback alerts
Wednesday, October 9, 13
Monitoring your code
Are backend and frontend errors monitored?
Are there user feedback mechanisms?
Are there smart alerts set up?
Wednesday, October 9, 13
Learning from bad code
Bad culture: Sweeps mistakes under the rug, refusing to
acknowledge or learn from them, or blames them on a
bad coder.
Good culture: Realizes that mistakes are an opportunity
for the *whole team* to learn and improve.
Wednesday, October 9, 13
Post-Mortems
• Timeline of events
• What went wrong?
• What went right?
• What specific action items would prevent this
from happening in the future?
https://groups.google.com/forum/#!topic/google-appengine/p2QKJ0OSLc8
Don’t blame. Learn.
Wednesday, October 9, 13
Post-Mortems
• Coding bugs: “The Mass Unenrollment”
• Server faults: “The Overloaded Database”
• Security issues: “Cross-site-scripting in PHP”
• Process flaws: “The Class Recyling Project”
Wednesday, October 9, 13
Learning from your code
When bad decisions are made in code, how does
the the team learn from them?
Wednesday, October 9, 13
Now what?
Learn from others
Share with your team
Experiment
Share with others
“Team Geek” by Fitzpatrick and Collins-Sussman
http://blog.pamelafox.org/2013/07/what-to-look-for-in-software.html
http://www.joelonsoftware.com/articles/fog0000000043.html
Wednesday, October 9, 13
The culture matters as
much as the product.
Wednesday, October 9, 13
THAR! Here be dragons!
Wednesday, October 9, 13
Planning your code
Bad culture: Expects great code to emerge with no
thought or collaboration.
Good culture: Values the process of planning code.
Wednesday, October 9, 13
Design Docs
• google template?
• can happen in a jira discussion
Wednesday, October 9, 13
Design Discussions
• whiteboard
Wednesday, October 9, 13

Engineering culture

  • 1.
    Engineering Culture What isit? What makes it great? Wednesday, October 9, 13
  • 2.
    What I learntin college artificial intelligence graphics java data structures algorithms calculus C++ databases networking how to write code Wednesday, October 9, 13
  • 3.
    ...What I didn’tlearn how to write code *for a company* communication code reviews conventions release process testing post mortems documentation onboarding Wednesday, October 9, 13
  • 4.
    Different goals College Company Provethat we understand a concept or mastered a skill. 1. Create a product that makes users happy. 2. Create a codebase that’s maintainable and not fragile. 3. Be intellectually excited by what we’re working on. 4. Do it with limited time and resources. As fast and lean as possible. Wednesday, October 9, 13
  • 5.
    That’s a lotto achieve... 1. Create a product that makes users happy. 2. Create a codebase that’s maintainable and not fragile. 3. Be intellectually excited by what we’re working on. 4. Do it with limited time and resources. As fast and lean as possible. And that’s why culture matters. Wednesday, October 9, 13
  • 6.
    Why should culturematter to you? Wednesday, October 9, 13
  • 7.
    Are you aboutto enter the job market? Don’t join a company just for their product. Join for their culture. Wednesday, October 9, 13
  • 8.
    Are you afounding engineer? You are shaping the culture for all the engineers that will come after you. Make it a good one. Wednesday, October 9, 13
  • 9.
    Are you inan established culture? You still have the power to change the culture. Nothing is set in stone. Wednesday, October 9, 13
  • 10.
  • 11.
    Joined when Googlewas X years old. Spent 5 years in developer relations Wednesday, October 9, 13
  • 12.
    Joined when Courserawas 5 months old. 1 year as Frontend Engineer Wednesday, October 9, 13
  • 13.
    Joined when KAwas 2 years old. 2 months (so far!) as engineer/educator. Wednesday, October 9, 13
  • 14.
    What makes aculture? Wednesday, October 9, 13
  • 15.
    The Engineering Lifecycle Onboarding WritingCode: * Understanding existing code * Planning your code * Writing consistent code * Testing your code * Improving your code * Releasing your code * Monitoring your code * Learning from bad code while(1) { writeCode(); } Wednesday, October 9, 13
  • 16.
    Onboarding Bad culture: Treatsyour first week as “initiation”. Good culture: Values getting everyone over the beginners hump with as many resources as possible. Wednesday, October 9, 13
  • 17.
    On-boarding Monday: Morning: - Talks: Overview,HR - Take Photos for Team Page Lunch: Show & Tell Afternoon: - Talk: Backend Architecture - Talk: Frontend Architecture - Talk: Code Review Process - Deploy first change together! - Meet your team Tuesday: - Work on a small change - Deploy small change Wednesday-Friday: - Pick first big project - Brainstorming meetings with designers - Begin working on it! Wednesday, October 9, 13
  • 18.
  • 19.
    Understanding the current code Badculture: Expects everyone to just “figure it out.” Good culture: Values over-communication about what the code does, and why it does it that way. Wednesday, October 9, 13
  • 20.
    Comments # Deprecated -this is true if the problem was done while in # context-switching topic mode, which has since been removed from the site. # TODO(benkomalo): Remove when all references are dead topic_mode = db.BooleanProperty(indexed=False, default=False) def consume_optional_goog_info(self, goog_user): """Assigns user information from Google to this UserData. Does not call put() on this entity and expects callers to do so. Args: goog_user An instance of google.appengine.api.users.User Returns: whether or not fields were consumed and this entity was modified """ import feature_flags.infection # sad circular dependency fix :( """Holds UserData, UniqueUsername, NicknameIndex UserData: database entity holding information about a single registered user UniqueUsername: database entity of usernames that've been set on profile pages NicknameIndex: database entity allowing search for users by their nicknames """ module function TODOs + deprecation Sadness Wednesday, October 9, 13
  • 21.
  • 22.
    Writing consistent code Badculture: Doesn’t care how the code is written, as long as it works. Good culture: Values a codebase where the code looks the same and seems to all belong together. Wednesday, October 9, 13
  • 23.
    https://sites.google.com/a/khanacademy.org/forge/for-developers/styleguide >> git commit Linting... LINTOKAY: No lint problems Guides Tools + Language Style Wednesday, October 9, 13
  • 24.
    Design Style • coursera:com • http://khanacademy.org/style Guides Re-usable CSS+ // Typography @baseFontSize: 13px; @baseFontFamily: MuseoSans300, "Helvetica Neue", Helvetica, Arial, sans- serif; @baseLineHeight: 22px; @textColor: #444; @lightTextColor: #898989; @fontSizeTiny: 11px; @fontSizeSmall: 12px; @fontSizeNormal: 14px; @fontSizeMedium: 16px; @fontSizeLarge: 18px; @fontSizeExtraLarge: 24px; @fontSizeHuge: 36px; // Buttons @primaryButtonBackground: #89b908; @primaryButtonBorder: #76a005; @buttonTextColor: lighten(@grayDark, 15%); @buttonBorderRadius: 3px; Wednesday, October 9, 13
  • 25.
  • 26.
    Writing consistent code Doyou follow standard conventions for every language in their stack? Do you have your own conventions for the frameworks you use? Wednesday, October 9, 13
  • 27.
    Testing your codeTestingyour code Bad culture: Expects you to write “safe” code, that’s magically free of bugs because you’re all so smart. Good culture: Realizes that tests are the key to a stable and maintainable codebase. Wednesday, October 9, 13
  • 28.
    Backend: Python/Django unittests Testing Code http://blog.pamelafox.org/2013/06/testing-backbone-frontends.html Frontend: Mocha/Chai/JSDom Integration: Selenium* Manual: QA Process, Engineer, and Team Automated tests CI + Wednesday, October 9, 13
  • 29.
    Testing Code Test education Testengineers http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html https://www.google.com/about/jobs/search/#!t=jo&jid=35182& Wednesday, October 9, 13
  • 30.
    Testing your codeTestingyour code Are there any tests? What kind of tests? How often are the tests run? Is there a testing requirement for new features? Is there a testing engineer or testing team? Wednesday, October 9, 13
  • 31.
    Improving your code Badculture: Gives you no feedback on your code or gives you non-constructive criticism on your code. Good culture: Recognizes that code reviews are a great way for everyone to learn from each other. Wednesday, October 9, 13
  • 32.
    Code Reviews http://phabricator.org/ >> arcdiff >> arc land --onto master Tools Wednesday, October 9, 13
  • 33.
  • 34.
    Improving your code Arecode reviews a part of the engineering process? Are code reviews *required*? What tool do you use for code reviews? Wednesday, October 9, 13
  • 35.
    Releasing your code Badculture: Makes it hard to release code early and often. Good culture: Enables everyone to release their code with minimal time and pain. Wednesday, October 9, 13
  • 36.
    Release Process http://betacs.pro/blog/2013/07/06/wayland/ 8 minutesto deploy 2 minutes to rollback Wednesday, October 9, 13
  • 37.
    Releasing your code Howoften is code deployed? How fast is the process? How fast is the rollback? Who's in charge of a deploy? Wednesday, October 9, 13
  • 38.
    Monitoring your code Badculture: Releases code without paying attention to how it fares in the wild. Good culture: Recognizes the value of logging, alerts, and user feedback mechanisms to ensure code validity. Wednesday, October 9, 13
  • 39.
  • 40.
  • 41.
    Monitoring your code Arebackend and frontend errors monitored? Are there user feedback mechanisms? Are there smart alerts set up? Wednesday, October 9, 13
  • 42.
    Learning from badcode Bad culture: Sweeps mistakes under the rug, refusing to acknowledge or learn from them, or blames them on a bad coder. Good culture: Realizes that mistakes are an opportunity for the *whole team* to learn and improve. Wednesday, October 9, 13
  • 43.
    Post-Mortems • Timeline ofevents • What went wrong? • What went right? • What specific action items would prevent this from happening in the future? https://groups.google.com/forum/#!topic/google-appengine/p2QKJ0OSLc8 Don’t blame. Learn. Wednesday, October 9, 13
  • 44.
    Post-Mortems • Coding bugs:“The Mass Unenrollment” • Server faults: “The Overloaded Database” • Security issues: “Cross-site-scripting in PHP” • Process flaws: “The Class Recyling Project” Wednesday, October 9, 13
  • 45.
    Learning from yourcode When bad decisions are made in code, how does the the team learn from them? Wednesday, October 9, 13
  • 46.
    Now what? Learn fromothers Share with your team Experiment Share with others “Team Geek” by Fitzpatrick and Collins-Sussman http://blog.pamelafox.org/2013/07/what-to-look-for-in-software.html http://www.joelonsoftware.com/articles/fog0000000043.html Wednesday, October 9, 13
  • 47.
    The culture mattersas much as the product. Wednesday, October 9, 13
  • 48.
    THAR! Here bedragons! Wednesday, October 9, 13
  • 49.
    Planning your code Badculture: Expects great code to emerge with no thought or collaboration. Good culture: Values the process of planning code. Wednesday, October 9, 13
  • 50.
    Design Docs • googletemplate? • can happen in a jira discussion Wednesday, October 9, 13
  • 51.