Brian Lonsdorf
Using math for better problem solving, with Brian Lonsdorf
Brian is the lead user experience engineer at Salesforce. More importantly, Brian is the first person in history to leverage highly educated stop-motion hedgehogs to make functional programming accessible to javascript developers! He is a regular speaker at conferences, an author, a podcast host, and a teacher who has a knack for making complicated content fun to learn.
Brian is the lead user experience engineer at Salesforce. More importantly, Brian is the first person in history to leverage highly educated stop-motion hedgehogs to make functional programming accessible to javascript developers! He is a regular speaker at conferences, an author, a podcast host, and a teacher who has a knack for making complicated content fun to learn.
Time Stamped Show Notes
2:13 – Brian started out as a Rails developer in the mid 2000s. Brian has no formal education in programming, and has been practising continuous-learning since he started.
3:00 – Martin Fowler, Uncle Bob, and Kent Beck’s books have been a big influence, but a pivotal book was Domain-driven Design by Eric Evans for learning about domain-modelling and programming design.
4:48 – Bad experiences in his code-base usually come down to not being diligent in modelling and getting rid of exceptions.
7:21 – Brian finds that he’s gearing more towards math to solve problems that he would previously have solved with an object-oriented approach.
7:40 – Brian believes focus is key. He tries to write test after test upfront, if he’s in a dynamic language. Similar to the a BDD/TDD style but more loose. He wants something that tells him where to pick up again when he gets distracted.
9:02 – In a typed system the compiler allows you to get back to where were you because it’ll complain when things don’t typecheck.
9:20 – Brian is a huge fan of PureScript. While Haskell is the main type language he would choose, he’s been working on a Scala project.
9:56 – Brian prefers Haskell as his main language, but thinks PureScript will soon beat it.
10:01 – Brian has a list on his textedit with to-dos for each feature. This lets him plan upfront.
11:43 – There’s room for improvement on how people can view and work with different people’s to-do lists without having to announce every little step you’re going to take.
12:42 – PureScript Halogen is exciting, but it’s difficult to use.
13:11 – The industry is moving away from tangling semantics and interpretation of programmes. Like with Redux, the UI says something happened, and it’s up to the interpreter on how to handle that.
14:05 – Purescript halogen is a strictly-typed UI framework which separates actions from interpretations of those actions. Instead of tying actions to reducers, like in Redux, anything in your code-base can be combined and fed into an interpreter.
15:15 – Instead of trying to keep up with the pace of the industry, Brian’s just slowly reading his 100 page theory books. When he first got into functional programming he was initially overwhelmed, but then realised it was all just the same maths in different clothes.
15:58 – Lambda calculus, category theory, and group theory are all really good at modelling code.
16:30 – It’s a learning path of understanding the main and general concepts that appear in the different areas of math that have put Brian on a slow, mellow, learning path with a clear end in sight.
18:28 – Learning functional programming comes down to building on ideas from abstract algebra; once you realise certain operators have their equivalents in programming then it becomes clear how mathematical properties in your code hold.
20:55 – People are often overcomplicating things with the tools they use, instead of simplifying their environments.
21:20 – Brian believes all the nuggets of wisdom developers accumulate in their careers help in decision making. He thinks it will be great if developers formalise the intuition they build up over the years. This intuition is what makes developers good programmers.
Quickfire Questions
25:02 – Best advice about programming
“Don’t just make things up”. Try find a principled solution, which will decrease exceptions in your code and keep it clean.
25:27 – Habits for writing better code
Composability
26:03 – Book
Haskell Book. He finds it to be the best functional programming book out there right now.
26:29 – Brian is working on part 2 of Professor Frisby’s Mostly Adequate Guide to Functional Programming
27:10 – Inspiring devs
Sarah Drasner’s awesome work with svg.
Rachel Nabors work with animation.
John A De Goes and his functional programming. John is driving a lot of the Pure Script frontend code. He’s also coming up with amazing technology for recursion patterns, as well as devising good practices using functional programming in the frontend.
28:20 – How to learn to code from scratch
Start with basic Lambda Calculus and Set Theory. That gives you a good foundation on things like Type Theory. And then start writing Haskell.
29:40 – Top tip to write better code
“Take a step back”. Write down what needs to happen to make the feature work from start to finish – just the overarching ideas. Then – if you’re using dynamic languages – write a test. Once the test is passed move onto the next thing. This process saves so many headaches.
30:16 – Use the same process when using a functional type language. However, instead of using the tests, use types to drive it. Use tests afterwards to lock it down.
Resources Mentioned
Contact Brian
twitter: @drboolean