It seems that in this industry we’re operating under the false assumption that once we learn (or hear about) a skill, it is with us for good. You only have to look at a typical developer’s resume for an example – it is truly buzzword central. I mean c’mon, just what exactly do you remember about XQuery or iBATIS at this point? I sometimes look at some of my own resumes I have used in the past and can’t help being impressed – if only I were really that awesome :). If you’re honest with yourself you can quickly classify all those skills into 3 categories:

1. Stuff you have used recently and know pretty well
2. Stuff you used to know pretty well, but haven’t used for ages
3. Stuff you’ve had some exposure to, but don’t really remember much about

Only the skills and tech that end up in the first group truly deserve a place in that buzzword list. The problem is that we don’t tend to prune skills/tech off our resumes all that often. More stuff makes us sound more impressive – who wants to mess with that. This would actually have been ok if we made a conscious decision to include neglected and forgotten skills for marketing purposes, but the sad thing is the vast majority of developers/people truly believe that all those skills deserve a place.

The Power Of The Mind

When we want something to be true, we’re really good at convincing ourselves that it actually is. Companies do it all the time, they want to be the market leader so they portray/see themselves as the market leader – the reality of the situation doesn’t matter. The same is true for individuals. We have some minor exposure to a skill and we convince ourselves that we’re better than a total novice. This may be true initially, but without some reinforcement, this quickly ceases to be the case. That however is irrelevant, we already believe we have some level of expertise and so the buzzword list grows. What’s even more interesting are the tricks our mind plays on us when it comes to skills we actually did have some expertise in. You vividly remember when C, Smalltalk or XSLT was your bread and butter, it seems like only yesterday. But, it wasn’t yesterday, it was years ago, sometimes many years – you would be surprised how far those skills can degrade with time. On some level we’re aware of this, after all we’re not stupid, but we tell ourselves that it doesn’t matter, we’re just a little rusty, we can pick it all up again in no time – after all, it’s just like riding a bike. Well, let me tell you something about riding bikes.

Just Like Riding A Bike

I learned to ride a bike when I was very young and spent quite a large proportion of my childhood on one. It was simply the thing that we did during summer. I was pretty good (even if I do say so myself :)), that’s what constant practice will do for you. Then, my family moved to Australia and I didn’t ride for many years, until, during one fateful school camp, mountain biking was on the list of activities we had to participate in. I fully expected to ace that activity, my riding memories were still vivid in my mind. The reality was I sucked rather badly. Oh, I could ride of course, you never forget the absolute basics, but that was the only thing I really felt confident about. I could no longer judge properly how fast I could take the corners without falling over. I couldn’t tell how fast I could safely go downhill, so I took it easy. Riding in a pack with other people seemed scary and unnatural and after only a short while my legs were aching and I was out of breath. Sure, the basics remained, but all the skills, which are built through continued practice and reinforcement, were no longer there. I was essentially reduced to a rank novice.

The Harsh Truth

Every skill is the same, without continued usage and practice they quickly begin to degrade. Your mind begins to page-out the knowledge and experience to make room for other information. Some goes into “long term storage”, some is lost completely, but the net result is you degrade towards ‘noobhood’. The longer you leave a skill untouched, the more you mind will page-out. It takes longer for skills you were more familiar with and some knowledge is reinforced in other ways so that you never really loose it; but the hard-earned expertise, the things that make you more than just mediocre can disappear with surprising speed. This is both sad and dangerous. It is sad because in software, we devote inordinate amounts of time and effort to acquire and master the skills we use in our work. When the pace of our industry forces us into using wholly different sets of skills/technologies all that time and effort begins to go to waste. Previously useful skills get relegated into disuse and only see the light of day in the resume buzzword section. This is especially sad considering that the “useless” old-school skills are often not quite so useless after all. Ruby is all the rage these days, but to make things go fast, what are all the native extensions written in – C, so what’s old-school anymore? It is dangerous, because we absolutely refuse to acknowledge that we may not be as expert in some skills as we used to be. Sure we might loudly proclaim how we have forgotten everything about skill/technology X, but deep down we still believe that we can give these kids a run for their money when it comes to X (I am not precisely sure which kids and what money, but you get the picture :)). This is why we proudly retain X in the buzzword section, but if someone really needed that expertise in a hurry (like your employer for example), would you be able to deliver? I am certain you’ll be able to get it eventually, but so could any other reasonably competent person, there is a difference between that and expert knowledge.

So What Are We Gonna Do About It

We can simply be scrupulously honest and remove all the skills and tech we’re not sure about from the resume. But that actually helps noone, despite what I said above, you with your “rusty” skills, are still better than a complete beginner when it comes to those areas. So, by removing that stuff from your resume you’re actually underselling yourself – it is wasteful and an easy way out. Rather than doing that, why not make sure your hard-earned skills and knowledge never get quite as rusty again.

As developers, we tend to do a lot of practice and self-study anyway, but most of us do it in a very diffuse and unfocused fashion. We learn about the latest and greatest things that strike our fancy and we practice by building stuff that catches our interest. All of that is fine as far as it goes, but we can do a lot better. Here is what I suggest. Engage a in a little self-examination by taking all your skills and sorting them into four buckets:

• Core skills – these are the skills you consider primary to the direction you want your career to go. You want to make sure you become increasingly proficient with these and so should devote the most time to practicing them. There will only be a few of these at most (there is only so much time in a day).
• Supporting skills – these skills support and underpin your core skills. You want to practice these to a lesser extent than the core skills, but you still want to see slow and steady growth. If chosen correctly many of your supporting skills will get a work-out as you practice your core skills, but you should still make sure you devote some time to them exclusively.
• Peripheral skills – these are the skills that you consider valuable and worth maintaining. You’re not looking to grow these skills, but you don’t really want to lose them either. You want to devote enough time to these so that they don’t fall into disuse.
• Misc – this is the bucket for “the rest”. The truth is you can’t be an expert in everything, so this should contain the skills that you believe will add the least value to your development going forward.

You essentially end up devoting you practice and study time to your core, supporting and peripheral skills on a rotating basis, dividing your time between all of them based on their importance. It is difficult to sort your skills in this fashion (and even to work out what constitutes a skill, is building web apps a skill, or should it be specified into building Rails apps or alternatively generalised into being an HTTP protocol expert), so it might be useful to get some help, but it is an exercise that is eminently worth going through. What it gives you is a set of goals and a strategic framework for where you want to take your skills and your career. Rather than being slave to the latest trends when it comes to your practice, it will allow you to have some focus which can only make your self-study that much more productive (you’ll be able to ignore the fads because you know what you need to focus on and work towards). The side benefit of this is that after a while, you will be a lot more confident about the buzzword section of you resume and be able to prune it without making it look sparse.

So, which skills should be your core and which should be supporting? This will be different for everyone, I’ve already told you what I think about fundamentals, so that is something to go on, but ultimately it is up to you to work out what knowledge and skills you want to devote the most time to depending on where you want to take your career. It is perhaps worth exploring this in a lot more detail (it is fine to have a strategic view, but it doesn’t actually tell you what to do :)) and I might do this in a later post. Of course the other side of the coin is this, even if you do work out what skills you want to focus on, how do you actually go about practicing them, do you just write a lot of code? What if some of the skills I value are not coding related? That aspect of it is what I would call the tactical view of your growth as a developer – here it is all about deliberate practice and that is something I will definitely explore further in subsequent posts. Stay tuned.

Images by ItzaFineDay and Pete Prodoehl

1. Real elite programmers can’t have distractions like kids and spouses in their life. Cut your family out of your life to maximize coding time. While you’re there cut your friends out as well to maximize coding time even more.
2. Real elite programmers don’t have hobbies that aren’t coding. If you still engage in activities that don’t involve a computer, this will have to change. If you find yourself burning out, just man-up and push through it.
3. Real elite programmers do their best work at night. Sleep is for wussies.
4. Real elite programmers hate their day job. Otherwise they would have nothing to complain about to other real elite programmers.
5. Real elite programmers eat pizza and drink Dr. Pepper. No other food is allowed, if you have fruit and vegetables in the house, they will have to go – stick to the diet of champions.
6. Real elite programmers don’t read about programming, they DO the programming. Don’t bother with books, just keep programming. Remember, you know best, those book-writing wimps are just a bunch of noobs, they should have been coding instead of writing, you’re way better than that.
7. Real elite programmers are always right. This makes sense since everyone else is just a stupid noob.
8. Real elite programmers already know everything that is worth knowing. All the other knowledge is useless and only noobs would be interested in it.
9. Real elite programmers do not acknowledge anyone who is not a real elite programmer.
10. Real elite programmers know when to say “RTFM” in response to a question. This is a good answer to any question – noobs should know better than to ask stupid questions in the first place.
11. Real elite programmers are on social media. This is allowed, since it involves a computer. It is infact their duty since there are so many people on social media who need to be corrected about all things programming.
12. Real elite programmers complain loudly about the lack of in-depth programming content on social media. They are however too elite to provide this content.
13. Real elite programmers know when to say “TL;DR” in response to any in-depth programming content on social media.
14. Real elite programmers are particularly offended by minor inconsistencies in grammar, punctuation, colour schemes as well as any other subjective stylistic choices.
15. Real elite programmers never create any code for others to use. They have already told everyone they are awesome; there is no need to prove it.
16. Real elite programmers know how to put argumentative noobs in their place. Stupid noobs must be told they are stupid and ugly if they have the audacity to question elite wisdom.
17. Real elite programmers condescend to anyone who is not interested in whatever the real elite programmer is currently interested in.
18. Real elite programmers particularly despise non-programmers, they are worse than stupid noobs.
19. Real elite programmers use the most complicated and roundabout techniques to explain simple concepts. All must know how smart the real elite programmer is.

I do hope you realise I am being facetious here. However, there is a grain of truth in every joke. I have seen instances of this type of behaviour and have been guilty of engaging in some of it myself from time to time – you probably have as well. Just something to watch out for.

Image by Amarand Agasi

As you know, I am a big believer in knowing the basics. I find it is especially valuable to go back to the fundamentals of whatever skill you’re trying to master periodically, as you gain more experience. Somehow you’re always able to extract something valuable from the experience due to the extra insight you’ve acquired along the way. Recently I’ve been looking more closely at some Ruby concepts that I may have glossed over when I was learning the language initially, so I will likely be writing about this in some of my upcoming posts. I thought I would begin with one of the most powerful features of Ruby – procs (and lambdas :)).

What’s So Good About Procs?

You know how everything in Ruby is an object, well, as it turns out that’s not quite true. Ruby blocks are not objects! We can discuss the implications of that, but let’s refrain, accept it as fact and move on. So, blocks are not objects, but you can turn them into objects without too much trouble. We do this by wrapping our block in an instance of the Proc class (more on this shortly). This is really great since it turns our block into a first class function, which in turn allows Ruby to support closures and once a language has closures, you can do all sorts of interesting things like making use of various functional concepts. That however is a story for another time, before we dive deep into those areas, let us really understand how Procs work.

Procs And Lambdas In Detail

There are three ways to create a Proc object in Ruby. Well, actually there are four ways, but the last one is implicit. Here they are:

1. Using Proc.new. This is the standard way to create any object, you simply need to pass in a block and you will get back a Proc object which will run the code in the block when you invoke its call method. ruby proc_object = Proc.new {puts "I am a proc object"} proc_object.call

   alan@alan-ubuntu-vm:~/tmp$ ruby a.rb
   I am a proc object

2. Using the proc method in the Kernel module. Being in the Kernel module, this method is globally available. It is basically equivalent to Proc.new in Ruby 1.9, but not in Ruby 1.8. In Ruby 1.8 the proc method is equivalent to lambda. As you may have guessed there is a difference between procs and lambdas (see below), so you need to be aware of whether you’re using Ruby 1.8 or 1.9. If you’re using 1.9 there is a way to find out if you’re dealing with a proc or a lambda. The Proc object lambda? method: ruby proc_object = proc {puts "Hello from inside the proc"} proc_object.call puts "Is proc_object a lambda - #{proc_object.lambda?}"

   alan@alan-ubuntu-vm:~/tmp$ rvm use 1.9.1
   Using ruby 1.9.1 p378
   alan@alan-ubuntu-vm:~/tmp$ ruby a.rb
   Hello from inside the proc
   Is proc_object a lambda - false

   If you’re in 1.8 this method will not exist at all. By the way, did you notice how I had to switch Rubies and was able to do so painlessly through the awesome power of RVM, hope you’re already using it. As far as I am concerned, if you need to switch between different versions of Ruby, don’t bother with the proc method, just use Proc.new and you will never have an issue.

• Using the Kernel lambda method. Once again, this is globally available being in the Kernel module, using this method will create a Proc object, but it will be a lambda as opposed to a proc (if you really need to know what the differences are at this point you can skip to the explanation :)). ruby proc_object = lambda {puts "Hello from inside the proc"} proc_object.call puts "Is proc_object a lambda - #{proc_object.lambda?}"

  alan@alan-ubuntu-vm:~/tmp$ ruby a.rb
  Hello from inside the proc
  Is proc_object a lambda - true

• The implicit way. When you write a method which will accept a block, there are two ways you can go about it. The first is to simply use the yield keyword inside your method. If there is a yield in a method, but there is no block you will get an error.  ```ruby def my_method puts “hello method” yield end

my_method {puts “hello block”} my_method```

1

    <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

hello method hello block hello method a.rb:7:in my_method': no block given (yield) (LocalJumpError) from a.rb:11:in<main>'

1
2
3

    The other way is to use a special parameter in your method parameter list. This special parameter can have the same name but you will need to precede it with an ampersand. The block you pass into this method will then be associated with this parameter, you will infact no longer have a block – it will be a Proc object. You will simply need to call the Proc _call_ method to execute the code in the block you passed in. The difference is, you can now return your block (_or rather the Proc object_) as the return value of the method, thereby getting your hands on a Proc object without having to use any of the above three methods explicitly.

    ```ruby

def my_method(&my_block) puts “hello method” my_block.call my_block end

block_var = my_method {puts “hello block”} block_var.call```

1

    <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

hello method hello block hello block

1
2
3
4
5
6
7

Those are all the different ways to get a Proc object in Ruby (_either a proc or a lambda_).

> ### Fun And Interesting Trivia About Procs And Lambdas
> 
> If you have a method to which you pass a block, but instead of calling _yield_, you call _Proc.new_ without giving it a block of its own, it will return a proc that represents the block you passed in to the method e.g.:
> 
> ```ruby

def some_method Proc.new end

my_proc = some_method{puts “I am a happy proc”} my_proc.call > > <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb I am a happy proc</pre> > > **In Ruby 1.9, there is actually another way to create lambdas**. It isn't really a different way, it is simply some syntactic sugar, but it is crazy looking, so worth knowing :). The normal way to create a lambda is using the _lambda_ keyword, and if you want your lambda to take parameters, you simply pass them in the normal block way e.g.: > >ruby normal_lambda = lambda {|param1, param2| puts “param1: #{param1} and param2: #{param2}“} normal_lambda.call(10, 20) > > <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb param1: 10 and param2: 20</pre> > > With the new syntax it is slightly different. We replace the lambda method with the **->** method (_as in minus followed by greater than sign_). The <a href="http://www.skorks.com/2009/08/method-arguments-in-ruby/" target="_blank">parameters</a> move out of the block, and move into some brackets right after the **->** method (_so they look like method parameters, but in reality are still block parameters_). Everything else is the same, so our previous example would look like: > >ruby normal_lambda = ->(param1, param2) {puts “param1: #{param1} and param2: #{param2}“} normal_lambda.call(10, 20)``` > >

alan@alan-ubuntu-vm:~/tmp$ ruby a.rb
param1: 10 and param2: 20

1
2
3
4
5
6
7
8
9

## Procs Are First Class (Functions That Is)

<p style="text-align: center;">
  <img align="middle" alt="First class" class="aligncenter size-full wp-image-1832" src="http://www.skorks.com/wp-content/uploads/2010/05/first_class.jpg" style="width: 322px; height: 214px;" title="First class" srcset="https://www.skorks.com/wp-content/uploads/2010/05/first_class.jpg 500w, https://www.skorks.com/wp-content/uploads/2010/05/first_class-300x199.jpg 300w" sizes="(max-width: 500px) 100vw, 500px" />
</p>

Once we have created our first class function (_in Proc form_), there are a few things we may want to do with it, such as calling it or comparing it to another Proc. As usual, Ruby makes all of this interesting. Let's look at Proc equality first. You can compare procs or lambdas to each other, using the == method (_just like with any other object_). Unlike many other objects though, defining exactly the same proc twice will not make them equal. For example:

```ruby

string1 = “blah” string2 = “blah”

puts “#{string1 == string2}”

proc1 = Proc.new{“blah”} proc2 = Proc.new{“blah”}

puts “#{proc1 == proc2}”```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

String are equal? - true Procs are equal? - false

1
2
3

There are only two ways that two procs or lambdas will be equal to each other. One way is to define two really simple procs that have the same object in them e.g.:

```ruby

proc1 = Proc.new{string1} proc2 = Proc.new{string1}

puts “Procs are equal? - #{proc1 == proc2}”```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

Procs are equal? - true

1
2
3

This is not really very useful. The other way that two procs will ever be equal is if they are clones of each other (_one was created by using the clone or dup method on the other_).

```ruby

proc1 = Proc.new{|x|“blah1”*x} proc2 = proc1.dup

puts “Procs are equal? - #{proc1 == proc2}”```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

Procs are equal? - true

1
2
3

Let us now look at executing procs. We have already seen the call method; this is the most common way to execute a proc or lambda.

```ruby

puts Proc.new{|x|“blah1”*x}.call(2)```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

blah1blah1

1
2
3

But, there are actually two other ways. The first is to use the array syntax, this works in both Ruby 1.8 and 1.9:

```ruby

puts Proc.new{|x|“blah1”*x}(#difference)```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

blah1blah1

1
2
3

The other is the dot syntax, which only works in 1.9.

```ruby

puts Proc.new{|x|“blah1”*x}.(2)```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

blah1blah1

1
2
3

This syntax being 1.9 only will once again cause Netbeans to barf all over itself :). Both of those ways are nice and succinct, but **I still recommend you use _call_; it is not that much longer and is much more readable, both for yourself and for others**. The array syntax could be especially confusing, consider:

```ruby

some_var[2,3]```

1
2
3
4
5
6
7

That could refer to an array, a string, a proc – without context it's a bit too ambiguous for my tastes, stick to _call_.

> ### Even More Trivia About Procs And Lambdas
> 
> You may not know this, but procs and lambdas have an _arity_ method which allows you to find out how many arguments a Proc objects expects to receive (_<a href="http://ruby-doc.org/core/classes/Method.html" target="_blank">Method</a> objects also have this method_). For example:
> 
> ```ruby

my_proc = Proc.new{|x|“blah1”*x} puts “I need #{my_proc.arity} arguments” > > <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb I need 1 arguments</pre> > > Pretty simple &#8211; the fun bit starts when the block you use to create the proc expects an arbitrary number of arguments (_or requires some, but sponges up the rest using a * prefixed final parameter_) e.g.: > >ruby my_proc = Proc.new{|x, *rest|“blah1 #{x} - #{rest}”} puts “I need #{my_proc.arity} arguments” > > <pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb I need -2 arguments</pre> > > What the hell? **When you get a negative number for you arity, it means there is potentially an arbitrary number of arguments involved**. In this case, all you can do is find out how many arguments are required (_the rest will be optional_). You do this by using the **~** operator on the return value of the arity method: > >ruby my_proc = Proc.new{|x, *rest|“blah1 #{x} - #{rest}”} puts “I actually require #{~my_proc.arity} arguments, the rest are optional”``` > >

alan@alan-ubuntu-vm:~/tmp$ ruby a.rb
I actually require 1 arguments, the rest are optional

1
2
3
4
5
6
7

<a name="difference"></a>

## So What IS The Difference Between Procs And Lambdas?

It took a while, but we finally got here. Long story short, **the real difference between procs and lambdas has everything to do with control flow keywords**. I am talking about return, raise, break, redo, retry etc. &#8211; those control words. Let's say you have a return statement in a proc. When you call your proc, it will not only dump you out of it, but will also return from the enclosing method e.g.:

```ruby

def my_method puts “before proc” my_proc = Proc.new do puts “inside proc” return end my_proc.call puts “after proc” end

my_method```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

before proc inside proc

1
2
3

The final _puts_ in the method, was never executed, since when we called our proc, the return within it dumped us out of the method. If, however, we convert our proc to a lambda, we get the following:

```ruby

def my_method puts “before proc” my_proc = lambda do puts “inside proc” return end my_proc.call puts “after proc” end

my_method```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

before proc inside proc after proc

1
2
3

The return within the lambda only dumps us out of the lambda itself and the enclosing method continues executing. The way control flow keywords are treated within procs and lambdas is the main difference between them. Or rather, the way that the _return_ keyword and the _break_ keyword are treated is the difference since most of the others are treated in exactly the same way in both procs and lambdas. Let's have a look at _break_. If you have a break keyword within a lambda it is treated just like a return:

```ruby

def my_method puts “before proc” my_proc = lambda do puts “inside proc” break end my_proc.call puts “after proc” end

my_method```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

before proc inside proc after proc

1
2
3

However, if we change the lambda to a proc:

```ruby

def my_method puts “before proc” my_proc = proc do puts “inside proc” break end my_proc.call puts “after proc” end

my_method```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

before proc inside proc a.rb:64:in block in my_method': break from proc-closure (LocalJumpError) from a.rb:66:incall' from a.rb:66:in my_method' from a.rb:70:in<main>'

1
2
3

We get a LocalJumpError, what happened? Well, the break keyword is used to break out of iteration, and we didn't have an iterator around our proc, so we couldn't break out of anything, so Ruby tries to punish us with an error. If we put an iterator around our proc, everything would be fine:

```ruby

def my_method puts “before proc” my_proc = proc do puts “inside proc” break end [1,2,3].each {my_proc.call} puts “after proc” end

my_method```

1

<pre>alan@alan-ubuntu-vm:~/tmp$ ruby a.rb

before proc inside proc after proc

1
2
3
4
5

So, how come the lambda didn't have the same error, we didn't have an iterator there either. Well, this is the other difference between procs and lambdas. Having a _break_ keyword within a lambda will cause us to break out of the lambda itself, but within a proc we get an error if there is no iterator around the proc and we break out of the iterator if we do have one.

There you go, the difference between Ruby procs and lambdas. There are other control flow keywords (_next, redo, retry, raise_), but they behave the same in both procs and lambdas, that behaviour, however, is quite interesting, I urge you to have a play with it. More interesting Ruby fundamentals soon.

<span style="font-size: 10px; font-family: trebuchet ms;">Images by <a href="http://www.flickr.com/photos/rofi/2097239111/" target="_blank">rofi</a> and <a href="http://www.flickr.com/photos/richardmoross/2211308689/" target="_blank">Richard Moross</a></span>