Every experience you have as a software developer should change you in some way. And I don’t just mean growing older by virtue of time passing. Everything you do should evolve your understanding of your craft (and/or related skills) or your understanding of yourself – which ultimately achieves the same goal. I am not just talking about major milestones in your software development career like switching jobs, becoming a leader/manager or starting you own company. Every job, every project big or small, every significant interaction you have with your team mates and even every story you implement, should morph you into a developer who is slightly better, more resilient, more knowledgeable than you were before.

What this means is that you should strive to glean at least a little bit of new knowledge/experience, that will make you a better developer, from everything you’re involved with day to day. I am of course talking about significant experiences – you don’t need to be philosophical about every key stroke – fine grained, but still significant experiences are the order of the day. You will agree that if you go on a journey and get nothing out of it by the end, you’ve wasted your time. It is the same with your software development experience. If you finish a project or even finish implementing a feature and find yourself completely unchanged (i.e. your understanding hasn’t grown and you’ve learned nothing new), you’ve wasted your time.

But, I hear you say, some work is mundane, it’s cookie cutter, you can’t learn anything from it, but it still needs to be done! That is true, but it all depends on how you approach it. Ultimately you’re responsible for creating the conditions that will allow you to grow and change, you just need to be creative about how you do it.

Getting The Most Out Of Every Experience

Becoming a better developer is about more than just learning new programming languages, or the next greatest feature of your favorite framework. There are your interpersonal skills, how you interact with others. There are teamwork skills, how well you work with people. There are leadership and management skills. There are personal productivity skills and financial skills. There is domain knowledge, marketing knowledge and organizational knowledge. There is wider industry understanding and recognition. There is improving your ability to learn and pushing your limits.

What I am getting at is the fact that no matter what activity you’re involved in you need to examine it from all these perspectives, to find how it can change you and make you a better developer than you were before. Sometimes the opportunities are obvious, you’re working with great new tech or using a process you’ve never used before, you almost can’t help but absorb knowledge, you’re growing despite yourself. Other times, the work really is mundane and if you don’t examine the activity from every angle, you miss the opportunities that it provides and then you really are just doing cookie cutter work and getting nothing from it – wasting your time.

I’ll try to be more clear. Say you’re an SQL guru, there is a whole bunch of SQL that needs to be done and it looks like you’re the man for the job. On the surface – boring, you’re already awesome at this, surely there is nothing you can get out of it. But, let us look further, maybe you’ll be pairing on this task and you’re not as much of a guru when it comes to pairing or interpersonal skills. Here is a perfect opportunity for you to improve those, you just need to see it. Or maybe you are a pairing guru as well, but what if you’re pairing with a more junior developer. Perhaps it is an opportunity to teach some of what you know, improve your mentoring skills and grow someone else as a bonus. But say you’re not pairing, you can do this by yourself with your eyes closed. Why not slow down and try and dig deeper into the domain you’re working with, improve your knowledge in that area, or maybe you can simply just try to improve your typing skills, it surely can’t hurt. Here is one out of left field, you don’t want to do this boring work, why not use your negotiation skills to try and get out of it. You probably won’t be able to, but you might learn a thing or two just from trying and it will certainly exercise your tact and poise after all you don’t want to piss off your manager/lead by trying to weasel out of work :). The point is, you look at a task from a different angle and all of a sudden you’re learning and changing, you’re morphing into a better developer than you were before.

What If You’re Just Marking Time?

Sometimes you’ve been stuck doing something forever (that’s what it seems like anyway). You’ve approached it from all the angles, you just can’t squeeze anything else out of it, what do you do then? That is a good question, but it is the wrong question to be asking. If you really do believe that you simply can’t learn and grow doing what you’re doing, why are you still doing it (that’s the right question)? Is it for financial reasons (you’re getting paid a lot), if so then make sure you’re not sacrificing your long term prospects in your industry for short term financial gain. It could also be because you enjoy working with the people in your team, which is a valid reason, but once again have a look at the pros and cons, after all, you don’t ever have to leave your relationships behind if you move on. You never leave the people, you just leave the company!

If it is neither of those reasons, then why ARE you still doing it? Your cheese is gone, it is time for you to realize it. Remember, judge every experience by how much it can change you and grow your understanding of your craft; move on if you can get nothing from it. If you do, not only will you always be able to gain a lot of satisfaction from your work, but you will also morph into a more well-rounded developer and human being day-by-day (and not just year-by-year).

Image by Looking Glass

There are many factors involved when determining job satisfaction, some have more effect, some less (most will have a marginal effect). But there are three factors that stand out above all others. You have all three – you are ecstatic, you have none – you’re miserable. I call them the three pillars of job satisfaction and they are:

• money – how much you earn
• people – who you work with
• type of work – the type of work you’re doing, i.e. whether or not it is interesting to you

I am probably biasing these somewhat towards software development, but then again I am a software developer, so I hope noone is surprised :). Regardless these should be applicable to just about any type of job, role, position or industry.

Money

This is your salary, bonuses, package etc. It includes how much you earn and all the perks and bonuses that are involved. This is mostly determined by how much you think you’re worth rather than industry averages or some other kind of metric. If you are earning less than what you think you should be, you’re not satisfied. If you earn more, or just enough, you’re happy. Since your sense of how much you’re worth can easily change based on your perception of the world (you read a survey about those same industry averages and realize you’re getting jibbed), your level of satisfaction with this pillar can alter drastically almost overnight.

People

This is all about the kinds of people you work with. Are you friends with everyone at work, do you like spending time with your work mates socially as well as professionally? If you do then you’ll be satisfied with this one. You don’t have to be friends with everyone at your company, but you do have to like everyone that you closely work with. When you only marginally like the people you work with (i.e. you don’t mind them but wouldn’t hang out with them), this pillar will hover on the verge of satisfaction. When you love the people you work with then you’re on a constant buzz when you come to work and “your cup runneth over” (so to speak :)) when it comes to this pillar. Disliking even one of the people you work with closely, can significantly decrease your level of satisfaction here. The upside with this one is, the more people you really like, the more resilient you are to not getting along with someone (i.e. if you’re good mates with everyone, you don’t really mind one idiot). As a consequence this pillar is not as susceptible to sudden major shifts like the Money one is.

Type Of Work

This is all about the kind of work you do. It will differ from industry to industry, but in software development it is all about the kind of technologies you’re using, what kind of stuff you’re learning while doing your work and the kind of impact your work has on the rest of the world. If you work with outdated technology on irrelevant projects and learn nothing new while doing it you will not be happy when it comes to this pillar. If however you get to learn a lot from your work and you think that what you’re doing is significant in some way (i.e. there is some bragging power in the work you’re doing, like working for a project with name recognition or working for a good cause) you’ll be happy. This pillar is usually more prone to slow degradation rather than big shifts. The work you do will usually not change significantly in a short period of time, so if you’re happy to start with you’ll usually be happy for a while. However, as you learn all you can from the work that you do (i.e. get across all the tech) you level of satisfaction may decrease. It will also decrease slowly as the novelty of the work wears off and it becomes routine. Note that if you do consulting work you may go from wildly happy to wildly unhappy about this one almost overnight by switching projects/clients.

How You Feel

When you feel good about all the three pillars at your current place of employment you feel like this:

“I am working with awesome people, doing some really cool stuff and getting paid a craploads to boot. Could this sh*t get any better?” – you’re very happy

When you’re happy with two of the pillars only, you feel like this:

“I am working with awesome people, doing some really cool stuff, I just wish this sh*t paid a little better.” –  you’re satisfied

or

“I am working with a bunch of idiots, but at least I am doing some really cool stuff and getting paid a craploads to boot.” –  you’re satisfied

or

“I am working with awesome people, the work IS boring and irrelevant, but at least I am getting paid a craploads.” –  you’re satisfied

When you’re only happy with one of the pillars you feel like this:

“I am working with awesome people, but the work is boring and irrelevant and I wish this sh*t paid a little better.” – you’re reasonably satisfied (not too bad but could be better)

or

“I am working with a bunch of idiots, the work is boring and irrelevant but at least I am getting getting paid a craploads.” – you’re reasonably satisfied (not too bad but could be better)

or

“I am working with a bunch of idiots, I AM doing some really cool stuff, I just wish this sh*t paid a little better.“- you’re reasonably satisfied (not too bad but could be better)

When you’re not satisfied with any of the pillars you feel like this:

“I am working with a bunch of idiots, the work is boring and irrelevant and I am getting paid next to nothing. This crap is for the birds, I gotta get the hell out!” – you’re very unhappy

Lessons

It is interesting to note that when you can claim to have all three of the pillars you’ll be extremely happy at your place of employment. As soon as one of the pillars is no longer satisfied, you level of happiness takes a significant dive, but you don’t become unhappy, you still feel ok about your situation. You would expect that losing a second pillar would produce another dive in your satisfaction levels and plunge you well into unhappiness, but this is not the case. Loosing a second pillar, doesn’t matter which one, only produces a slight decrease in your level of satisfaction, I believe this is due to our (i.e. humans) natural instinct to stick with what we know.

Humans don’t really like change, so the fact that our general situation remains mostly the same largely makes up for losing a second pillar. Note that if you’re newly entering into a situation where two of the pillars don’t exist, your outlook will be completely different and you will be pretty unhappy from the start. This is once again due to the fact that we don’t like change and since you’re changing circumstances already, it tends to exacerbate the fact that two of the pillars are already lacking. The only thing that can make up for it in this case is if your previous situation was much worse (i.e. all three pillars were missing).

Unscrupulous companies will tend to exploit the fact that you can still be reasonably satisfied with only one of the three major pillars, so it is up to you to watch out for this. You need to recognize the fact that the situation you’re in is crappy and even though it still has some redeeming qualities you have a very good chance of being a lot more satisfied if you change your circumstances now.

Losing a third pillar produces another nose dive in your satisfaction levels and you go from reasonably satisfied to extremely unhappy. This is mostly due to the fact that while we don’t like change, there is only so much we are willing to put up with for the sake of comfort. When all three pillars are taken away, your situation no longer has any major redeeming qualities and while it might take you a little while to realize that moving on is the best option, you will eventually arrive at that conclusion.

And that’s my amateur psychologist analysis :), I’d love to hear what everyone else thinks about the subject. And if you’ve enjoyed reading this don’t forget to subscribe to my RSS feed, so you don’t miss more of my musings :).

Images by J.W.Photography and Tambako the Jaguar

Method arguments in Ruby are interesting because of the great flexibility in how you’re allowed to supply them to methods. Ruby method arguments can loosely be broken up into two categories, required arguments and optional arguments. However, I like to break them up into three categories (I hope it will become clear by the end of this post why I do so):

• required arguments
• arguments with default values
• optional arguments

Required Arguments

These are just your stock standard method arguments, e.g.:

def some_method(a, b)
end

To call the method above you will need to supply two arguments to the method call, e.g.:

some_method(25,"hello")

Pretty basic stuff, nothing much to see here, moving on :).

Arguments With Default Value

In Ruby you can supply a default value for an argument. This means that if a value for the argument isn’t supplied, the default value will be used instead, e.g.:

def some_method(a, b, c=25)
end

You may call the method above in one of two ways:

some_method(25,"hello")

or

some_method(25,"hello", 48)

In the first case you don’t supply a value for the third parameter, so it’s default value (i.e. 25) will be used in the method body. In  the second case you do supply a value, so it will be used in place of the default value. Therefore, arguments with default values are a type of optional argument.

Optional Arguments

If you want to decide at runtime how many – if any – arguments you will supply to a method, Ruby allows you to do so. You need to use a special notation when you define the method, e.g.:

def some_method(*p)
end

You can call the above method with any number of arguments (including none), e.g.:

some_method

or

some_method(25)

or

some_method(25,"hello", 45, 67)

All of those will work. If no arguments are supplied, then p will be an empty array, otherwise, it will be an array that contains the values of all the arguments that were passed in.

So, far it is all pretty basic stuff. The real fun begins when you need to mix and match the three types of arguments together.

Mixing And Matching The Various Types Of Arguments

What happens when you start to mix required arguments with optional arguments? Do they have to be in any specific order, and what gets assigned to what?

The easiest case is mixing a number of required arguments with the fully optional argument (i.e. the * notation), e.g.:

def some_method(a, b, *p)
end

You can call the above method with two or more values. The first two values will be assigned to arguments a and b, the rest will be assigned to p as an array, pretty simple. But, what if I wanted to do the following:

def some_method(a, b, *p, q)
end

In this case, you can call the above method with 3 or more values. When you call the above method, the required arguments get assigned first and if there are still any values left over they get assigned as an array to the optional argument, e.g.:

some_method(25,35,45,55) - a=25, b=35, p=[45], q=55

some_method(25,35,45) - a=25, b=35, p=[], q=45

some_method(25,35,45,55,65,75) - a=25, b=35, p=[45,55,65], q=75

Notice that the required arguments get assigned the value that corresponds to their order in the argument list, while the optional argument gets all the values that are left over that correspond to it’s order in the list.

Things can get even more involved if we introduce arguments with default values:

def some_method(a, b, c=5, *p, q)
end

In this case you can still call the above method with three or more values. When you make a call, all required arguments must get a value assigned, if there are more values left over, then the arguments with default values will get a value assigned to them, after that if there is still something left over, the optional argument will get those values as an array, e.g.:

some_method(25,35,45) - a=25, b=35, c=5, p=[], q=45

some_method(25,35,45,55) - a=25, b=35, c=45, p=[], q=55

some_method(25,35,45,55,65) - a=25, b=35, c=45, p=[55], q=65

some_method(25,35,45,55,65,75) - a=25, b=35, c=45, p=[55,65], q=75

Once again all arguments get assigned the values that correspond to their order in the argument list. And the arguments with a default value will get something assigned to them (if possible) before the fully optional argument gets any values.

It’s all pretty cool and it might seem like you can do anything with argument lists in Ruby, but there are some things to look out for. The only real hard and fast rule to remember is when you’re mixing optional parameters and default value parameters in the argument list. In this case, all default value parameters must occur before the optional parameter in the list, e.g.:

def some_method(a, b=5, *p) - correct

def some_method(a, *p, b=5) - incorrect!!!

If your optional parameter occurs before your default one, it is a syntax error, which makes sense if you think about it. And obviously, it makes no sense to have two optional arguments in an argument list (i.e. two parameters with * notation).

Feel free to leave a comment if you know of any other interesting things or caveats when it comes to Ruby method arguments.

Image by Anders V