Code we talk and code we walk

Talking about code is hard. I genuinely find it much harder to persuade fellow peers of my approach to a problem than to actually write it.

I'm sure there are the opposing types too - People who can talk about code much more proficiently than write it. I guess this is enough proof to declare talking about code, a different skill to actually writing it. This won't be any different to any other industry or task really, only; talking about code seems a much more essential day to day task to a software developer, than to say; a plumber talking with his/her peers about new techniques. This comes down to various things: how fast our industry moves etc...

You can be good at one skill, and maybe no so good at the other. It is important to remember that both compliment each other, and the goal is to try and not let either one dwindle.

Code reviews

It's no secret that it takes a lot of practice and discipline to become less defensive when our code is being criticised. To be fair, it also takes a good reviewer to not make an inquisition out of it.
Hopefully you are a member of a team, which never makes it personal, the code should be in the spotlight, not the coder.

A good thing you can take from code reviews is there is always another way to do something, and every solution should be considered without ego getting in the way. Again, this takes practice, as your default stance is to get defensive when your days/weeks work is being judged. Try to really understand the other persons approach, whether or not you decide to go with their solution in the end, it will make you a better programmer.

Home vs. Work

Another thing i've been thinking about recently, is the difference in the way we code at home versus our day job.
I usually find the code I write in my own time is better than the code I write for work; surely this is just my perception? It makes sense though... I can solve a problem exactly how I want to solve it, making/conforming to my own rules and conventions, without having to immediately consider other developers (presuming this isn't an open source project).

The problem is, I obviously don’t want that to be the case. I want to feel like I do the best I can regardless of whether or not this is at home or work.

How do we go about this?

Challenge conventions

Constantly. What was decided at the time to be best practice can change as the application/team evolves.

Arguments

It's no good just saying 'my way is better, because, it just is!'
You need to backup your argument to make a difference...

A good example of this would be the (age old) tabs vs. spaces argument. We had this at work recently. At the beginning of the project (years ago now) a decision was made to go with tabs throughout.
We questioned this numerous times with no argument taking hold. Until we started using Github and noticed it really doesn't play well and made for a jarring experience when reviewing code. This was the first argument (pro spaces) which would make a real difference to the way we work. Making the code look prettier in Github... Win. So we changed. Prior to this there was no compelling reason to change - At least not one that was worth the time and effort to make the switch.

I guess what I’m saying is (after that long winded story...) you should have these discussions and challenge conventions. After all, it is all about making a better product or making the team happier.

Whether you win or lose, these arguments are healthy. Provided they are backed with some reasoning (and they don't become personal).

Bring innovation

It can be all to easy to think that the things you are learning in your own time won't be fitting for your day job, that your team won't be interested.

I’m not suggesting that the things we are interested in or enjoy learning in our own time must be accepted at work. There are many reasons why your team should not employ framework X you have been learning. But these things should be raised. I’m pretty sure the company would encourage you to raise them. Companies spend huge amounts of money, planning hackathons and offering '20% time’, all in the hope their employees will bring innovation, new direction; technology and ways of thinking - Ultimately to the success of the business.