Your improvement is your responsibility

I really liked the introduction from the book Exercises for Programmers, by Brian P. Hogan:

Practice makes permanent.

A concert pianist practices many hours a day, learning music, practicing drills, and honing her skills. She practices the same piece of music over and over, learning every little detail to get it just right. Because when she performs, she wants to deliver a performance she is proud of for the people who spent their time and money to hear it.

A pro football player spends hours in the gym lifting, running, jumping, and doing drills over and over until he masters them. And then he practices the sport. He’ll study plays and watch old game videos. And, of course, he’ll play scrimmage and exhibition games to make sure he’s ready to perform during the real contest.

A practitioner of karate spends a lifetime doing kata, a series of movements that imitate a fight or battle sequence, learning how to breathe and flex the right muscles at the right time. She may do the same series of movements thousands of times, getting better and better with each repetition.

The best software developers I’ve ever met approach their craft the same way. They don’t go to work every day and practice on the employer’s dime. They invest personal time in learning new languages and perfecting techniques in others. Of course, they learn new things on the job, but because they’re getting paid, there’s an expectation that they are there to perform, not practice.

Brian P. Hogan

Pay me and teach me

Too often software developers complains that their employer should be held responsible for their formation. 

That’s so far from the truth! Your employer is paying you to perform, not to learn.

Of course, a learning-friendly environment is something desirable, but that not a strict requirement to continue learning and improve on your craft.

On interruptions and growth

Today was a tough day: one of those days when you’re trying to achieve your todo list items, but it just seems that the world is against you. Then I had an epiphany.

As many of you know, I’m a software developer. I always thought that my job was to produce lines of code, to design software systems, to review pull requests, and so on.

So I consider every day that I’m unable to write at least a line of code a wasted day.

“So what is preventing you from doing your job?” I hear you asking.

Interruptions

“Did you wrote this part of the system last year? Can you help me? I have to extend it…”
“Can you help me with this git command?”
“I just wanted your opinion…how would you solve this problem, given these constraints?”

So, today, when I was sitting at my desk for the first time at 4 pm, 8 hours later I entered the office, I was furious to see Slack notifying me yet another “Can you help me with..” message.

But then, it happened.

I realized that, despite the fact that I haven’t produced a single line of code, I enabled more than ten people to continue their work.
I helped all those stuck people to overcome a simple issue that was preventing them from keeping on working.

So, instead of being bothered, I decided to be proud. Instead of being shallow, I decided to give every person the time he needs to understand deeply what he’s asking me.

And I like to think that, as I’m growing as a person, my professional side is also changing, growing and adapting. Taking me to my next challenge.

So, the next time that someone asks you for help, think that they’re helping you grow.

Do you ask for code reviews?

Lately I find myself asking for code reviews more often. I used to think exactly as Wiegers put it:

Anyone who needs his code reviewed shouldn’t be getting paid as a software developer

But that’s not true. Code reviews improve code quality a lot! And, as a side effect, they improve also team cohesion.

So read “Who’s Your Coding Buddy?” via Coding Horror