211–220 of 238 posts
Earlier quoted context omitted.
I'd pay $$ just to have someone reviewing our Raman bowel of a codebase and documenting it.
> and documenting it Sounds like you need two or three people dedicated to the task. Documentation is a whole profession by itself. Well, good documentation.
: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 beli…
You can be a ruby expert, but to review a ruby PR for Stripe's backend I think you'd need to know a lot about the various internal systems, downstream users, etc that the code impacts
This entirely misses the point of code review. Say it with me: Code review is a knowledge transfer exercise. Finding bugs, security vulnerabilities, and keeping the code maintainable are merely side effects that we appreciate along the way. The primary purpose of code review is increasing the bus factor of the given piece of code and facilitating organic knowledge transfer. That's it.
I mentioned this idea to a very knowledgeable enterprise architect. I was mentioning how much I'd enjoyed being able to use the code review process in this way. His reply: As good of an idea that is, it breaks Agile. So long as the code meets the biz-provided spec, it must be accepted, and if there are other concerns with the code, to make a tech debt ticket to address it at a later date. This, of course, horrified m…
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Earlier quoted context omitted.
No one has to die or quit. You could just hire a new dev who doesn't have to wait for someone to explain the relevant parts of the godzilla object.
I guess we are in violent agreement then. I just happened to have fresh scars from a lot of knowledge that departed with an ex-colleague recently.
Earlier quoted context omitted.
Disclaimer, I'm the CTO @ PullRequest. One thing to note about our service is that we are not trying to replace your code review process if it is already working well and we strongly agree that knowledge transfer is a very important part of code review. ( We actually have code review metrics as well that help encourage and reward your internal code review process. ) However what we do believe and see on a daily basis…
I wonder if, instead of just incremental code reviews, there would also be a way to get a 3rd party review our huge codebase and flag issues (architectural, real legibility -- not just "CC measures") to be dealt with. Then you could keep track of them and burn them down as part of "killing technical debt" goals.
I'm just a reviewer and can only comment on what I've experienced. But I can say that what you're asking has definitely been done.
Having on-demand engineers look at code, without broader context on the project it is in my view the same as something that can be automated either or both via static analysis and custom ci/cd workflow checks. This can probably makes sense on a project with more junior engineers where many basic improvements can be supposedly suggested without needing broader context? I would be keen on hearing the use case
I can think of one real-world use-case, though I have never used this product. It's pretty common in larger companies to have legacy products with a couple of very senior (usually overworked) people and a larger number of junior people. The juniors very often have little experience with the language, much less the frameworks, of these legacy systems. So PR's from junior devs are often very frustrating for senior devs…
Can someone give a solid and succinct review of doing this as a side-job? What was 1) the hourly pay, 2) language(s) you reviewed, and 3) how was the work?
A little background: I've been doing software dev for 20+ years ranging from C++, Ruby (not Rails), front-end/full-stack dev. I make enough in my day job to be plenty happy.
I won't comment on pay (it's good enough for me!) as I'm not sure if it's standardized across the board, but let me just say that I was going to start moonlighting since my current role isn't as much development as I am used to....but I decided that PR was going to be a better fit and here's why:
1) I enjoy mentoring! I love interviewing candidates, doing reviews for my teammates, being a good role-model for junior devs to follow. I've taught and helped folks transition from non-tech to a tech jobs. And as a reviewer for PR, it's a lot of the same sort of thing that I already enjoy doing!
2) It helps me become a better programmer! Seeing novel or interesting solutions is always fascinating to me. I love to learn something new, and reviewing code I'm able to see the mistakes (or learn what didn't work) and then able to then take that knowledge and pass it on!
3) Much more flexibility. I can work as little, or as much as I want. I don't have a client asking where the MVP is. I don't have to worry about project planning, hitting milestones, endless meetings. I do enough of that in my day job. I can pick and choose what I want to review, when I am able. As a reviewer, there is a list of pending reviews to choose from based upon our experience and expertise in certain languages and frameworks. For instance, I often review C++, NodeJS, and React/Angular/VueJS pull requests. I tend to enjoy working on reviews for the same organization so I can pick up on the architectural design, coding style, and on-going design decisions being made...especially when I review code from a new developer joins the organization.
4) The work has been enjoyable and stress-free. I routinely do about 10-20 hours/week (in addition to my 40 hours/week day job). And it's not a fire and forget model. When I perform the review, I'm working with the developer until the review is merged. Sometimes I'll review the same piece of code multiple times as they/we work through feedback given by not only myself, but other members of the team. I am able to see comments from other PR reviewers as well as reviews from the organization.
Another aspect that I haven't seen mentioned much in the comments is that we also get to review code challenges as well! Sometimes organizations don't have the expertise or time to evaluate developers. As a reviewer, I'm able to come in and provide that feedback to the organization on how the perspective candidate did.
5) The folks at PR are also really helpful. They review the reviewers and can provide good feedback, encouragement, and suggestions in order for me to provide better reviews!
Earlier quoted context omitted.
I have reviewed for pullrequest and you’d be surprised how many things one can fix. Why do you think that you don’t have context? You can look at the whole project and see what’s up. And no, you can’t write programs to do this.
It's a rare case indeed where I'd be willing to let a third party in on business logic plus the whole source code for something I was developing. I love talking shop but if I'm really having a problem with a structural issue, it's hard to imagine someone outside giving any better advice than people inside who understand the lay of the land. Meanwhile, it's a pretty much totally unacceptable security risk. So what's t…
Maybe due to limitations on team size, it's not possible to have an in-house expert on every technology used.