Tech Book Face Off: Learn Ruby on Rails Vs. Crafting Rails 4 Applications

After the last two books on Ruby on Rails that I read, I was going to move on to filling other holes in my understanding of programming. I planned to next read either something about refactoring or test driven development or agile practices in general. But then I got an answer to my request for a more textbook-style Rails book from Daniel Kehoe. He suggested I give his Learn Ruby on Rails tutorial a try. While I don't think it addresses exactly what I was looking for, I do think it was a good book that meets the needs of novice programmers that would find tutorials like Ruby on Rails Tutorial a bit too challenging.

Full Disclosure: I received a free review copy of Learn Ruby on Rails for this review. While that is cool and flattering, I will do my best to remain impartial. I always try to be honest and fair with my reviews, thinking about who would find each book most useful and whether the books are clear, understandable, and engaging. That should remain the same in this case.

To find something to pair up with this book for beginners, I went in the other direction and picked a much more advanced Rails book with Crafting Rails 4 Applications. This book goes deep into the guts of Rails, explaining code samples directly from the source code and showing how to create plug-ins, engines, and rack applications. It should offer a stark contrast to Learn Ruby on Rails and bring out the strengths and weaknesses of both books, so let's take a look at them.

VS.

Learn Ruby on Rails

Unlike most other software development books, Learn Ruby on Rails is part of an online subscription available at railsapps.github.io. If you subscribe, you get access to two books, the other one being Rails and Bootstrap, and a number of tutorials and guides. Starter apps and an app generator called Rails Composer are also available at GitHub. I didn't look into any of this extra stuff since I already have quite a few starter apps now from the various tutorials I've gone through. If you're curious, I encourage you to check them out for yourself.

I would place Learn Ruby on Rails as easier than either of the other two tutorials I went through: Agile Web Development With Rails 4 and Ruby on Rails Tutorial. Kehoe gives the reader a very gentle introduction to Rails with this tutorial, and keeps the book as short as he can by referring to online articles for installation instructions of Rails and other necessary tools and for more in-depth explanations of various topics.

He also limits the tutorial to the controller and view sections of Rails and leaves out the use of databases entirely. For an introductory tutorial like this, I think it was the right decision. You can still make a decent Rails application without a database, and beginners can focus on understanding the view and controller side of a web application.

I had a somewhat difficult time evaluating this book as an introductory text because I had already read two books on Rails, and essentially nothing was new to me. I can't know for sure how the book would work for someone who had no previous exposure to Rails, but Kehoe certainly did a good job explaining the fundamental areas of development with Rails in a clear, direct way. He started off with an overview and introduction to web development, gave a rundown of available resources, presented agile development processes, and went through how to get up and running with Ruby, Rails, rvm, gems, and Git.

Once the environment was set up and the stage was set, he presented a series of exercises that built up a simple web application with home, about, and contact pages, a couple of forms with validation, and the capability of sending email. Nothing too fancy, but it gives the reader a firm foundation to build on.

Sometimes things were redundant, and chapters would overlap, explaining similar material. As an example, the Git commit and push commands were explained multiple times with increasing detail each time. First, Git was described in a fair amount of detail in its own chapter where it was mentioned that the command git push origin master could be shortened to git push after the first use.

Then, at the end of the next chapter the git push shortcut was brought up again in more detail. Some issues that may have come up when using the shortened command were addressed here, but would have probably been more useful when the shortcut was introduced. I'm not sure why these explanations were split into separate chapters. Maybe it's easier for beginners to pick up more advanced features if they are introduced gradually, but I thought it was a little weird.

There were two things that I really liked about this book. First, Kehoe explores the Rails framework through experimentation, which is a great learning tool. He encourages playing around with the code, and iterates through a number of ways to accomplish what's being implemented. It's incredibly valuable for programmers to get comfortable experimenting with code, learning for themselves what works and what doesn't, and gaining the confidence that the answer is there to be discovered by those that are persistent. Learn Ruby on Rails does a good job developing those skills.

Second, Kehoe forgoes the generators and scaffolding, and instead has the reader create every file from scratch. This teaching method reminded me particularly of Charles Petzold's Programming Windows series of books where he refuses to use Visual Studio's code generation features to write Windows applications. The idea is that the beginning programmer is going to learn much more by writing all the code themselves and understanding what's actually going on. Progress may be slower initially, but the foundation will be much stronger for building on later. I completely agree with that approach, and it was nice to see it in Learn Ruby on Rails.

Having Rails presented this way actually cleared up some foggy ideas and misconceptions I had about the view and controller interactions. It was very helpful, and for that alone I would recommend this book. It's fairly short and easy to work through, making it a good introductory tutorial before you move on to the more advanced ones.

Crafting Rails 4 Applications

At the other end of the learning spectrum lies Crafting Rails 4 Applications. This is a book firmly directed towards intermediate to advanced Rails developers. It assumes you have a working Rails environment and you know what to do with it. José Valim dispenses with any and all introductory material, and after a short preface, he jumps straight into the first Rails plug-in - a custom view renderer for generating PDFs from embedded Ruby templates.

Code examples note which file the code should be added to, but do not show the context around the code, so you have to know where to add it yourself. Basic hand-holding is kept to a minimum so time can be spent going through the plug-ins and Rails source code while keeping the book short. There wasn't even an explanation of how to wrap a plug-in up as a gem and use it in other Rails apps. Luckily, a Step-by-Step Guide to Building Your First Ruby Gem showed up on Hacker News while I was in the middle of this book, so the solution to that problem came right to me. Talk about serendipity.

The setup of the book worked pretty well, in spite of the lack of guidance for anything not directly related to building the plug-ins. For the target audience, this format was probably appropriate, and I actually got a kick out of overcoming some of the challenges I would run into as I was implementing each of the eight plug-ins. I probably made it harder on myself by doing everything in Windows 7, (I know, I know, but I don't have the money to get a MacBook, and I haven't had the time to set up Ubuntu) and things got especially hairy when I needed to install things like OpenSSL, MongoDB, and Redis to complete the later chapters.

I got everything working in the end, and I was even pleasantly surprised that everything I needed was actually available for Windows 7, if I was willing to dig a little. It would be nice to have something like rvm, though. That's still missing as far as I can tell.

Anyway, back to the book. These are advanced topics that Valim covers. He explains how to hook into Rails to add features and extend functionality in the rendering engine, the controllers, the HTTP responder, and the database interface. It was extremely cool to implement plug-ins that could fetch view templates from a database instead of the filesystem, send multipart emails generated from Markdown templates, stream events to clients for continuous updates to web apps, and monitor website metrics with an attached MongoDB database.

Some of this stuff is over my head at this point, but when I get deeper into Rails development, I'll know where to look to find answers to questions I have about Rails internals. Even though I didn't understand everything, going through the examples was a blast, and I learned a ton of stuff about how Rails works under the hood. If you're looking for a book to take your Rails development to the next level, Crafting Rails 4 Applications will help get you there.

The Big Picture

Now that I've read four Rails books, what would I recommend? Well, of the two books in this review, the choice is easy. If you're an absolute beginner with Rails, then Learn Ruby on Rails would be the book for you. If you already have a few Rails apps under your belt, and you want to see how flexible and extensible Rails really is, then you should take a look at Crafting Rails 4 Applications. To bridge the gap between the two, either Agile Web Development with Rails 4 or Ruby on Rails Tutorial would work perfectly, giving you a full path from beginner to advanced Ruby on Rails developer.

Of course, you'll need to actually write a few non-trivial Rails apps before you can claim to have finished this learning path, and Crafting Rails 4 Applications will make much more sense after you do. Have some fun with it, and no matter what level you're at with your Rails knowledge, one of these books will help you reach the next level.

Keeping Up

Times are changing. Faster than ever, we're told. It seems that technology is continuing its ever accelerating pace with smart phones and social media being the current thing that's eating the world. What will be next? How will we learn to adjust? How can we hope to keep up with all the change happening around us?

As a software engineer, the world seems to be moving even faster with new languages and frameworks popping up every year to add to the hundreds already available. It's hard to even think about all of the open source plugins and libraries out there, especially for the more popular platforms on Ruby (Rails), Python (Django), PHP, C#, and Java. The count must be in the millions by now. The C# .NET framework and Java class libraries alone are too huge for any single developer to even hope to know what's all in them.

The Pace of Progress

What's a developer to do? How can we claim to be experts without knowing everything there is to know about our chosen profession? Of course, this is a fool's errand. No one can possibly know everything there is to know even about a small slice of our world. If you tried, you would spend all of your time studying the next thing to come out and the next thing and the next, and there would be no time leftover to actually get anything done.

So what about the other extreme? Could you learn just enough to get by and then stick with that knowledge for the rest of your career? Pick up some PHP, HTML, and CSS, and bang out websites for the rest of your days. Or learn some C and write embedded software until you retire. There are certainly people that do that, but it seems awfully risky to me. As the technologies move forward and get replaced, you'll be more and more likely to get replaced yourself, or at least look less and less productive as other developers pass you by with more efficient knowledge and skills.

In the decade since I finished college, I've seen C# replace C++ (and many other languages) on the Windows desktop as well as challenge Java in the enterprise space. Ruby on Rails shook the web development world and lead a revolution in web frameworks for most popular languages with the latest being Node.js for JavaScript. New and interesting languages designed to run on the JVM and CLR, like Clojure and Scala, have appeared and are looking promising. Agile methods rose to stardom, were taken over by money grubbing software consultants, and now the original creators are trying to recover Agile's essence and practical applicability.

Those are only a few of the major changes that have happened in the last ten years, and the software industry is showing no signs of slowing down. Suffice it to say, letting your skills stagnate is not a good plan. There must be a happy medium between drowning in new technology and refusing to even get your feet wet. The trick is to figure out just how deep you can go so that you can swim at a smooth pace without getting exhausted.

Information Overload

Scott Berkun brought up an interesting theory about information that starts to get at what we're talking about here:

One popular theory about our universe is that there is a fixed amount of matter in it. All that changes over time is the state and position of particular atoms. ... The net information in the universe might be fixed.

...We are compulsive information hoarders. We still pretend information is scarce. It isn’t. It never was. Even if you limit it to human produced information, for the last few centuries if you could read and had a nearby library, you had several lifetimes of information available to you.

If we think about potential knowledge as a vast, effectively infinite sea of information, then we will never learn even a small part of it in our lifetimes. At first that may sound depressing, but really, it's liberating. You don't have to learn everything because it's impossible. If you try, you will most certainly fail! Once you accept that you won't ever know everything, it's much easier to see what you should learn.

Learn the stuff that matters to you and that interests you. Learn enough new stuff to keep being more productive, but also learn the right new stuff so that your newly developed skills don't become immediately obsolete. As an example, when Rails was first released in July of 2004, a lot of people thought it was hot and shiny and a great paradigm shift from how websites had previously been built. But it was changing fast. Today Rails is sitting at version 4.0.4, and it is a completely different animal than when it was released almost a decade ago.

Rails has certainly improved in any number of ways over the years, but the fact remains that if you picked it up when it was fresh, you had to learn about all of the changes that went into it to keep up. If you were actively developing websites and Rails drastically improved your productivity even in its infancy, then that may have been the right choice. If you're starting out with web development today and learning Rails, you don't have to learn all of that legacy stuff. You can pick up the current thread of development and run with it.

So there are tradeoffs to diving into a new technology. When you're on the cutting edge, there's more risk of learning stuff that won't achieve wide adoption, and the stuff you learn will be changing constantly. But if you're learning new ways of solving problems, that knowledge could benefit you even if you don't use what you learned directly, and you may still be able to put what you learn into practice to get real work done faster right now.

Filtering Out The Noise

Rails is just one example of a new technology, and when it was released it was far from certain that it would be as successful as it is. If you follow software technology, you know that new frameworks, libraries, languages, and tools are released all the time. On Hacker News alone, you're practically guaranteed to see at least one of those four things on the front page anytime you look. How do we deal with this deluge of information? There's an awful lot of noise out there.

First, know that there are many ways to do something in programming, and no single right way, just more efficient and less efficient ways. Let that sink in for a minute. There is no single right way to solve a programming problem. There is the way you would currently solve it. Then there are worse ways to solve it and there are better ways to solve it.

Programming languages in particular can show you different ways of solving the same problem. For any given language, you have to figure out how to build a solution to your problem most efficiently within the confines of that language's features. You're going to solve any given problem much differently in a functional language than you would in an object-oriented language. The problem may map more directly to one paradigm than another, and knowing more languages dramatically expands your toolset for solving these problems.

Second, be self-aware. Know your development pain points. Those are the areas of software development that constantly irritate you or that make you feel like there's a gap in your knowledge. If you ever find yourself throwing your hands in the air and yelling, "This is stupid! There has got to be a better way!" That's a pain point. Make a note of it. It could also be something more subtle, like being aware that you should really look into that new functional language or unit testing or (gasp) version control. You've heard whispers of them being kind of important, and you're curious. Add them to the list.

Finally, carve out some time to learn something from your list. Pick something easy and fun to start with, but pick something and start learning it. There are a ton of different ways to learn new software development stuff, so you need to find the best way for you. Once you've finished with one item, it may naturally lead to another so keep following the thread. Otherwise, go back and pick something else off the list. Each time it will get easier, so you can start tackling harder topics. The important thing is to be consistent about it. Set a little time aside to learn every day if you can, but at least once a week if you must.

It may feel like wasted time at first, like you're not being productive because you're not actually getting stuff done. Don't let it get to you. Even if you're spending 10%-20% of your free time learning, if you're putting what you learn into practice and making yourself 50% more productive, that's a huge win. On top of that, the time invested in learning is a constant cost, but the benefits accrue exponentially. There really is no limit to how much you can improve if you keep learning.

Learn Like a Kid

When I stop to think about all of the knowledge out there to learn, even in one narrow area of human knowledge, it is simply astonishing, and that's only the stuff I'm aware of. Within any particular area, the things you need to learn can take years to acquire and connect together to have a working understanding of the field.

Often times you need to learn a bunch of things together for any of them to make sense, and it isn't until you have a firm understanding of what they are and how they interact that you can actually start to do meaningful things with them. Programming has all kinds of things that work this way. Take functions for example. Before you can really understand how to use functions, you need to learn about call and return semantics, variables, arguments, parameters, scoping rules, and the call stack. Not only do you need to know what these words mean, but you also need to know what the things do and how they work together in the context of a program.

The whole time that you're figuring out this or that piece of the puzzle, you'll have questions about how something works that was mentioned in passing but will be covered later, or how that thing relates to this other thing, or what the thing you're learning right now will behave in that other context. Everything is being revealed in little bits and pieces, and it's hard to see how it all fits together to make the final picture.

When you're starting out learning something new, it all seems like a mass of confusion, a big pile of pieces with no obvious rhyme or reason to it. Only after working hard at the puzzle, organizing the pieces, turning them over in your mind, connecting them together, shifting them around to try them out in different places, do you start to get a sense of how it all comes together.

Usually you'll reach a point where things start to click, and the pieces start to fall into place. Progress happens faster, and the overall picture becomes more and more clear. Once you've reached this point, it's pretty much smooth sailing, but how do you get there? The first steps in learning anything new are such a slog, and if you've been out of school for a decade or more, you're probably well out of practice or don't want to learn yet another new technology to stay current.


Think back to how you learned as a kid, or how your own kids learn on a daily basis. I'm not talking about what they learn in school, either. I'm talking about the society they grow up in and the technology they're surrounded with that they have to learn how to deal with to survive. The world is constantly advancing, and kids are dropped into that rushing stream of change totally unprepared. Yet they learn enough fast enough to become the next generation’s researchers, inventors, and entrepreneurs.

We can capture that ability at any age, if we remember (or do not forget) how we did it the first time, and we can do it better with age because we already have a wealth of experience to draw from and prior knowledge to connect to. So let's think about how kids routinely learn all kinds of new things that we find hard and tend to resist as we get older.

Necessity

Let's start at the beginning with things that we all take for granted. We are born into this world knowing absolutely nothing. We immediately need to learn how to breath, and soon after that, how to drink. We learn the smell, touch, and sound of those giant beings that provide us with food, warmth, and safety. Over the next few months we develop better eyesight and start learning about the world around us. As we gain strength and motor control, we learn to sit and then crawl and then walk.

The earliest developments may be instinctual, but as babies progress they are undeniably learning. By the time they are saying their first words, they have learned to do some incredibly hard things for their age and ability, and they are not learning these things for the hell of it. They are learning because they must.

If they are to survive, they need to learn the basics and move on to the harder stuff. They don't think about it this way, of course, but they still need to learn to do the things they want to do. If they want to not feel hungry, they need to learn to eat. If they want to reach their toys, they need to learn to crawl. If they want to communicate their needs and desires with their parents, they need to learn to talk. If you can create a need to learn something new that's half as strong as these needs, then you have found a real incentive to learn, and you will most likely succeed.

Immersion

Every kid learns something at an early age that most adults find incredibly difficult. They learn a language. Within a matter of a few years they go from having no speaking ability whatsoever to speaking fluently. If they end up learning a second language later in life, most likely it will take longer and they won't learn it nearly as well. Not that there's anything inherently more difficult in learning a second language, as children who grow up bilingual show, but there is something unique about that first language that helps kids learn it especially quickly.

How can all of these kids learn something as difficult and complicated as a language, especially if it's as inconsistent as English, in such a short amount of time? Immersion. They live, eat, and breath their mother tongue from the moment they're born, so they can't help but absorb it. They're practicing twelve hours a day or more through hearing speech, trying to understand it, and speaking it every waking moment. With that amount of practice, it's no wonder they pick up their first language so rapidly.

Other things kids are immersed in every day include social behaviors and technology, and they pick those things up just as quickly, not always with our approval. It's particularly amusing to think about the types of technology that kids grow up with and learn with ease simply because they never knew things were ever any other way. Kids today are surrounded by touch screens, smart phones, and information at their fingertips. That's the world they're learning every day.

We can learn things more quickly as well by finding ways to make those things more a part of our life or allowing ourselves to be immersed in them. Do you want to learn a new programming language or framework? Join the community associated with it. Ask questions, make contributions, and listen to those with experience. Do something with the language everyday, and before long you'll have picked up more knowledge than you ever expected. Simple continuous exposure to something new goes a long way.

Play

If there's one thing that children love to do more than anything, it's playing. When they're not being made to sit in class, be well-behaved, or go to bed, they will most likely be playing with something, even if that something is only their imagination. Kids love to build, draw, play games, and pretend. It may seem like they're just having fun, but they are most certainly learning as well.

When kids build and draw, they are developing their creativity and figuring out how our physical world works. When they play games, whether that be sports and other physical games or puzzles and board games, they are learning about strategy, tactics, and what their bodies and minds are capable of. When they are playing pretend, they are working out how to interact with other people and experimenting with different ideas about life and the culture they live in.

Those are all extremely important skills to learn, and making them fun through play makes the whole experience more enjoyable and more memorable. Kids benefit greatly from play, and we would, too, if we allow ourselves to indulge in it. When you're learning, find ways to make it a game. Forget about the drudgery of studying books and documentation for a while. Take the concepts and ideas and do something fun with them. Think of a project all your own and figure out how to build it with what you're learning. You'll learn how things work better, you'll remember it better, and as an added bonus, you'll have an example to refer back to if you need it.

Experimentation

Last weekend my wife caught my son experimenting with markers...on his legs. They were nontoxic (the markers, not his legs, although I think his legs are nontoxic, too) and he wasn't vandalizing the walls or anything so she gave him a piece of paper and left it at that. He happily continued his body artwork. I'm sure he learned a great deal about the properties of skin as a medium for marker drawings.

My daughter used to love playing with rocks in the sink. She was constantly collecting interesting looking rocks, and they congregated in the bathroom where she would meticulously clean them all with an old toothbrush. She was interested in seeing how their appearance would change from getting cleaned and getting wet. Then they would return to their drab colors once they dried. She was learning about some of the physical properties of water and light.

Kids are experimenting with their physical world all the time, and believe me, they are not at all worried about messing it up. Have you ever seen a four-year-old with a scissors and a sheet of paper? I bet you haven't because those three things cannot coexist for more than ten seconds. It's an unstable configuration. Kids haven't developed the fears of failure and embarrassment that we have, so they experiment freely, trying all kinds of things that wouldn't even occur to us. Many times they stumble into surprisingly insightful discoveries.

As adults we may be a bit more careful with our experimentation, but we should not forget how extremely valuable it is and not worry so much about messing things up. Making a mess and figuring out how to clean it up can be a great learning experience. Working with something first hand, molding it, bending it, applying different things to it, finding out where it breaks, gives you powerful experiences that will last far longer than what you'll read in books.

Rejection

When kids come across something that they have never seen before, their first reaction is not generally one of disbelief, but one of amazement. It only takes them a moment to accept that this new phenomenon is possible and reject any previously held beliefs that can't explain it. That's why it's so much fun to show kids new things.

You mean I can just blow through this little loop and bubbles come out? Let me try that!

You mean you can keep throwing those balls in the air and keep it going indefinitely? Do it again, do it again!

You mean I can turn this nozzle and water will come spraying out and I can get you soaked? Lemme see that hose!

Kids discard incorrect ideas all the time, with everything they come in contact with. They learn at an early age that everything falls to the ground, but when they see some things that don't, like planes, birds, and helium balloons, they readily accept it and adjust their thinking. As they get older and learn more about physics, chemistry, and biology, they are constantly revising their ideas of how things work and what is possible.

They easily adjust to new technology because they can reject an older interface for a new one without any significant effort. Even if the old interface had been around for years, kids are so used to changing their world view that new interfaces and new technologies don't phase them at all.

On the other hand, we tend to have trouble adjusting to new technology as we get older. We hold on to what we already know and fight off new ideas that would disrupt our carefully organized thoughts. There's a lot of legacy stuff clogging up our heads that we've invested a lot of time in learning. If we can let go of the past, even if it was the way we always did it before and it served us well, we'll be able to learn new things more easily. The old experiences and the fundamental concepts are worth holding onto because they will endure in new contexts, but we should realize when the details have become irrelevant to the current state of the world and discard them.

Kids learn an incredible range and depth of stuff in a relatively short period of time. We could certainly learn a thing or two about how they do it. So the next time you're faced with learning something new and difficult, remember how you learned things as a kid. Create a compelling need, immerse yourself in it, experiment without fear, reject old world views, and for Pete's sake, have some fun with it.

And Now For Something Completely Different

 I fear the end of this statement:

Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. Anything invented after you’re thirty-five is against the natural order of things. — Douglas Adams, The Salmon of Doubt

I'm getting mighty close to the third phase where Adams claims that your mind closes off and rejects new things. I can see how it could be true, and how it could happen. By thirty-five you're probably getting settled into a career. You've gained a fair amount of experience, and your work life has become more predictable. You've learned a good number of tools and processes to do your job, and your brain is starting to feel a wee bit full.

Besides, there are so many other things pulling for your attention - a wife, kids, a house, the latest episode of Game of Thrones... There seems to be little time to learn the latest programming language or development process. What you already know is good enough, right? It's served you well up to this point, and now you should be able to coast until you get into a management position or maybe hold on long enough for retirement.

I don't want to be that guy. I will resist that future me at all costs, and there's a good way to fight that tendency of becoming complacent. Learn something completely and utterly different from what you are doing now. This does not mean that if you are a programmer you should learn some graphic design (although you should; it will help you better understand designers), or if you are a web designer you should learn how to program (although you should for the same reason).

Get aware from software. There's a much bigger world out there. You could pick up a musical instrument, learn a new sport, or practice a new art form. Study a subject that you have little exposure to, whether that be economics, history, literature, or some field of science. Find something you're interested in that you have never done before and seriously learn it.

Why? Because it will be hard. Learning something new is hard, and if you've forgotten what it's like, it will be good to remember what it feels like to have to put concerted effort into something to produce only the most basic of results. It will twist your thinking and expand your mind so that there's room for new ideas to take root. You'll come back to your day job with fresh ways of thinking and a new appreciation for what you already know.

The difficulty of learning something completely new will make learning that new language or framework that you need to know seem like a walk in the park in comparison. When learning a new tool or method for a skill that you've developed for years, you have plenty of ways to connect that new knowledge with what you already know, and it's relatively easy to expand your knowledge in familiar areas. But if it's something you've never done before in your life, it's much harder to relate it to what you already know, and you have to work much harder to get good at it.

When learning this new thing that you've decided to pursue, bring some intensity. Don't just dabble in it here or there. Devote some real time to it. If you are thinking about it everyday and putting in concentrated effort multiple times a week, you'll start to see another benefit to this exercise. After six months or so you'll begin to appreciate the depth of this new thing you're learning and how incredibly little you know about it. You'll be improving rapidly, but at the same time you'll increasingly become aware of how much more there is to know - advanced techniques, development of style, and the rich history that surrounds it.

Recognizing what you don't know is a valuable skill, and re-experiencing what it's like to be a newbie is a good way to develop that skill. We think we know so much about aspects of life that we've never really done, only observed. Economics, climate science, and teaching come readily to mind. Do you think you know what it takes to do these things? Do you think it would be easy? Try it, wholeheartedly. I encourage you. You'll likely find that it's not as simple as you thought; that it takes a lot more work and effort than you realized. You'll likely come out of the experience with a much greater appreciation for those that do it for a living and do it well.

You may even come away with a new perspective on your day job. Are there things that you do everyday that could be done differently? Better? What things don't you know about your area of expertise, and what things do you think you know that just ain't so? Learning something entirely new will help you reevaluate what you already know in a new light and notice where the gaps are.

Finally, learning new things will keep your mind supple and flexible. You'll be actively resisting that tendency to become rigid and static. I remember reading about a 100-year-old woman who was lamenting the fact that she didn't start learning the violin at sixty. If she had known she would live that long, she would have started, and she could have been playing the violin for forty years! Learn from her regrets. Forty, fifty, or sixty years old is not too old to learn something new. It may prove difficult, but that's a feature, not a bug. You'll learn more about your limits, your misconceptions, and your strengths, and through the process of personal development, you'll become better in immeasurable ways. Who doesn't want that?