Download to read offline
Uploaded byChristian Heilmann
Sacrificing the golden calf of "coding"
Chris Heilmann gave a talk at BTConf in Munich in January 2018 about machine learning, automation worries, and coding. He discussed how coding used to refer to creative programming within technical limitations but now often refers to programming for work. He addressed common worries about new technologies and dependencies, and argued that abstractions are not inherently bad and help more people build products together through consensus. The talk focused on using tools to be more productive and enabling rather than seeing them as dangers, and creating solutions for users rather than fighting old approaches.
More Related Content
Similar to Sacrificing the golden calf of "coding"
Sacrificing the golden calf of "coding"
- 1. Chris Heilmann (codepo8),BTConf, Munich, January 2018
- 2.
- 3.
- 4. Machine Learning andAI is hot.
- 5.
- 6. Blanket solution: Everybody mustlearn how to code.
- 7. But we’re notimmune, either… https://twitter.com/mattrickard/status/941065444919840769
- 8. Let’s rewind fora bit…
- 9. To me, codingwas a demo scene term.
- 10. Coding in thedemo scene: Programming in a creative fashion, pushing the boundaries of limited environments
- 11. + performance + cleverness +inventiveness - maintainability - readability
- 12.
- 13. + maintainability + readability ~cleverness ~ performance - inventiveness Coding for a living (my idea):
- 14.
- 15. Results that keptus busy: Worries of the battle- weary people of the web.
- 16. Environment optimisation Browser $xis the new IE6! People who optimise for it are terrible and probably kick puppies!
- 17. Kittens will dieand unloved code will clog up the web! Reliance on abstractions What if $library or $framework goes away and that’s all people learned?
- 18. Third-party dependencies Frantically copyyour code to floppy disks for safekeeping, that’s what! Yes, $service is amazing, but what will you do when it is gone?
- 19. Are you sureit doesn’t like Trump tweets on your behalf? Third-party dependencies Sure, $package does solve this problem for you, but you don’t own it and you don’t know what it does.
- 20. In my daysall we needed was two lines of CSS and changed it every four days! Generic code bloat Generic code tries to solve too many things you don’t need solving.
- 21. My clients haven’tupgraded in years, if malware developers can support them, so should you! Backwards compatibility Sure, $feature of the web is cool, but what about people on older browsers?
- 22. Notepad and FTPwas good enough for me and made me the person I am today! Maintaining a simple starting point Everybody is invited to build for the web. You don’t need to use a certain editor or training.
- 23. We’re good at inventingand advocating best practices…
- 24. Less so atusing them…
- 25.
- 26.
- 27. The curious caseof Benjamin a Button Story time:
- 28. Professional development: “Wow, howdid you do that?” “Have you finished this?” Instead we get: Only a few of us ever hear:
- 32. Everything counts inlarge amounts
- 33. It is notabout building the perfect, gorgeous, beautiful solution.
- 34. Ubiquity demands simpler, disposable andmodular solutions to cover the growing demand.
- 35. With increased complexity anddemand, any software product will sooner or later use pre-built components. The natural software evolution:
- 36. ▪ Easy touse ▪ Easy to keep updated ▪ Limited pollution of the final product ▪ Appropriate tooling Great components:
- 37. These are problems, but datedones, many of which have technical solutions. ▪ Environment optimisation ▪ Reliance on abstractions ▪ Third party dependencies ▪ Generic code bloat ▪ Backwards compatibility ▪ Maintaining a simple starting point Worries of the battle-weary people of the web
- 38. Why is thisall so complex? medium.freecodecamp.org/making-sense-of-front-end-build-tools-3a1b3a87043b
- 39. Toolchains and processes: Ensuringthat large teams can work safely together.
- 40. From code topeople: We create code that might not be optimised, but is easier to convert and maintain.
- 41. A common evolution: Languagesget abstractions to solve common tasks with less code.
- 42. A simple task: Findthe largest member of an array
- 43.
- 44. Using built-in methodsand objects…
- 45. Keeping it conciseand up-to-date…
- 46. Humans rely heavilyon technology these days. Some things to consider:
- 47. This gives usplenty of opportunity to endanger our end users. Some things to consider:
- 48. Abstractions are not inherentlya “lazy way out” or “dangerous”… Some things to consider:
- 49. Abstractions are aconsensus to enable lots of people to build bigger and better products. Some things to consider:
- 50. To play wellwith others, we need to establish rules.
- 51. We’re not codewarriors fighting the man or the good fight. Old approaches don’t apply:
- 52. We are engineersbuilding solutions in teams for people to use. Focusing on the end product:
- 53. It may bethe warriors who get the glory. But it's the engineers who build societies. – Steve Jobs
- 54. It may bethe warriors who get the glory. But it's the engineers who build societies. – B'elanna Torres
- 55. “That’s the dutyof the old,” said the Librarian, “to be anxious on behalf of the young. And the duty of the young is to scorn the anxiety of the old. – Pullman, Philip. “The Northern Lights.”
- 56. It is muchmore important what you create than how you do it. ▪ Environment optimisation ▪ Reliance on abstractions ▪ Third party dependencies ▪ Generic code bloat ▪ Backwards compatibility ▪ Maintaining a simple starting point Worries of the battle-weary people of the web
- 57. I envy peoplewho start now:
- 58. Good tools teachyou code while you write it. Tooling helps us:
- 59. Open and extensible editors thatintegrate with our workflows and environments. code.visualstudio.com
- 60. Linting and auto- completebuilt in – think autocorrect for code… vscodecandothat.com
- 61.
- 62. Good tools allowyou to find bottlenecks and obvious flaws. Tooling helps us:
- 63. Browsers come with excellentdevelopment and debugging tools.
- 64. Linting and validation toolstell us what to fix – even as a continuous integration step. sonarwhal.com
- 65. Thinking with reusable componentsis not only a thing for coders.
- 66. More tools andprocesses to strip the overhead before shipping to the end user. The digital hoarding solution: It flows over into the design space. Style guides, pattern libraries.
- 67. When we have predictable,reusable and well working parts to mix and match we can go even further…
- 68. Computers are goodat repeating things, finding patterns and improving them. Humans suck at that.
- 69.
- 70.
- 71. We built aninitial prototype using about a dozen hand-drawn components as training data, open source machine learning algorithms, and a small amount of intermediary code to render components from our design system into the browser. We were pleasantly surprised with the result: airbnb.design/sketching-interfaces
- 72. We built aninitial prototype using about a dozen hand-drawn components as training data, open source machine learning algorithms, and a small amount of intermediary code to render components from our design system into the browser. We were pleasantly surprised with the result: blog.floydhub.com/turning-design-mockups-into-code-with-deep-learning/
- 73. We built aninitial prototype using about a dozen hand-drawn components as training data, open source machine learning algorithms, and a small amount of intermediary code to render components from our design system into the browser. “ airbnb.design/sketching-interfaces
- 74. But where isthe fun in all that?
- 75.
- 76. Questioning the dogma: Everybodymust learn how to code.
- 77. Questioning the dogma: Everybodymust learn how to solve problems.
- 78. ▪ To creategorgeous new components ▪ To run unencumbered pet projects ▪ To help better the tools we use ▪ To play with upcoming tech ▪ To drop out of the rat race and clear our heads ▪ To help each other when we’re stuck ▪ To help others get excited about what we do By automating the neccessary we gain time:
- 79.