Rhodee

Joined 16 years ago

Karma
102
Submissions
65
Member since
Jan 13
developer. aspiring coffee farmer.
View on Hacker News

Recent submissions

Comment · 4 years ago
:wave: Pull Request reviewer here with over 1000 reviews.

I've reviewed code across languages, team size and maturity. A good static analysis tool is not code review. The word 'context' came up 37 times in this thread (by the time I hit submit) and it is worth digging in to how I build and maintain context with teams. First up, it is my responsibility to uphold, not define a team's best current practices. If you believe a linter and static analysis tools are best current practices, you probably do not need code review. The code review process is an exercise to affirm how well a pull request meets the expectations (context) of a team and suggest remediation where appropriate.

I assume 'context' used in the threads to mean "how we do things here". As a reviewer, I conduct review understanding the problems the team wants its code reviews to optimize for or to avoid. This is due to the people creating the platform. It's a solid platform for reviewers to get things done. Every line of contributed code I review is done with an eye towards ensuring it affirms a team's stated objectives. If those objectives somehow falls outside of what I know to be true from my experiences as a professional and best current practices (BCP), I am empowered to engage the team.

I've had teams request to never provide guidance for coding style issues. Others want to know if how they modeled a React component tree could be improved. My success on the platform relies on always building context. Without that rapport it limits the depth of the review. Because code reviews are interactive, they tend to get better over time. When things go well, the relationship between team and reviewer is seeking a pareto optimum between the pull request and the team's best current practices. When needs change I adapt my reviews. It is the same treatment if you're a one person shop, SME or a listed company.

k thx bye

Comment · 13 years ago
Comment · 14 years ago
I think one of the strengths of Ruby and thus RoR is its kind of simple. Although I will admit the leap to 3.1 was probably more difficult than it ought to have been. I can only speak for NYC but joining the local meetup community has done wonders for my skill building. But remember, this is a ten year process =) Good luck!
Comment · 14 years ago
Beginning last year I was in the same about you appear to be in. I can say, with a lot of confidence, I disagree with the previous comment. BECAUSE Ruby is such an articulate language it was fairly easy for me to pick up, with no formal CS classes in over 15 years. Might I suggest IF you have 1 year and 4hrs a day do the following:

1. Spend three months just in Ruby. I recommend LRTHW (Shaw) and LTP (Pine)

2. Code School 1 & 2.

3. Hartl (will hurt your head in a good way)

4. Repeat Step 1

5. Make apps, learn a few front-end frameworks (bootstrap, zurb-foundation) along the way.

6. Hit the IRC.

Comment · 15 years ago
I've been steeped in this space for a bit - there's catchafire, 5000hands and a bunch of others.

I guess it all depends on geographic scope and focus of the startup. Unreasonable Institute and Global Social Business Incubator are good places to begin looking.

Hope it helps -

Comment · 15 years ago
This was very helpful thank you.
Comment · 15 years ago
Thank you so much. I was not even aware of this. I really appreciate it. Opens up my options.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton