by Mithi

A Few Good Tech Talks

1*xcbvc6oEUwOlWJmvhQB6SA

Jim Brikman compiled a list of must-see tech talks for every programmer, which I’ve put in my to-do list. From the top of my head, here’s a short list of my own. (Six videos and two articles)

Programming is Terrible — Lessons Learned from a Life Wasted, by Thomas Figg — EMF 2012

“Hello, my name is Tef, and I’m a really terrible programmer… I’m here to talk about mistakes I’ve made, mistakes other people have made, and how we can learn from them. But really I’m talking about the people in the industry, the practices in the industry and the code that we write…”

This funny, insightful, and sometimes snarky hour-long talk is the
talk that I don’t mind watching over and over again despite the poor lighting and video quality. So bad that you can hardly read the slides!

“The software industry is terrible, so is every other industry. Retraining won’t help you escape people.”

Nothing is Something, by Sandi Metz — RailsConf 2015

“ Being explicit about hidden ideas makes your code simpler, your apps clearer and your life better. Even very small ideas matter. Everything, even nothing, is something.”

Despite never having written a single line of code in Ruby, this is the talk that inspired me to think about the code that I write, and to watch more tech talks!

Beyond PEP 8: Best practices for beautiful intelligible code, by Raymond Hettinger — PyCon 2015

Raymond Hettinger is my favorite Python speaker. He speaks in an engaging way and gives valuable information to help coders of all skill levels be better “Pythonic” Python programmers.

PEP 8 or “Python Enhancement Proposal” is the style guide that is the recommended coding convention for writing Python code. In this talk, Raymond Hettinger talks about how to avoid some of the hazards of the PEP 8 and learn what really matters for creating beautiful intelligible code.

Working Hard to Keep It Simple, by Martin Odersky — OSCON Java 2011

From none other than the inventor of the Scala language himself, in this short 16 minute talk, Martin Odersky talks about some the core technology that was developed in Scala to deal with the parallelism challenge.

This talk made me understand why the “functional programming paradigm” is a “thing.” More importantly, he explained how the functional programming paradigm and object-oriented programming paradigm can be fused together and can actually be viewed as two sides of the same coin.

Learning Functional Programming with JavaScript, by Anjana Vakil — JSUnconf 2016

Anjana Vakil is an english teacher turned computational linguist turned software developer. About six months before she gave this talk, she knew nothing about functional programming and very little about JavaScript. Her talk is about the things she learned about functional programming. This is the best explanation of functional programming I have ever seen.

Stop Writing Classes, by Jack Diederich — PyCon2012

“I hate code and I want as little of it as possible in our product”

This talk reminds me of two things. Mark Twain’s quotable quote, “This letter is longer than usual, only because I have not had time to make it shorter” and the chapter from the Art of Linux Programming “Don’t just do something, stand there.”

Classes are great but they are also overused. This talk will describe examples of class overuse taken from real world code and how to refactor the unnecessary classes, exceptions, and modules out of them.

Cecily Carver — Things I Wish Someone Had Told Me When I Was Learning How to Code — 2013

“Someone will always tell you you’re not a real coder, HTML isn’t real coding. If you don’t use vi, you’re not really serious. Real programmers know C. Real coders don’t do Windows. Some people will never be able to learn it. You shouldn’t learn to code. You’re not a computer programmer (but I am).
Someone will always tell you you’re doing it wrong. Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments.”

Peter Norvic — Teach Yourself Programming in 10 years — Why is everyone in a rush?

“So go ahead and buy that Java/Ruby/Javascript/PHP book; you’ll probably get some use out of it. But you won’t change your life, or your real overall expertise as a programmer in 24 hours or 21 days. How about working hard to continually improve over 24 months? Well, now you’re starting to get somewhere…”