Deflated Self-Evaluation

[Falk Köppe]

Hello Avdi,

while reading your text and following the group discussions I realized how little I progressed from being a beginner ruby & rails developer. 

I read a lot of books and posts, coded private and commercial applications, watched screencasts and conference talks, but the concepts and philosophical base presented, just pushed open a door to another universe I wasn't expecting. Somehow I feel a little overwhelmed with all the topics that jumped on my schedule by just reading the first 45 pages.

- applied single responsibility

- rigorous decoupling

- practical lambda usage

- class and module manipulation

- dependency injection

- and much more I have to catch up on to even name it

Even though I understand your reasoning and motivation in the given examples, I'm having a hard time imagining myself incorporating the knowledge and practices into my own code and habits. It's a little bit like watching Lionel Messi playing soccer and then trying some of his moves on the next local kick. Doing the same and being consistent will take me a lot of effort and time, but you paved the next part of my road on becoming a ruby & rails craftsman.

Thank you for taking the time to share.

[Steve Klabnik]

Hey Falk-

So, I kinda feel like you, in a different way: I just started playing
StarCraft last week. Total beginner. And it's _hard_. There are
professional players. The game is truly based on skill.

I lost my first 15-20 matches.

So I spent tons of time watching strategy videos, reading guides, etc.
There are multiple daily strategy podcasts, for example. And one thing
kept coming up if you want to get better at StarCraft (as well as
programming):

Just pick one thing to work on.

Take next week, and just say "I'm going to practice using lambdas. I
don't care if my code is coupled, the rest of it can be total crap,
but I'm gonna be a super awesome lambda user." And then focus on that.

Then, the week after, say "this week is Dependency Injection week.
Screw lambdas: I'm gonna inject _ALL THE THINGS_."

Eventually, you'll wake up one week and be waaay better. But trying to
get better at all the things at once is HARD.

-Steve

[Chris Zwickilton]

+1

This is called "deliberate practice" and is a staple of athletes and musicians, but is just now gaining wide acceptance in the coding community (think code katas).  We need to practice our craft, and as Steve highlights, this means picking a small area and working on it with critical thinking.

[Patrick Mulder]

I like that book on "deliberate practice" too (it's even more
interesting together with Malcom Gladwell's Outliers book, showing
more examples of the 10'000 hours rule in practice). From motivation
theory, this video is interesting too:
http://www.youtube.com/watch?v=ZHbxB2Q48Zo&list=PL36CDB8219D1DF744&index=26&feature=plpp_video

@programming: What somewhat works for me is, making "sandbox"
projects, that indeed live only 1-2 weeks. In Rails context, those
sandbox projects are often blog applications. In a C/C++ project, my
sandbox often only consits of some strange-looking pattern of foo,
bar, Foo, Bar, *, &, "new" combinations only to understand why a
certain syntax works, and another syntax variation is not working.

[Hugo Estrada]

I was trying to find some practice that would be functional equivalent to musicians practicing. Unfortunately programmers don't code set pieces. However, the important part of deliberate practice is being self-aware and noticing errors. Starting with the code retreat format,  via trial en error, I eventually came up with the following format.

I write a few goals on a piece of paper, and then I attempt to achieve them within 25 minutes. After the time runs out, I write down what went well and what went wrong.

So, in 25 minutes, if you set out to do something ambitious enough, you will have a list of areas that you can improve.

[Kerry Buckley]

On Mon, Apr 16, 2012 at 1:49 PM, Hugo Estrada <hugo...@gmail.com> wrote:

> Unfortunately programmers don't code set pieces.

Ah, but they do!

http://blog.objectmentor.com/articles/2009/11/21/whats-all-this-nonsense-about-katas

Kerry

[Steve Klabnik]

> I was trying to find some practice that would be functional equivalent to
> musicians practicing.

This is actually the explicit design goals of Zed Shaw's "Learn the
Hard Way" books: http://learncodethehardway.org/

[Hugo Estrada]

Thanks for the link :) I was learning lisp via "Land of Lisp" using his same type-everything approach. It is pretty pleasant and efficient.

[Aaron Cruz]

Hugo Estrada wrote:

Thanks for the link :) I was learning lisp via "Land of Lisp" using his same type-everything approach. It is pretty pleasant and efficient.

Me too! https://github.com/pferdefleisch/learning_lisp :P

[Falk Köppe]

Thanks @all,

I really appreciate the help, suggestions and links. Now it feels more like not being alone in moving forward slowly doing one step after another and being assured that it all takes its time.

Cheers

[Jorge Dias]

This is a good advice, just do it on your pet projects, when
practicing like this you end up overusing a given technique. The
problem with this is that the resulting code is a disaster. I have
some examples in a project I work where someone decided to "practice"
continuation passing style programming and the end result is one of
the nastiest, ugliest, most difficult to read pieces of code I've ever
had to maintain, simply because they used it "because they could" not
because it would be the right thing to do.

So the point is pick a pet project and practice there, then when
you're doing "real" programming you'll have the ideas and you'll know
where to use them appropriately.

Just my 2 cents

[Hugo Estrada]

Thanks for pointing this out, Jorge. Other reasons for why you would don't want to practice on work is because learning takes time, so it will slow you down and you may not do a good enough job. Back to music analogies: practice time is the time you identify your try new things and identify your shortcomings to improve; performance time is when you play as well as you can at that point in time.Same with programming.

[Zach Dennis]

On Wed, Apr 18, 2012 at 6:06 AM, Hugo Estrada <hugo...@gmail.com> wrote:
> Thanks for pointing this out, Jorge. Other reasons for why you would don't
> want to practice on work is because learning takes time, so it will slow you
> down and you may not do a good enough job. Back to music analogies: practice
> time is the time you identify your try new things and identify your
> shortcomings to improve; performance time is when you play as well as you
> can at that point in time.Same with programming.

As a wannabe guitarist... I love the music analogy!

Zach

--

--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com