Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
DevNation DC 2010
- 1. Tonality and Timbre Lessons for Personal Improvement from Musical Instruction Tony DevNatio Falls Church, Pitale n VA
- 2. The Basics
- 4. Code Kata, Project Euler
- 6. One Bar at a Time
- 10. Mentors & Peers
- 12. Code Analysis
- 14. Tommy Dorsey, Joseph Alessi
- 15. OSS
- 16. Try Something Different
- 17. What to Improve
- 18. Music Lessons
- 19. Design Patterns
- 20. Code Analysis
- 21. Common Facets ‣ Minimal ‣ Loose Coupling Complexity ‣ Reusability ‣ Ease of ‣ Extensibility Maintenance ‣ Portability
- 23. Always bear in mind that your own resolution to succeed is more important than any other one - Abraham Lincoln
- 24. Thanks! Tony DevNatio Falls Church, Pitale n VA
Hinweis der Redaktion
- Hi, thanks for coming to dev_nation. I’m Tony Pitale and I work here at Viget. The understanding of personal improvement in the study of music is much farther along, it would appear, than the same in our own field. I’d like to speak today about some of the methods I’ve found to be effective in my study of music, and the correlations I’ve derived to software development. Tonality and Timbre are just two of many aspects considered when attempting to improve musical skill. I believe a similar set may be identified in development to aid our goals for personal improvement. A little more about me: I began playing the Trombone in 3rd grade. After 8 years of study I was able to perform in the NJMEA All State Orchestra. Most students starting out are given a rental instrument. We start out by learning to make noise, and to refine that noise into something with a pleasurable tone. Continued study leads us to practice scales and intervals. It is only upon becoming sufficiently competent in these basic areas that we may continue on to more subjective aspects of musical performance. This, I think is similar to how many of us become developers, at a somewhat later age. The five things I want to talk about: - importance of the basics - deconstructing challenges - gathering feedback - inspiration and emulation - and finally: learning what to improve
- The MOST important part of any improvement is to always maintain a firm grasp upon the basics.
- Scales & intervals are some of the most simple, boring parts of learning a musical instrument. But, they are essential in reinforcing the basics. By practicing over and over we learn to hear pitch, the relationships between notes, we can learn to adjust and tune. We learn to breath (in the case of wind instruments) and to expand our breathing capabilities and dynamics (piano/forte), and, when done with tools such as a metronome, we improve and begin to understand tempo. All from playing something as simple as scales.
- In comparison, problem solving, math, algorithms, or syntax may be considered some of the more basic skills of a programmer. But, when it comes down to it, how many of us actually continue to practice or even review these skills? We presume that we “use it or lose it” and as long as we work with a language every day we’ll be alright. I think we, as developers, could do much, much more to maintain our basic skill-set. Three projects come to mind when talking about the basics. Ruby Koans happens to be Ruby specific, but the others are language agnostic. All of them focus on helping us to learn or maintaining abilities in your chosen language through the problems and puzzles to be solved.
- And what I mean by that is: our work is challenging. We’ve come up with agile and other methodologies for breaking down the difficult stuff to reduce the chances of making mistakes.
- In music we break down tough problems by repeatedly practicing the harder sections, adding a little more to the section, and practicing some more, rinse and repeat. This is where something like deliberate practice really takes shape as this technic can be practiced ad infinitum.
- The nearest thing I can associate to this repetitious behavior is TDD/BDD. We have the intention of doing something in a particular way, we make a concerted attempt at this behavior, and when we inevitably fail to do so we consider what we did incorrectly, we have another go at it. In music we can deconstruct the sections down to a single note or interval. One would presume we could perform a single note properly without issue, but that isn’t guaranteed. This is especially true of intervals. The same can be said in TDD, we set the bar as low as possible and constantly and continuously change the behavior until it reaches what is truly desired. My first gut reaction is that TDD/BDD are not as repetitious as musical practice. But I believe, if done properly they can be as useful. The only major difference is that, due to other constraints on our performance, it is unlikely that we will continue to repeat ourselves in testing, once a satisfactory solution has been created. Mostly because, it is very unlikely that our employer or client would be willing to have us rebuild functionality from scratch if it’s already in a working state. This is to say nothing about refactoring, but I’m not certain refactoring is about repetition.
- After the basics, and breaking things down to make them easier to tackle, the most important thing to do is to get feedback and to reduce the feedback loop as much as possible. We do this to identify problems and to prevent ourselves from forming bad habits.
- Performing in small groups: duos or quartets, for example, is a common practice amongst musicians.
- Peer review serves a similar purpose in software development, as it is important to receive feedback. Alternatively, having a guiding mentor is an option. To close this feedback loop down even farther we do pair programming. This has been very effective for information sharing and reducing the time between making a mistake and learning what that mistake was.
- As in sports, it is fairly common practice to record a performance and watch or listen to it in order to get an outside perspective of ourselves. In programming, there are a number of ways we might accomplish a similar feat.
- To augment peer review, especially for automated purposes, code analysis is a great tool. In ruby, tools such as: flay, flog, reek, roodi, saikuro, churn, and rcov are all very helpful and all serve fairly unique purposes in gathering feedback very quickly or in some cases continuously. In addition, we make use of continuous integration to guarantee that we get feedback quickly for each change we make. Not only this, but the feedback is “public” amongst the developers here which provides an opportunity to start a discussion and gather even more feedback.
- One of the fastest ways to learn is to see how others, hopefully people better than ourselves, are doing things. A common technique is to perform with and/or study those who are farther along than ourselves.
- Tommy Dorsey and Joseph Alessi are two of my favorite trombone players. I watched their performances and listened to their sound for many hours in order to seek inspiration, and something to emulate as I combined the works of other performers into my own unique sound. Working from this base we then move to improvisation and other experimentation to make it truly our own.
- In the development world, we can find inspiration in the work of others thanks in great part to open source software (and Github). It is sometimes difficult to wade through the massive pile of code available. But, I find it’s best to check out the projects you use most often. At the very least you get a better understanding of the code you’re making use of. Hopefully, you’ll find quality code with interesting style, patterns, and something to learn from.
- In music it is fairly common practice to learn to play other instruments. We hear different sounds, we use different muscles, and we think in different ways. In development, I would suggest trying a different language, or developing for a different audience. Most of us work almost exclusively on the web, while some of us have tried our hand at iPhone or Android development. But, how many of us have made a concerted effort at building desktop applications or server software? I think there is much to be learned from diversifying our skill-sets across multiple languages and platforms.
- Knowing or learning what to improve upon is very likely the hardest skill to acquire for oneself. It requires practice for its own benefit. However, before we can go about accomplishing this on our own it is best to seek help.
- At least when starting out, it is common to work with some form of instructor or mentor in order to get feedback, to prevent bad habits from forming, and most importantly: to identify the facets that need improvement. The experience an instruct has may eventually be learned, but even the greatest musicians will seek the perspective offered by others. Some of the facets we might learn in music are tonality and pitch, timbre (which is the texture of sound), tempo, dynamics and a whole lot more.
- Design patterns are fairly common in all languages. At the edges of what a language was designed to do we find the patterns of how best to accomplish those tasks which a language does not implicitly handle. We can study these patterns as part of the basics to better see the areas which need improvement. The book most people would cite is probably the Gang of Four book of design patterns.
- Again, many code analysis tools are designed to take a look at specific facets of software development. These facets are often great areas to study for improvement. Saikuro, for example, analyzes cyclomatic complexity. This describes, in simplistic terms, the number of code paths through a particular method through different control structures. This would suggest that it is valuable to keep code paths to a minimum. If we find that code we write is repeatedly high in complexity when judged by Saikuro, then this may be something to practice.
- Here are some of the common facets from programming (I’ll skip music), to give you an idea of the possibilities for improvement. Ideally, one would find they are stronger at some and weaker in other areas and given the previous slides we might know where to start looking. It’s important to note that these are aspects of what makes great software. It has been my experience that If we look at what makes a great developer we would only really find subjective business values that say very little about skills in software development. This may have value, but I’ve chosen to ignore them for this talk. All of these may be things we’ve all heard before, but it’s important that we note ignore them, just as the basics are very important.
- In the end, it all comes down to deliberate practice, but that’s a whole topic in and of itself and is left to you to investigate.
- Those who attempt deliberate practice will undoubtedly fail without the resolution to succeed. That is where the greatest achievers stand apart.