How to Name Things: The Hardest Problem in Programming
Please log in to watch this conference skillscast.
Developers can get better at their craft by learning from the great writers who mastered theirs. Writing software isn’t the same as writing a novel, but there are parallels. Besides, advice from writers is better because writers have been struggling with their craft for many centuries, not just a few decades. It’s better-written as well. During this talk, you will discover great writers’ best advice for coders: Stephen King on refactoring, Anne Rice on development hardware, Hemingway on modelling with personas, and Neil Gaiman on everything.
You will explore the similarities between writing and coding, and uses writers’ advice to identify different kinds of avoidable bad naming in code. Some class, method, and variable names are so bad that they’re funny, but you’ve still seen them in production code. The second part of the session explores practical techniques for working on better naming, including renaming things. Renaming is even harder because it includes naming things plus other hard things. The final section goes back to writing. The next step after finding better names in code is to write better comments in code, which is almost as hard as naming is.
The surprising thing about naming things well in code is not that it’s hard, but how easy it is to accept bad names. This is a hard problem that’s worth working on, because although you can’t make the naming problem go away, you can learn to write much better code regardless of which technologies you use.
YOU MAY ALSO LIKE:
- How to write maintainable Scala code - Beginner (SkillsCast recorded in December 2016)
- Introduction to Docker Fundamentals (in London on 30th September - 1st October 2019)
- CloudNative London 2019 (in London on 25th - 27th September 2019)
- Converting Architectural Requirements into Code using CloudFormation (in London on 18th September 2019)
- Lightbend Scala Language - Professional (in London on 9th - 10th September 2019)
- Lightbend Scala Language - Expert (in London on 11th - 13th September 2019)
- SC London 2019 (Software Craftsmanship London) (in London on 3rd - 4th October 2019)
- Scala eXchange London 2019 (in London on 12th - 13th December 2019)
- London Java Community August Meetup (in London on 28th August 2019)
- London Java Community August (in London on 28th August 2019)
- The Last Frontier and Beyond (SkillsCast recorded in August 2019)
- Why API Design Matters, and Why Yours Sucks! (and mine sucks too!) (SkillsCast recorded in June 2019)
Thanks to our sponsors
How to Name Things: The Hardest Problem in Programming
Peter Hilton
Peter Hilton is a software developer, writer, speaker, trainer, and amateur musician. His professional interests are business process management, web application development, functional design, agile software development and documentation. Peter currently consults for Signavio in Berlin, remotely from Rotterdam where he has lived since January 2000. Peter regularly presents at developer conferences and provides the occasional training course.
Please log in to watch this conference skillscast.
Developers can get better at their craft by learning from the great writers who mastered theirs. Writing software isn’t the same as writing a novel, but there are parallels. Besides, advice from writers is better because writers have been struggling with their craft for many centuries, not just a few decades. It’s better-written as well. During this talk, you will discover great writers’ best advice for coders: Stephen King on refactoring, Anne Rice on development hardware, Hemingway on modelling with personas, and Neil Gaiman on everything.
You will explore the similarities between writing and coding, and uses writers’ advice to identify different kinds of avoidable bad naming in code. Some class, method, and variable names are so bad that they’re funny, but you’ve still seen them in production code. The second part of the session explores practical techniques for working on better naming, including renaming things. Renaming is even harder because it includes naming things plus other hard things. The final section goes back to writing. The next step after finding better names in code is to write better comments in code, which is almost as hard as naming is.
The surprising thing about naming things well in code is not that it’s hard, but how easy it is to accept bad names. This is a hard problem that’s worth working on, because although you can’t make the naming problem go away, you can learn to write much better code regardless of which technologies you use.
YOU MAY ALSO LIKE:
- How to write maintainable Scala code - Beginner (SkillsCast recorded in December 2016)
- Introduction to Docker Fundamentals (in London on 30th September - 1st October 2019)
- CloudNative London 2019 (in London on 25th - 27th September 2019)
- Converting Architectural Requirements into Code using CloudFormation (in London on 18th September 2019)
- Lightbend Scala Language - Professional (in London on 9th - 10th September 2019)
- Lightbend Scala Language - Expert (in London on 11th - 13th September 2019)
- SC London 2019 (Software Craftsmanship London) (in London on 3rd - 4th October 2019)
- Scala eXchange London 2019 (in London on 12th - 13th December 2019)
- London Java Community August Meetup (in London on 28th August 2019)
- London Java Community August (in London on 28th August 2019)
- The Last Frontier and Beyond (SkillsCast recorded in August 2019)
- Why API Design Matters, and Why Yours Sucks! (and mine sucks too!) (SkillsCast recorded in June 2019)
Thanks to our sponsors
How to Name Things: The Hardest Problem in Programming
Peter Hilton
Peter Hilton is a software developer, writer, speaker, trainer, and amateur musician. His professional interests are business process management, web application development, functional design, agile software development and documentation. Peter currently consults for Signavio in Berlin, remotely from Rotterdam where he has lived since January 2000. Peter regularly presents at developer conferences and provides the occasional training course.