martinvanaken

7 ms·

1.
by martinvanaken 13y ago
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. Mart
2.
Why you need a Definition of Done(blog.8thcolor.com)
4 points by martinvanaken 13y ago|0 comments
3.
by martinvanaken 13y ago
+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
4.
by martinvanaken 13y ago
Thanks, nice list, summarize a good part of the best practices in a short form. Will quote.
5.
by martinvanaken 13y ago
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 th
6.
by martinvanaken 13y ago
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 au
7.
by martinvanaken 13y ago
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 ar
8.
by martinvanaken 13y ago
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
9.
by martinvanaken 13y ago
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
10.
by martinvanaken 13y ago
This one should be recorded on http://www.codingconfessional.com/
11.
by martinvanaken 13y ago
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 cod
12.
We don’t do code reviews to improve the code(blog.8thcolor.com)
3 points by martinvanaken 13y ago|0 comments
13.
How our own workflow is driving PullReview(blog.8thcolor.com)
2 points by martinvanaken 13y ago|0 comments
14.
Don't repeat yourself in your Rails views(blog.8thcolor.com)
2 points by martinvanaken 13y ago|0 comments
15.
Use Rails partials without abusing them(blog.8thcolor.com)
4 points by martinvanaken 13y ago|0 comments
16.
Code Rules are Lines, not Walls(blog.8thcolor.com)
3 points by martinvanaken 13y ago|0 comments
17.
Why Code Style Matters(blog.8thcolor.com)
3 points by martinvanaken 13y ago|0 comments
18.
Git is all about code reviews(blog.8thcolor.com)
2 points by martinvanaken 13y ago|0 comments
19.
Dead code is rotting your codebase(blog.8thcolor.com)
4 points by martinvanaken 13y ago|0 comments
20.
What is the appropriate time for a code review?(blog.8thcolor.com)
2 points by martinvanaken 14y ago|0 comments
21.
We need collective code ownership - and it sucks(blog.8thcolor.com)
2 points by martinvanaken 14y ago|0 comments
22.
Puppet & Vagrant : Smarter / Better / Stronger(blog.8thcolor.com)
1 points by martinvanaken 14y ago|0 comments
23.
Blog post : we were smart(blog.8thcolor.com)
3 points by martinvanaken 14y ago|0 comments
24.
About being a team leader(blog.8thcolor.com)
1 points by martinvanaken 14y ago|0 comments
25.
Fast(er) tests in Ruby & Rails(blog.8thcolor.com)
1 points by martinvanaken 14y ago|0 comments
26.
Entrepreneurs are Employers(blog.8thcolor.com)
1 points by martinvanaken 14y ago|0 comments
27.
by martinvanaken 14y ago
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, a
28.
Technical founders have nothing to lose(blog.8thcolor.com)
9 points by martinvanaken 14y ago|12 comments
29.
What we are paying for(blog.8thcolor.com)
2 points by martinvanaken 14y ago|0 comments
30.
Networking in the Silicon Valley(blog.8thcolor.com)
2 points by martinvanaken 14y ago|0 comments

More ›