Tuesday, April 30, 2013

A Responsible Programmer





Write Consistent Code




Don't Quick-Fix


Write Short Functions


Separate Commands From Queries



// Can be called whenever, no side-effects
function generateRoute(params) {

// Updates the hash with the new route.
function updateRoute(params) {
  location.hash = generateRoute(params);

Refactor Mercilessly


Prefer Explicit


Don't Fear Advanced Techniques


Check Boundaries


Wrap External Services


External Libraries









The System Overview


The Domain Overview


The Style Guide


Code Comments


// be entirely loaded from the server
function loadCities() {












Continuous Integration/Deployment










Version Control




Own It






Don't Do as They Are Told









Sandro Pasquali said...

Excellent post. Good to know that some still believe in excellence.

Anders Janmyr said...

@sandro, I'm glad you liked it. If you like excellence you are going to love the book Mastery, which I write about here: Mastery

Anonymous said...

What a nice post! Gonna show this to all programmers in my company

Anders Janmyr said...

@anonymous, I'm glad to hear it.

Vitaly said...

Why programmer is "she"? =)

Anders Janmyr said...

@Vitaly, Why not? :)

Vitaly said...

@Anders Just kidding. It's unusual though. )

Great article.

Anders Janmyr said...

@Vitaly, thanks, I thought that it would be interesting to use a she as the hero of the story!

Richard Bucker said...

"refactor mercilessly" that's just wrong. Too much refactoring is a bad thing. Not for readability but for consistency. You have expectations that an API exists and that it works a specific way. (no protected or private code here). Refactoring is supposed to maintain the method signatures as-is but in practice that'snot the case.

Anders Janmyr said...

@Richard, I disagree with you about refactoring, I think it helps make a system consistent. I agree it is a different matter once the API is public, though, then you have to start doing versioning etc., but internal APIs I think should be refactored until they are consistent with the rest of the application.

Jakub said...

I need to print your post and stick to the wall in my office :-) Thanks for the excellent post!

Anonymous said...

it was awesome to see "she" all the way through this. Great list.

Anders Janmyr said...

@Jakub, You're welcome, I'm glad you liked it!

Anders Janmyr said...

@anonymous, I'm glad you liked it.

Martin English said...

Excellent Article !!
WRT Refactoring:
I would prefer 'Refactor appropriately'. Firstly, there are always reasons to refactor code, but you need to stop somewhere :) A typical example is performance; sure you can screw another 2 cycles out of the initialisation routine, but is that the best use of your time ?


Anders Janmyr said...

@Martin, Thanks!

I can't argue with appropriately. It's not a very good argument to say "Don't refactor appropriately!" ;)

I view refactoring mostly from a readability perspective and I feel that many people don't do the little extra that is needed for a maintainable code base.

Anonymous said...

While I agree with most points, I simply can't agree with your views on continuous integration.

Is CI a good thing? Sure.

Is a lack of CI "a clear sign that [the project] is not healthy"? Absolutely not. That's religious talk there. I have worked as a professional (and responsible) programmer for a long time, and CI is only another tool, definitely not necessary for the long term health of a project.

Anders Janmyr said...

@anonymous, If I come into a project and it does not use CI, I see it is a sign that the project is not healthy.

I have seen few that don't use it and are still in good shape. And, I have seen many that use CI, but are in bad shape.

But, not using CI, when it is so easy to setup is, I believe, irresponsible.

Anonymous said...

Well, my experience differs pretty drastically from yours. And we'll just have to agree to disagree on this point.

Anders Janmyr said...

@anonymous, sure, experiences differ, I'm just glad that we agree on the rest :)

tabashir said...

@anonymous - If I find a project where CI is not used, I check out how easy it is to deploy. There's a better than evens chance that you won't be able to check out and get it running with a single command as suggested in the article. Just setting up CI forces you to think about these things.

Gustavo Freitas said...

This is a great summary! Couldn't agree more. I'm sharing it man =D

Anders Janmyr said...

@Gustavo, thanks, I'm glad you liked it.

nna said...

this is a nice post because i still believe in exellent. http//wwww.unn.edu.ng

Anders Janmyr said...

@nna, I'm glad you liked it :)

Sinelogix said...

Excellent post guys
Web Designer in Bangalore

Anonymous said...

Great post. I'm not sure if I agree with your statement regarding refactoring and not doing as they were told though. Ideally you are right. But a responsible programmer also knows how to stay within boundaries: either financial or time given. Refactoring takes time and thus costs money. Both may be an issue. What's the value of code that is refactored to the max making it state of the art, but didn't finish on time? Stakeholder may cancel the project, making the code void, regardless the state of it. The same may happen when the project goes over budget...

Refactoring? Absolutely, I do it often. But it should serve the project and not be a goal on its own. Not doing as was told? My opinion is that a stakeholder, product owner or whoever should describe a desired end situation, but leave the developer free on his/her choice on how to get there.

Anders Janmyr said...

@anonymous, I see what you mean, but more often than not, we, the responsible programmers, are the best people to make that judgement. We can't expect the stakeholders to know the cost of the refactoring and if we tell the stakeholder that this is necessary and must be done right now and then are not allowed, we are essentially saying that it is not our responsibility anymore. I don't think that is the responsible thing to do.

If we are pressed for time, we can still do small refactorings as part of our regular work.