Keynote at BTConf Munich https://vimeo.com/251427758

1. Chris Heilmann (codepo8), BTConf, Munich, January 2018

2. twitter.com/codepo8/status/922380136531537921

3. money.cnn.com/2018/01/15/technology/reading-robot-alibaba-microsoft-stanford/index.html
Machine Learning and AI is hot.

4. Machine Learning and AI is hot.

5. Automation worries everybody
http://wumo.com/wumo/2017/10/28

6. Blanket solution:
Everybody must learn
how to code.

7. But we’re not immune, either…
https://twitter.com/mattrickard/status/941065444919840769

8. Let’s rewind for a bit…

9. To me, coding was a
demo scene term.

10. Coding in the demo scene:
Programming in a
creative fashion,
pushing the
boundaries of limited
environments

11. + performance
+ cleverness
+ inventiveness
- maintainability
- readability

12. Coder
Programmer
Developer
Engineer

13. + maintainability
+ readability
~ cleverness
~ performance
- inventiveness
Coding for a living (my idea):

14. This wasn’t easy…

15. Results that kept us busy:
Worries of the battle-
weary people of the web.

16. Environment optimisation
Browser $x is the new IE6!
People who optimise for it are
terrible and probably kick puppies!

17. Kittens will die and 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 copy your 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 sure it 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 days all 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’t upgraded 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 FTP was 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
inventing and
advocating best
practices…

24. Less so at using them…

25. Why is that?

26. People are people…

27. The curious case of
Benjamin a Button
Story time:

28. Professional development:
“Wow, how did you do that?”
“Have you finished this?”
Instead we get:
Only a few of us ever hear:

32. Everything counts in large amounts

33. It is not about
building the
perfect, gorgeous,
beautiful solution.

34. Ubiquity demands
simpler, disposable
and modular solutions
to cover the growing
demand.

35. With increased complexity
and demand, any software
product will sooner or later
use pre-built components.
The natural software evolution:

36. ▪ Easy to use
▪ Easy to keep
updated
▪ Limited pollution of
the final product
▪ Appropriate tooling
Great components:

37. These are
problems, but
dated ones, 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 this all so complex?
medium.freecodecamp.org/making-sense-of-front-end-build-tools-3a1b3a87043b

39. Toolchains and processes:
Ensuring that large teams can
work safely together.

40. From code to people:
We create code that might not
be optimised, but is easier to
convert and maintain.

41. A common evolution:
Languages get abstractions to
solve common tasks with less
code.

42. A simple task:
Find the largest member
of an array

43. Keeping it basic…

44. Using built-in methods and objects…

45. Keeping it concise and up-to-date…

46. Humans rely heavily on
technology these days.
Some things to consider:

47. This gives us plenty of
opportunity to endanger our
end users.
Some things to consider:

48. Abstractions are not
inherently a “lazy way out” or
“dangerous”…
Some things to consider:

49. Abstractions are a consensus
to enable lots of people to
build bigger and better
products.
Some things to consider:

50. To play well with
others, we need to
establish rules.

51. We’re not code warriors
fighting the man or the good
fight.
Old approaches don’t apply:

52. We are engineers building
solutions in teams for people
to use.
Focusing on the end product:

53. It may be the warriors
who get the glory. But
it's the engineers who
build societies.
– Steve Jobs

54. It may be the warriors
who get the glory. But
it's the engineers who
build societies.
– B'elanna Torres

55. “That’s the duty of 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 much more
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 people who start now:

58. Good tools teach you code
while you write it.
Tooling helps us:

59. Open and
extensible editors
that integrate with
our workflows and
environments.
code.visualstudio.com

60. Linting and auto-
complete built in –
think autocorrect
for code…
vscodecandothat.com

61. Collaborative
editing and
education tools.
code.visualstudio.com/blogs/2017/11/15/live-share
codepen.io
jsbin.com
glitch.com

62. Good tools allow you to find
bottlenecks and obvious flaws.
Tooling helps us:

63. Browsers come with
excellent development and
debugging tools.

64. Linting and validation
tools tell us what to
fix – even as a
continuous
integration step.
sonarwhal.com

65. Thinking with reusable
components is not
only a thing for
coders.

66. More tools and processes
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 good at
repeating things, finding
patterns and improving
them.
Humans suck at that.

69. autodraw.com

70. quickdraw.withgoogle.com

71. We built an initial 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 an initial 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 an initial 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 is the
fun in all that?

75. twitter.com/kurtiskemple/status/930419045769318400
Humans > Machines

76. Questioning the dogma:
Everybody must learn
how to code.

77. Questioning the dogma:
Everybody must learn
how to solve problems.

78. ▪ To create gorgeous 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. Chris Heilmann
@codepo8