Aysylu Greenberg

Twitter: @aysylu22


Aysylu Greenberg works at Google on Drive infrastructure. In her spare time, she ponders the design of systems that deal with inaccuracies, paints and sculpts. Aysylu's first functional language was Clojure, which she used as a getaway from OO programming during weeknights and weekends. She has since found herself applying the functional principles to improve her C++ and Java code in her day job. Now she can pretend she's doing functional programming with Java8, if she squints at it a bit.

Delivery Tips

  • Your main goal as a speaker is to teach the concept/idea to the audience, so that each person walks away with something that they just learned. Focus on what the attendee will get out of the talk. Watch the audience reaction (look out for nodders) and slow down and spend more time explaining if you notice confused faces.
  • Repeat your key ideas by rephrasing your point, even if it feels silly. That's how you ensure attendees learn the new material.
  • Communicate the structure to the audience. This will help them stay oriented and understand how different ideas link together.
  • If you prefer to have bulleted text, have it appear at the same time as you mention the point verbally to prevent the audience from being overwhelmed with a wall of text and start reading it while you speak.
  • Rehearse, rehearse, rehearse. Plan to spend many hours practicing just the flow, even when all the material and slides are ready. The difference between a well-prepared and excellent delivery is a few dry runs.

Structure Tips

  • Make sure to address different types of learning strategies the audience relies on: say it, show it visually, and gesture it.
  • Come up with a clear structure of the talk and stick to it. Make sure to explain why each new idea is relevant to the overall talk.
  • You won't be able to teach everything in 1 talk. Try to stick to a few main points that you'll reiterate at the end. If it's an overview talk touching on many subjects, make sure you have a few takeaway points at the end to help the audience tie it all back together.
  • Ensure your intro and conclusion material are well thought out. "What will I learn from this talk?" should be addressed at the beginning and will guide the rest of the content.
  • If you're using analogies to explain, make sure to add a slide or two to explain the analogy to "catch up" those who aren't familiar with the concept. Think through your analogies carefully to ensure they aren't overstretched which would make the content more confusing.

Mike Gehard

Twitter: @mikegehard


Mike has been writing software for 15+ years and has recently been bitten by the functional programming bug. He's on his 5th time trying to teach himself Haskell and this time it may just stick. When he's not writing writing code or coaching other developers, you can find him our riding his mountain bike, climbing or hiking around the hills of Boulder. You also might find him enjoying some of the amazing breweries that dot the landscape of Boulder and the surrounding towns.

Delivery Tips

  • Your job is to entertain your audience, they can get the information from the internet.
  • If you have a slide with a lot of information or a quote, don't read it back to your audience. Give them time to digest it and then talk to the points you are trying to make.
  • Allow folks to ask questions during the talk but reserve the right to table questions may derail your talk.
  • The audience will enjoy your talk more than you think they will so there is no need to be nervous.
  • When you are speaking, you are the expert on that specific topic. You've earned that right so act like it.

Structure Tips

  • Don't put too many words on slides. People will read them instead of listening to you speak.
  • Start by telling them what you are going to tell them, then tell them and then tell them what you told them. This will help them ask good questions later if they didn't understand something.
  • A well placed picture/diagram can help explain complex topics better than words. This allows people to form their own mental model of what is going on.
  • Include at least one take away that the audience can apply to their world the very next day.
  • Dark background with light text are easier to read than the other way around.

David Greenberg

Twitter: @dgrnbrg


David Greenberg loves learning new things. He is an independent consultant who previously worked at Two Sigma, where he led the effort to rebuild their computing infrastructure. His desire to learn has lead him to study Russian and Spanish, and he is an enthusiastic home cook. He's interested in high performance software and distributed systems. He's the author of the O'Reilly book "Building Applications on Mesos".

Delivery Tips

  • Keep the audience engaged through polls/survey questions/
  • Don't use excessive text--full screen images can offset text/
  • Practice at least 6 times, to the point you know what to say w/o looking at your notes/
  • Repeat every important point twice while presenting, and again at the end in summary/
  • Practice until your time is consistent, and leave 5-8 minutes for questions at the end (even if you have to cut content!)/

Structure Tips

  • Make a "Table of Contents" slide that highlights which section we're on, and display the ToC between each section.
  • Every slide should have a diagram or picture--you can usually better present the material with a diagram than reams of bullet points - (depending on the person) Don't spend too little or too much time styling your slides--picking a premade style and judiciously changing it can give you a unique look. Don't spend more time on beauty than content.
  • Present your talk to someone who barely knows about the material, and someone who's an expert, to get feedback on ways people might misunderstand.
  • Don't have too many points: one talk probably has space for 3 main points. As a speaker, you should focus on communicating fewer points well, rather than trying to teach everything.

Kris Nuttycombe

Twitter: @nuttycom


Kris is a software engineer based in Boulder, Colorado. He is aficionado of strongly typed functional programming languages, mostly because he's not smart enough to write working software using anything else. He likes writing Haskell in Scala, struggles with writing Haskell in Haxe, and sometimes actually writes Haskell in Haskell. His hobbies include blacksmithing, experimenting with software-mediated economies, and climbing on rocks.

Delivery Tips

  • Don't try to cover too much ground - focus on a single concept and why it matters. Nobody ever complains if talk covers its subject well and comes to a logical conclusion early.
  • Plan for a specific audience. You can't possibly cover all the prerequisites for an advanced topic, but you *can* make advanced talks compelling for unprepared users if you can elucidate why the topic matters.
  • If possible, give the talk in full to an audience (of coworkers, or your local meetup group) prior to LambdaConf. Rehearsal doesn't reveal all of the rough spots in the same way that the reaction of even a small audience can.
  • Only address the most vital caveats. There are few subjects in technology where there isn't more detail, or some exception to the rule, that will become important in serious use cases. However, by definition people are coming to your talk to be exposed to new ideas that they can use - if you succeed, they'll find out the gritty details on their own. Certainly cover things that might cause people to fail when getting started, but if they won't run across some issue in their first week, leave it for the supporting materials.
  • On that note, your supporting materials can be one of the most important parts of your talk, and the part that takes the most time. The transcript, accompanying blog post, and source code are things that many people outside the conference will use as resources, even if they don't attend and never watch the video of your talk. You may even wish to plan your talk as support for your "supplementary" material, rather than the other way around. If you truly want to get someone using a technique or a piece of technology, the talk will inspire them, but the supporting materials will enable them to succeed.

Structure Tips

  • A talk is an inherently linear form of information transmission, while knowledge acquisition is much more frequently graph-structured. As an expert, you're likely to want to explore some of that graph - avoid the temptation. It's okay to leave interesting branches out; that's what the supplementary materials are for. If in an outline you find yourself coming back to the root level, consider whether you can prune off that new branch from the root entirely - it may well be that it's not closely associated enough with the primary thing you want to be talking about.
  • Your presentation materials should have 3 parts: the slides, the accompanying blog post, and the source code as an independent compilable/runnable artifact that people can play around with. If you're talk is about something that requires effort to build a working environment for, provide a Dockerfile that someone can use to build that environment. Prefer this over (just) an image; give people source that they can hack on when they need to use your thing for their own purposes.
  • If you need to put more than 3 lines of code on a slide, you should plan nobody in the audience should need to read that code. The cognitive burden of mentally simulating an interpreter for even a few lines of code (and the attendant looking for gaps/issues, which your audience *will* do) takes too much of their attention away from the subject at hand, and any problems that you miss will be jumped on by somebody trying to prove how smart they are. If you *must* put more than 3 lines of code on a slide, one thing you can do is to fade the text of all but 3 lines - this helps the audience focus on the truly critical bits, and nobody is going to call out bugs in the faded parts.
  • At the beginning of the talk, give a link to the slides so that those who are more comfortable looking at their own screen can do so. At the end of the talk, provide the link to the blog post that the talk supports (as mentioned above).
  • Punctuate your slides. In technical talks, it's usually necessary to have code and bullet points to a greater degree than is generally recommended for many other kinds of presentations, but pauses where there's just an image on the screen and your voiceover is the focus are important, otherwise your audience will become fatigued.

Simon Belak

Twitter: @sbelak


Simon Belak is the Chief Analytics Officer at GoOpti where he is in charge of making the company data-driven; building analytics infrastructure (end goal: provide any answer stemming from data in 2 min or less); and developing a predictive real-time pricing and risk hedging engine. Before GoOpti he worked with over 20 startups and growth companies helping them become data driven and set up (or level up) their analytics departments.

Now an accomplished speaker on the tech circuit, he used to be an avid competitive debater winning multiple international tournaments and ranked top English as a foreign language speaker at Worlds Universities Debating Championship in 2008. He taught debate on primary school, high school and university level, including coaching the Slovenian national team (which went on to win the World Championship).

Delivery Tips

  • for beginner and intermediate speakers knowing the entire talk by heart is more of an impediment than help. However a great trick to smoothly get into the presentation and keep stage fright in check is to have memorized the opening 10-15s and visualise & rehearse transitions from there. Starting is the hardest and at the same time critical to get audience buy in.
  • know slides and transitions by heart. Slide transitions will inevitably draw attention and people will start reading off the new slide. If you account for that you can use it to drive a point home, if not it can lose you attention of the audience and forces you to needlessly spend time ting ends together which further detracts from the main point (the more time you spend on a topic the more it sticks as important).
  • expectations are a powerful tool. Break them once to really make a point, but only once. If you continually break expectations the audience will feel betrayed: they put in the effort, but you are just stringing them along. Once this happens, their engagement and receptiveness will also fall.
  • referring back helps with clarity and structure and gives the sense of cohesiveness. Audience participation via show of hands is another way to set an anchor you can later refer back to.
  • take it as a given that people won't be fully following the entire talk, the more help you can give them to get back in, the better. Use pacing to demarcate the important from the glue. "Structure slides" (eg. repeating the index with the current topic highlighted) are a good -- if rough -- tool as well.

Structure Tips

  • why, why, why, ... why is a good default structure. If you grab the audience's attention, they will go through follow up whys in their head. If you preempt them you won't have to fight for attention with their internal dialogue and it they will get a feeling of familiarity, that what you say meshes well together with how they think.
  • repeat important things trice: state, explain, sum up. A cheap trick is to have an explicit section "take aways" at the end. Even here have a hierarchy: start with the one thing you want your audience to take away, then the second, third ... (journalists call this structure the inverted pyramid).
  • make a persona for your typical/target audience member. Go through what they know, why they are here, what will make them happy/successful, why should they care. Use that to inform your structure, emphasises and level of detail.
  • allow for some mental breathing space. Unlike reading, talking forces the listener to your pace which might be too fast for them. Give them time to catch up, help them be sure they are understanding things right (see also: repetition).
  • despite this being a technical talk, try having a narrative arc. Start with a problem, a challenge you faced, a story or at least some principle you hold dear and use that as the key to the rest of your talk.
About Connect Events Buzz

Winter Retreat

2018, January 6th-9th | Whistler, BC, Canada

Escape the hustle of everyday coding with LambdaConf’s second Winter Retreat, held this year in Whistler, British Columbia, Canada—a beautiful mountain town nestled in the southern Pacific Ranges of the Coast Mountains!

With 12 hours of content, 12 hours of dedicated Office Hours from expert guides, a continuous unconference track, and 9 shared meals, Winter Retreat packs an incredible amount of content, mentoring, and networking into a 4 day, 3 night package.

Leisurely explore selected topics in functional programming from invited LambdaConf Guides. Pair with attendees on interesting projects. Apply what you have learned from conferences, books, and blogs. And start 2018 with fresh passion for writing software in ways better than you ever thought possible.

  • Takes place in Whistler, a beautiful mountain town. Whistler's pedestrian village has won many design awards and the town has been voted among the top destinations in North America by major ski magazines since the mid-1990s. There are numerous shops, restaurants, and cafes, and opportunities for downhill skiing, cross-country skiing, snowboarding, sledding, snowshoeing, and much more. Experience Whistler's legendary beauty and charm for yourself!
  • Easy, cheap flights and open borders. Vancouver is a direct and affordable plane flight away from most major cities in the USA and Canada and has many non-stop international routes. Canada is well-known for relatively open borders, low hassle with customs, and no travel bans, making it a perfect vacation destination.
  • Original content from hand-invited Guides. These LambdaConf Guides have been selected based on their expert teaching skills, mastery of key topics in functional programming, and popularity with attendees. You'll find helpful and very knowledgeable Guides with backgrounds in Haskell, Scala, Elm, PureScript, mathematics, and more.
  • Dedicated mentoring time with Guides. Every Guide dedicates 2 hours of Office Hours to help attendees, whether that's by teaching concepts, pairing with them on challenging code, or practicing with them to enhance key skills essential for mastery of functional programming.
  • Plenty of time for collaboration and peer-learning. Scheduled content consumes only four hours each day, allowing plenty of time for learning from Guides and fellow attendees, collaborating on interesting projects, and sharing your own knowledge with fellow attendees.
  • Includes 3 days with breakfast, lunch, and dinner. Self-pay for lodging and activities, but 9 full meals are included, which keeps costs low and provides ample opportunity for networking. If you stay at the official retreat hotel, which gets you phenomenal rates, you get to stay with most other attendees and Guides!
  • Two reserved conference rooms and several lounges. Wifi is included and projectors can be used by attendees outside hours of scheduled content. Bring some fun problems or side projects and expect to make some serious progress with help from some of the most experienced engineers working in functional programming.
  • Legendary LambdaConf swag. Expect the "cold weather" edition of LambdaConf swag, which will help you keep warn during your trip to Whistler. Hot chocolate, bookmarks, and premium zippable jackets are all included!
  • Childcare available. Don't let little ones deter you from leveling up. You'll have the option of signing up for childcare for any of the days of the retreat, either half day or full day. There are also plenty of outdoor activities and classes available for older kids (5+) and teens, including sledding, skiing, snow-boarding, and more.

Unlike Winter Retreat 2017, your Winter Retreat 2018 ticket does not including lodging. Please purchase accommodations separately. We recommend the official conference hotel (a very short walk away from the conference center), for which we have secured an excellent rate.

Note: Due to the nature of this small, intimate event, attendance is strictly capped, so if you want to attend, purchase a ticket at the earliest opportunity. As with all LambdaConf events, there are no refunds or exchanges.


Hardy Jones


Hardy is a language enthusiast, was the first professional PureScript developer, and currently writes Elm daily for NoRedInk.

Running With PureScript

2 Hours — PureScript

PureScript is well-known for its row-polymorphism. Extensible records use row-polymorphism to increase modularity. The Eff data type uses row-polymorphism to describe the effects a program can produce in more detail than the IO data type.

In this hands-on workshop, we'll explore other data types that make use of row-polymorphism in intriguing ways. We'll see how to use row-polymorphism to increase modularity in a different way from extensible records. We'll also see how to use row-polymorphism to describe effects in a more rigorous way than the Eff data type.

Office Hours

2 Hours &Mdash; PureScript, Haskell, Elm, Javascript, & Others

Hardy is open to help with pretty much any language: PureScript, Haskell, elm, JavaScript, Erlang, Prolog, Ruby, you name it, we'll work on it. If you'd prefer to discuss topics at a higher level, we can do that as well. If you're feeling lost with the many front-end libraries and languages, we can talk about options that would be useful to you.

Kris Nuttycombe

Kris is a software engineer based in Boulder, Colorado. He is aficionado of strongly typed functional programming languages, mostly because he's not smart enough to write working software using anything else. He likes writing Haskell in Scala, struggles with writing Haskell in Haxe, and sometimes actually writes Haskell in Haskell. His hobbies include blacksmithing, experimenting with software-mediated economies, and climbing on rocks.

Michael Snoyman


Michael Snoyman is the founder and lead developer of multiple Haskell open source projects, including Yesod, Conduit, Stack, and Stackage. His main interests are creating developer-friendly, high performance libraries that minimize bugs. Michael is VP of Engineering at FP Complete, where he focuses on using Haskell and modern devops to help projects make it to market faster and with fewer bugs.

Whirlwind Tour of Core Haskell Libraries

2 Hours — Haskell

Central to writing any significantly sized project in Haskell is choosing the right libraries. Data structures, network protocols, and file I/O are some tasks that most applications will run into.

In this talk, we'll cover some of the most popular libraries in Haskell, covering the majority of use cases. In the process, we'll get a better sense of how to choose a library, how to familiarize yourself with a new library, and how to structure production code bases.

Office Hours

2 Hours — Haskell & Others

Michael will be available for review and pair programming of any code you're working on, though you'd probably prefer to talk Haskell. If you've got some questions on specific topics in Haskell, such as exceptions, streaming data, or tooling, bring 'em too.

Sig Cox


Sig is an aerospace engineer, currently building a scramjet-powered smallsat launch vehicle, and a startup. Sig occasionally tries to reinvent the Internet, and did Haskell things a long time ago.

Telluric: An Arcane and Contrarian Distributed Network

30 Minutes

The Telluric network is a new distributed cryptosystem focused on fast streaming communication and broadcast messaging. Its architecture, interface paradigm, and community structure are very very different from the web.

This talk will provide a brief overview of its design, interfaces, mathematics, and philosophy.

Using Telluric

90 Minutes

After describing Telluric and taking questions, Sig will assist attendees in setting up the Telluric client, creating identities for the messaging protocol, and getting started developing applications.

  • A computer or VM running Linux, with network access
  • Some familiarity building C programs from source

Office Hours

2 Hours

After the workshop, Sig will be available to help with any further telluric questions or issues, or to talk about rocketry and financing ambitious projects.

John De Goes


John A. De Goes has been functional programming for more than seven years at multiple companies, and has assembled world-renowned Scala and PureScript engineering teams, trained new developers in Scala and PureScript, and developed several successful open source FP projects. Known for his ability to take very complex concepts and explain them simply, John has taught numerous workshops and classes, including several highly-regarded workshops on Scala and PureScript. John moonlights as an instructor for LambdaConf, but his primary job is Chief Technology Officer of SlamData, an open source software company using pure functional programming to redefine analytics for modern data.

Using Functional Programming to Rapidly Build Scalable, Concurrent, Non-Leaky Scala Services

1 Hour — Scala

Rapidly building scalable, concurrent applications that don't leak memory and threads has proven all but impossible for procedural and object-oriented programming. Scala frameworks like Akka have simplifed parts of this problem, but only by sacrificing equational reasoning, type safety, and modular composability, all of which dramatically increase development and maintenance costs.

In this presentation & workshop, you'll learn how to build applications with Scalaz 8 IO, a powerful, purely functional effect system that will help you build type-safe, concurrent, scalable, and non-leaky applications, faster and easier than ever before. By the end of the session, John hopes you'll agree that purely functional programming is the only practical, Enterprise-grade choice for the working programmer.

Making a Testing Framework Using Applicative Functors

1 Hour — PureScript, Haskell, Scala, Others

In this workshop, you'll get to follow along in Scala, PureScript, or Haskell, as John leads you on an exploration of building a testing framework DSL using applicative functors, a very powerful and under-utilized abstraction in functional programming. Bring your laptop, your wish list for a testing framework, and your very best functional thinking cap for what's sure to be an exciting and useful exercise in functional design and development.

Office Hours

2 Hours — Any Programming Language

In John's office hours, he will be happy to pair with you on projects in PureScript, Scala, Haskell, or most other programming languages, to work with you on learning concepts in functional programming, and to provide exercises to help increase your skills in specific areas related to functional programming, algebra, advanced types, distributed computation, and analytics.

Aaron Hsu

Aaron is a passionate computing artist with over a decade of experience in Scheme before he began to explore the wider application of array languages to HCI/d, parallel programming, human/computer performance, and human to human communication.

Notational Thinking with Arrays in APL/Co-dfns Workshop — Part 1

1 Hour - APL/Co-dfns

This workshop, which is split into two parts with time between them to let things simmer and gestate, is focused on helping to stretch your mental and aesthetic muscles by using a problem-driven, interactive approach that helps to guide you to think about problems in new ways, using notation, structure, and Iverson-style array programming as a focal point.

The workshop will focus on the use of APL and the Co-dfns dialect in particular to build programs that are concise, transparent, and leverage parallel hardware by construction. Come see how to merge visualization, pen-and-paper exploration, and high-performance array programming into a highly productive, parallel by default method of solving problems.

This workshop will be intense, highly interactive, and audience driven. The workshop will not require any prerequisites, but it is highly recommended that anyone wishing to get the most out of their time spend some time before the workshop getting prepared and checking out some existing materials in order to set the stage and prepare their minds.

Notational Thinking with Arrays in APL/Co-dfns Workshop — Part 2

1 Hour - APL/Co-dfns

Part 2 of the workshop.

Office Hours

2 Hours

Come and discuss anything related to the HCI of programming languages, Array Programming, and code minimization and aesthetics. Aaron would love to work with any of your existing code or problems to develop new approaches to existing solutions, or to find ways of formulating problems most efficiently in Array Programming style. He’d also love to help you get into thinking in an Array-centric style, and solving your problems through notational thought rather than abstractive scaffolding.


Aava Whistler Hotel

The official hotel of Winter Retreat 2018 is the Aava hotel in Whistler. This beautiful hotel is located close to the Whistler Conference Center, and a few minutes away from ski lifts for those planning to engage in winter sports.

Although attendees are free to book and stay at any place of their choosing, we have negotiated excellent rates at Aava, and most speakers and attendees will be staying at the hotel.

To receive the discount, call Aava and mention that you are with the "LambdaConf" group. The discounted rate is available a day before the retreat begins, so you may want to arrive a day early the Whistler mountain.


Whistler Conference Center

Attendees Quotes

  • "I do data engineering with Scala, heavily applying functional programming. I would like to learn more about theoretical CS concepts applicable in the real world to make better software."

  • "Comparing functional web frameworks across languages, building apps in a functional language, and practical functional programming."

  • "Exploration of next FP language concepts like dependent types, generic programming and proof solving."

  • "Love to talk about FP vs OOP and how OOP languages are converging on FP in some ways. Also love to touch base on microservices in FP."

  • "Haskell, FP paradigms, application development in FP languages."

  • "I'd like more in-depth Elm and other related areas. I'm interested in using Haskell for backend work as well."

  • "More understanding of functional programming concepts in general. I've been introduced via Elm and started learning Haskell."

  • "Interested in either working learning more formal methods for improving code quality or maybe hacking on LLVM stuff in Haskell."

  • "Networked servers, event sourcing, Elm, Haskell, databases, uni-directional data flow, functional architecture. I can share about event sourcing."

  • "Elm, Haskell, FP game dev, concurrency. I can share quite a bit about Elm."

  • "I've been writing Elm recently and have really enjoyed the functional paradigm. I'm hoping to learn more here as well as meet other functional programmers."

  • "Functional programming has amazed me with its efficiency and power. I have been working recently in Elm and look forward to working with other local programmers to learn more."

  • "My coworker pointed me at Elm and I'd love to learn more about functional application development. I need to learn the ropes of FP in general."

  • "I am just learning about lambdas, but I am so excited to be surrounded by people who are enamored by it!"

  • "Open source strategies. Lean, robust products."

  • "I see FP as having so much potential to improve our interactions with technology, both as a developer and in the world in general. I'd like to understand how and when to apply these techniques to improve lives, and how to spread the ideas to others. I'm particularly interested in how to evolve systems safely, from the smallest refactoring to an entire distributed system."

  • "Learn me a Haskell. And Scala Cats."

  • "Excited to learn more Elm, PureScript, or other FP greatness."

  • "I am a costumer, so I'm super interested in furthering knowledge of modeling transformations. Rigging lights within that can be programed for different things, connecting little servos to create moving parts within a costume, special effects, etc."

  • "I'm learning Haskell. I want to get comfortable with functional programming in general and specifically Haskell. Current goal is to be able to write a simple parser."

  • "I'd like to get a more fundamental understanding of Haskell and/or F#. Ideally this would be some work with web apps as well as console applications.Additionally, I'd like to enhance my understanding of functional programming so I can better apply it to my day to day work in C++ and C#."

Get Your Ticket!