Developing in Public

309
-1

Published on

Daniel Hengeveld's talk from Future Insights Live 2014 in Las Vegas: "When we work on software with others, we expect that our collaborators will share their *code* in a way that makes it easy to see what they’ve been working on. We should have the same expectation for all the *other* artifacts of software development."

Miss his talk? Join us at a future show: www.futureofwebapps.com. Sign up for our newsletter at futureinsights.com and get 15% off your next conference.

Published in: Internet, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
309
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Developing in Public

  1. 1. DEVELOPING IN PUBLIC
  2. 2. STORY TIME
  3. 3. ▸ navigation team couldn't drive ▸ system engineering checks were weak ▸ informal communication channels
  4. 4. some communications channels among project engineering groups were too informal
  5. 5. too informal
  6. 6. NOT A SOFTWARE PROBLEM?
  7. 7. A HUMAN PROBLEM
  8. 8. HOW CAN WE DO BETTER?
  9. 9. SOFTWARE ARCHAEOLOGY
  10. 10. commit 9e3ce0965868f1e9af385951cf1e22960d0edf0d Author: Kevin Sawicki & Nathan Sobo <kevin+nathan@github.com> Date: Wed May 21 18:04:44 2014 -0600 Add thruster input We need to take the thrust input from the propulsion bus and fire the thrusters accordingly
  11. 11. OK, maybe we've mostly solved this for code.
  12. 12. ▸ Use version control ▸ write good commit messages ▸ use feature branches ▸ the list goes on...
  13. 13. I GUESS MY TALK CAN BE OVER?
  14. 14. /NOPE
  15. 15. HERE'S A CLICHÉ
  16. 16. It's better to work together than to work alone
  17. 17. What if “together” is miles and hours apart?
  18. 18. What did she do yesterday?
  19. 19. What did I do yesterday?"
  20. 20. SOFTWARE != SOFTWARE DEVELOPMENT
  21. 21. SOFTWARE ⊆ SOFTWARE DEVELOPMENT
  22. 22. [********] Coding [***] Communicating / coordinating [**] Reviewing code / PRs to merge [**] Runtime / CI / infrastructure [*] Long term project planning
  23. 23. SO
  24. 24. WHAT'S THE WORK?
  25. 25. (Here come some dirty words)
  26. 26. MANAGEMENT
  27. 27. POLITICS
  28. 28. Other people are your allies, in other words, but that alliance takes sustained effort to build. And you should be prepared for that, not irritated by it. Ed Catmull
  29. 29. DOCUMENTATION
  30. 30. TRANSCRIPTION
  31. 31. STARING OFF INTO SPACE DESIGN
  32. 32. Oh, and just one more thing...
  33. 33. CODING
  34. 34. SOME TOOLS
  35. 35. WIP PRS
  36. 36. ALWAYS BE PAIRING
  37. 37. CHATOPS
  38. 38. /ci status <repo>/<branch> /deploy team to stg /graph me -10min @app-perf (or something) /procs unicorn /resque critical /conns fe1 /who's on call
  39. 39. WHY IS THIS STUPID CHAT BOT SO IMPORTANT?
  40. 40. What if we don't have a Hubot?
  41. 41. A SELF-REPORTING CULTURE
  42. 42. EMBRACE GOOD TOOLS
  43. 43. YOUR TOOLS = YOUR OFFICE
  44. 44. BE PREDICTABLE
  45. 45. prefer communication
  46. 46. DON'T BLOCK
  47. 47. TELL ME WHY
  48. 48. TRULY PRODUCTIVE REMOTE WORK
  49. 49. FAST ONBOARDING
  50. 50. TRANSPARENT STRATEGIES & #REALTALK
  51. 51. NO ONE GETS LOST
  52. 52. DEVELOP IN PUBLIC BECAUSE.. ▸ it enables remote work ▸ gets new people started fast ▸ teaches your teammates how your brain works ▸ Exposes failure early enough to fix it
  53. 53. Daniel Hengeveld Softwaresman, GitHub @thedaniel thedaniel.github.io

×