About-Face: Reflections on growing an open-source mentality

Transcript

1. About-Face REFLECTIONS ON GROWING AN OPEN-SOURCE MENTALITY
2. About-Face HOW I SNUCK A CULTURE TALK INTO NODEDAY AMSTERDAM
3. Self-Destruct HOW TO WRITE A SELF-DEFEATING TALK
4. PLEASE ALLOW MYSELF TO PROPERLY INTRODUCE MYSELF
5. Jean-Charles Sisk twitter/@jcse • github/jasisk • jeancharles@paypal ▸ BOSTON, MA, USA ▸ ENGINEER ▸ PAYPAL
6. "I have hats older than your country." — Europeans
15. Jean-Charles Sisk twitter/@jcse • github/jasisk • jeancharles@paypal ▸ BOSTON, MA, USA ▸ ENGINEER ▸ PAYPAL
16. i said YES
18. THE JOB I HAVE
19. I work, primarily, on OPEN SOURCE SOFTWARE
20. JOB I WISH I HAD MATCHING FAMILY SWEATSHIRT MODEL
21. NODEJS
23. you're in luck, I AM NOT GOING TO TALK ABOUT NODEJS
24. SINCE ADOPTING NODEJS IN 2012 ▸ massive growth in app-engineer developed componentry ▸ greatly improved developer happiness ▸ significantly faster time to live
25. OUR APPLICATIONS APPEAR TO HAVE BEEN BUILT IN THE 21ST CENTURY
27. REMEMBER WHEN PAYPAL LOOKED LIKE THIS?
28. Technology adoption checklist: ▸ TECHNOLOGY ▸ PROCESS ▸ CULTURE
29. don't worry, I'M STILL NOT GOING TO TALK ABOUT NODEJS
30. Technology adoption checklist: ▸ TECHNOLOGY ▸ PROCESS ▸ CULTURE
31. NODEJS WAS A TROJAN HORSE
32. "If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long." — Taiichi Ohno
33. But first: A BRIEF HISTORY
34. OOPS
35. PAYPAL IN THE MID-AUGHTS WAS DRIVEN EXCLUSIVELY BY RISK MITIGATION
36. SLOW BY DESIGN
37. Developers: CREATURES OF HABIT
38. TRUST NO ONE
39. nih (NOT INVENTED HERE)
40. GREAT FOR FARMS—NOT GREAT FOR YOU UNLESS YOU FARM, IN WHICH CASE I'M IMPRESSED
41. "everything is a secret and I trust no one." — Developers
42. PAYPAL IN THE MID-AUGHTS WAS DRIVEN EXCLUSIVELY BY RISK MITIGATION
43. !
44. THE CULTURE WAS THE REAL REASON FOR THE DECISION TO CHANGE THE TECHNOLOGY WAS HOW WE SOLD IT
45. HOW?
46. start small
47. TEAR IT DOWN
48. BUILD IT BACK UP
49. TRANSPARENTLY?
50. CONSIDER EVERYTHING BUT DON'T BE AFRAID TO SAY NO
51. TRANSPARENCY: I lied. ENJOY THE FOLLOWING NODEJS CODE
52. HOW TO WRITE AN EXPRESS APP import Express from 'express'; const app = Express(); app.listen(8000);
53. HOW TO WRITE A KRAKEN APP import Express from 'express'; import Kraken from 'kraken-js'; const app = Express(); app.use(Kraken()); app.listen(8000);
54. HOW TO WRITE A PAYPAL APP import Express from 'express'; import Kraken from 'kraken-js'; import PayPal from 'paypalize'; const app = Express(); const opts = PayPal(); app.use(Kraken(opts)); app.listen(8000);
55. So … WHAT DOES THAT GIVE US?
56. dynamic service mapping, local secrets decryption, service configuration, PayPal standard configuration (csrf, x-frame, etc), central logging, central cookie handling, central device-detection, central session handling, central exception tracking, monitoring, analytics, app heath-checks, infra-specific uncaught exception handling, CDN awareness … … you generally wouldn't know that unless you read the README.
57. RELY ON EXISTING COMMUNITY CONVENTIONS
58. when you're not wasting time learning and fighting your internal systems, you have time to accomplish the job you signed up for
59. Homework: SEE WHAT KATHY SIERRA HAS TO SAY ABOUT DEPLETING COGNITIVE RESOURCES1 1 youtu.be/FKTxC9pl-WM
60. "Fine, but that's a lot of work for one line. Isn't that too magical?" — you
61. Absolutely BUT THERE'S A CATCH
62. EVERYTHING IS IN THE OPEN WITH AN EMPHASIS ON DOCUMENTATION AND DISCOVERABILITY
64. "What about our process? We can't make [custom-x] an open process." — you
65. K. DON'T. BUT FIND A WAY TO MAKE IT WORK
66. HOOK INTO COMMON PROCESSES ▸ Source Control ▸ Continuous Integration ▸ Distribution Service ▸ Deployment
67. consider optimism ASSUME SUCCESS AND GOOD INTENTIONS FOR NON- CRITICAL SYSTEMS AND APPLICATIONS
68. ADOPTING COMMON CONVENTION AND BUILDING IN THE OPEN BUILDS TRUST
69. PROMOTING TRUST: COMMUNITY
70. BUILDING COMMUNITY: CULTURE
71. … big finish …
72. IT SHOULD COME AS NO SURPRISE THAT THESE ARE PRECISELY THE WAYS LARGE- SCALE OPEN-SOURCE PROJECTS WORK
73. … wall of text alert …
74. Building our projects as if they're open-source even with no intention of ever opening them up has lead to better documentation, discoverability, ownership, responsibility, code-quality, efficacy, etc. By emulating practices we've seen and used in the open-source community, we've seen tremendous growth from both seasoned developers and new hires alike. By simply adopting open principles, PayPal is a measurably better place to work.
75. Thanks. @JCSE