martinvanaken

Hi Sheff, I'm Martin, co-founder of PullReview. I'm interested in understanding why the SaaS is not a good solution for you. Is it because you are not using GitHub (or any other online forge)?

Thanks for your interest anyway.

Martin

+1 to that one. Code Review should be Peer Review - it is not about a Senior reviewing a Junior it is about a developer reviewing the work of another one. The junior's questions may actually be as useful as advices (notably by forcing you to explain your choices).

Thanks, nice list, summarize a good part of the best practices in a short form. Will quote.

Hi, author here. I agree this may not be easy - but something can always be done. I've been in several situation.

As a team leader facing junior developers, I did simply set-up rules. I explained them, but I had the power to enforce them by myself. I coded with them, and they started coding like me - until they were confident enough to challenge me. I apologize to the "autonomous self organizing teams" evangelists, but in some situations, giving some direction may be the most efficient way to progress.

As a peer, you just need to find one other person in your team that is willing to play along. Although I understand the value in explaining something, doing it is for me much more convincing. If you really think something is a good practice, don't try convincing me if you are not already applying it yourself.

If you are in an Agile/sprint oriented team, just propose to test it for one sprint, then it will pass the retrospective test or it will not - no one should object to a one sprint experience, especially in an agile team. Do the same with your colleagues ideas, even if you find them silly. It shows goodwill, and you can be surprised at some time.

This is actually the way me arrived to our current workflow at 8th color (http://blog.8thcolor.com/2013/09/how-our-own-workflow-is-dri...) - successive retrospectives.

Finally I would not involve non coding management in the discussion if possible, as it will quickly devolve into "what would it cost". Better to handle this inside the technical team.

Hope it helps, and remember, it's the first step that cost. Find one willing colleague and start!

Martin

Great list (especially "off the top of your head"). Thanks a lot for sharing. Several of those can actually be implemented in an automated tool (styles, short variables, spacing, unused variables even). What's your take on automated tools? (Disclaimer: my company built one - pulreview.com).

I agree with you, and this is the reason why having small features and reviews for all of them helps. Groking a colleague's code is much simple if it is a small piece, and when you are reviewing his code regularly (and the other way around).

Our typical PR is 1-2 days of work, so I'm reviewing several by week, something by days.

You are of course right that it should not fall into "you should do it my way". Now, when my colleague said "I would have done it differently", I always ask how and why. I will probably not change my code if it is good (or even good enough), but I would have learned something, or got another point of view.

Its the whole point for me: even if I prefer managers that I can convince, I just call that "development". Replace: "feature is done but need to be tested or reviewed" by "feature is not done".

The fall in the technical/developer responsibility anyway for me.

Hi, OP here. Interesting list. I think I would approve most of your points, but never worked (or created) such a "proper" environments in my various teams. Could you share the kind of checklist you use? Or give an idea of the kind of "checks" you have there?

Thanks!

This one should be recorded on http://www.codingconfessional.com/

Hi, I think both are actually useful. The CI is supposed to run the tests (even if I like to run some myself when reviewing), but I agree that starting the application is a part of the review - you should not stop at just looking at the code (but just startint the application does not cut it either for me).

Martin (OP)

My point (as another commenter pointed), was more that, as long as you do not put a lot of money in, you'll have ample opportunities to recover, even in the worst case. Especially in the market we are in. This does not invalid your point, as I agree that there is plenty of jobs and money to do around here in the sector.

You see : we clearly have enough stuff to fill a museum.

It is not especially the fear of losing knowledge, more about opening our industry and what it does.

May be it can push us so have a little less horror to show ?

I'm not sure I like the analogy (as a gold miner disappearing into the mountains), but it certainly made me laugh.

I remember someone saying that one of the biggest winners of the incubators processes were sometime the incubators themselves (via the equity they get in the companies they help). You analogy is not that far.

Thanks for the thought.

Martin

Thanks for all comments an replies, I did post a quick wrap up on what it means to pick a language : http://blog.8thcolor.com/2012/07/you-are-not-just-picking-a-...

I'm following very closely what is happening in the "dynamic languages on the JVM space", and I agree there is really ambitious work and progress there (Mirah & JRuby from Charles Nutter & others, Kotlin, Groovy, etc). I like the fact that we are coming to a situation where you can use the language you want on the platform you want.

You are right, the reason for the examples are that I wanted to start from a practical situation I experienced, in place of making another discussion about the pro's and con's of dynamicly vs staticly typed languages (I found both to have their use, depending on the project but also on the people).

Thanks for the informed answer. I agree on most of your points, and my experience goes in the same direction as yours : most of the problems I thought would happen due to the dynamic nature of the language did not really happen.

I'll certainly take a look at YARD.

It is important to know your own preferences, but as you said yourself, then you need to make your choices accordingly : it could be the startup, or aiming for a position in a big company where you have something to say about those choices. Both are interesting.

For the first point, I will not start a discussion about what is a "good" language (a large part of it being in the eye of the beholder and in the requirements of the projects).

Most large companies (and even mid-sized ones) have some kind of "technological environment of choice" that sort of given (three languages is already not so bad). It does not means it cannot change or be lifted for a specific project, just that it is "what you are supposed to use", and that you are expected to provide heavy arguments to be allowed deviate from it.

In most situations, this is actually wise : behind development, you have a whole process (deploy, quality control, etc), and they will have the required tools and expertise for the languages they use on a regular basis. And when you start a project at a large company, you know that other people will take it after, so it is easier if it is close to the company technical standards.

Having written an application in Ruby in a Java shop, I remember protesting on the "rewrite in Java" that happened just after the prototype phase. With some distance, I think I understand the decision.

Same here. I think those discussions are useful because, as you, I think Rails is really nice, but it does hurt my domain driven design optic. I think many people are searching various way to overcome the ActiveRecord "problem" (/design decision). I saw a presentation by Corey Haines on this recently, and it did gave me some food for thought : http://blog.8thcolor.com/2011/11/arrrrcamp-fast-rails-tests/.

I'm currently working on a new Rails project, and I'm delegating more and more responsibility to model objects that does -not- extends ActiveRecord. Works for me, for now.

For work : Rework, from 37signals. Fresh, opinionated and funny.

For leisure : A Dance with Dragons, from Georges R.R. Martin "Game of Thrones" series (the HBO version is superb, but do not miss the books either).