How to be a great software developer

from:  http://peternixey.com/post/83510597580/how-to-be-a-great-software-developer

"Your value as a developer is measured not in the height of your peaks, but the area under your line" http://t.co/6JMyGvGuzl

Name your functions and variables well (write Ronseal Code)

Consider the function:

123	def process_text string … end

view raw process_text hosted with ❤ by  GitHub

It tells someone almost nothing abo

ut what it’s going to do or how it’s been implemented in the code. However:

123	def safe_convert_to_html string ... end

view raw safe_convert_to_html hosted with ❤ by  GitHub

tells someone exactly what’s going to happen. It’s also a good indicator as to what’s not going to happen. It tells you both what you can expect the method to do but also how far you can overload that method.

Function names create contracts between functions and the code that calls them. Good naming defines good architecturehttp://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey)  April 22, 2014

A good function promises what it will deliver and then delivers it. Good function and variable naming makes code more readable and tightens the thousands of contracts which criss-cross your codebase. Sloppy naming means sloppy contracts, bugs, and even sloppier contracts built on top of them.

It’s not just functions that you can leverage to describe your code. Your variable names should also be strong. Sometimes it can even be worth creating a variable simply in order document the logic itself.

Consider the line:

1234	if (u2.made < 10.minutes.ago) && !u2.tkn && (u2.made == u2.l_edit) ...

view raw garbled if statement hosted with ❤ by  GitHub

It’s pretty hard to figure out what the hell is happening there and even once you have done so, it’s not 100% clear what the original author was trying to achieve with it. The variable names are horrible and tell you nothing.

The “and not” statement is always confusing to read (please never write “and not” clauses which end with a noun) and if your job was to refactor this code you’d have to do some acrobatics to guess exactly what the original intent was.

However, if we change the variables names into something more meaningful then things immediately start to become clearer:

123	if (new_user.created_at < 10.minutes.ago) && !new_user.invitation_token && (new_user.created_at == new_user.updated_at)

view raw better if statement hosted with ❤ by  GitHub

We can go further still and forcibly document the intent of each part of the if statement by separating and naming the components:

12345678

user_is_recently_created = user.created_at < 10.minutes.ago invitation_is_unsent = !user.invitation_token user_has_not_yet_edited_profile = (user.created_at == user.updated_at)   if user_is_recently_created && invitation_is_unsent && user_has_not_yet_edited_profile ...

view raw clearest if statement hosted with ❤ by  GitHub

It takes some courage to write a line like “user_is_recently_created” because it’s such fuzzy logic but we all do it at times and owning up to that helps inform the reader about the assumptions you’ve made.

Notice also how much stronger this approach is than using comments. If you change the logic there is immediate pressure on you to change the variable names. Not so with comments. I agree with DHH, comments are dangerous and tend to rot - much better to write self-documenting code.

The better code describes itself, the more likely someone will implement it the way it was intended and the better their code will be. Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors.

"If you want to be a great developer, make sure you write Ronseal Code that does exactly what it says on the tin"http://t.co/6JMyGvGuzl

Go deep before you go wide - learn your chosen stack inside out

"Most programmers waste huge amounts of time by lazily re-creating implementations of pre-existing functionality." http://t.co/6JMyGvGuzl

Check and re-check your code. Your problems are yours to fix

Do actual work for at least (only) four hours every day

Write up the things you’ve done and share them with the team

Understand and appreciate the exquisite balance between too much testing and too little

Take the time to understand what really needs tests and how to write good tests. Take the time to see when tests add value and what the least you need from them really is. Don’t be afraid to test but don’t be afraid not to test either. The right point is a balance; take time to explore where the equilibrium lies.