RailsConf 2014 - Keynote: Writing Software by David Heinemeier Hansson
Confreaks3 HN recommenders · 2014–2021
123K views · talk · evergreen · Uploaded 2014-05-05
David Heinemeier Hansson's RailsConf 2014 keynote argues that programming is closer to writing than to science, with clear code produced by iterating through drafts. It prioritizes clarity and craft over technical superiority.
HN points to it in discussions of programming as a creative craft and of how to write clear software.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
2:25:52The spelled-out intro to neural networks and backpropagation: building micrograd
Andrej Karpathy
49:55How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
26:53What the heck is the event loop anyway? | Philip Roberts | JSConf EU
JSConf
1:03:55🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
1:00:19How To Design A Good API and Why it Matters
Google TechTalks
10:13The Problem with Time & Timezones - Computerphile
Computerphile
6 comments from Hacker News
Many people might have already seen it, but I thought it'd make sense to mention DHH's talk at RailsConf either way. In his talk, he is coining the term "software writer", which goes one step further and motivates a style of programming which prioritizes clarity of code over alleged technical superiority. Very opinionated, but recommended nonetheless: [VIDEO]
I don't really see how this would be much more different from language to language. The being 'sick of' part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person. One of the struggles that the writer seems to have is that programming applications is not science, but he seems to think it is. DHH has a great keynote on this phenomenon: "Writing Software by David Heinemeier Hansson" [VIDEO] As mentioned in the comments of the article you will run into issues with any programming language. One of the tricks is to not hold on so tightly to 'rules'. Like (take from the article) 'break functionality into lots of small objects'. This is horrible advice if applied to all situations. You should only do this when it makes sense. I see so many programmers breaking up everything in useless classes and methods/functions/whatever just because someone wrote a blog post about doing so. This just makes complicated code look simple at a glance, but when you want to find out what the code really does you have to jump up and down through files looking at what each function does, you have to open split screens between abstract classes that have some dedicated piece of code in a class that had to exist in order to satisfy the 'break things up' rule, etc. Long story short: just relax, write code (in whatever language you like, for what
I really like this[1] talk from DHH on the subject, where he talks about the misconception of many programmers that we are doing science rather than something creative. While laced with hyperbolic statements it is at the very least thought provoking on some of the things that we do as developers. 1: [VIDEO]
> This brought me back to the time my SO tried to explain an 84 year old lady she was assisting what is it that I do for a living. The consensus was that I'm a writer. Maybe relevant talk from DHH coming to the same conclusion: [VIDEO]
Half true, I guess? I'm definitely in the camp of the CRUD developers. I do accept that I don't do lower level work (even making plugins/affecting how the framework works) in my day to day job. And it's fine. Evidently these skills are worth paying for and create value (monetary or otherwise) in the world. An interesting take on this and the wider topic of how to write software is DHH's keynote from 2014[0]. He states that he himself is more interested in the 'Information System' parts instead of the 'Computer Science' part. I think there's space for more specialized titles to differentiate these jobs/skillsets. 0: [VIDEO]
Software is read orders of magnitude more often than it is written. Therefore, the most important thing is to optimise your code for clarity. Software is an interative process. Sometimes it can take 5+ draft versions before you produce high quality code. There a good talk on this topic: Writing Software by David Heinemeier Hansson [1] If you're short on time, you can skip to the highlight here: [2] 1. [VIDEO] 2. [VIDEO]