Teaching sand to think was a mistake.
Code Review as a Service
121–130 of 238 posts
Re: Code Review as a Service
#122Earlier quoted context omitted.
His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.
In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to mai…
In my experience, splitting the testing team out of development materializes refactoring as costly.
"What parts of the system did this impact?"
"Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system"
"Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore".
End result: refactoring never happens. Get it right the first time.
Re: Code Review as a Service
#123As a PullRequest reviewer, I think many on this thread are missing the forest for the trees.
First, I think many here may be viewing Code Review as a Service from their frame of reference: from unicorn start ups, FAANG tech companies, prestigious universities, etc. Many of the companies that we help aren't coming from this world. They're small startups, looking for technical guidance. They're entrepreneurs who need to ensure they're not being duped by app developers. They're older, less tech-savvy companies that are looking to modernize. These companies need help, and they can get help from people who have technical expertise. (And by the way, some companies aren't sophisticated enough to set up linters or code scanners at their stage of development)
In a similar vein, many of the developers we help may not have had the same level of education, learning, or coaching as you or I may have. For example, I've helped introduce more modern syntax options to developers, such as string interpolation and extension methods in C#, to Options and Streams in Java, to filter/map/reduce functional patterns and optional chaining in Javascript. These developers may have never seen high quality code or had mentors who insisted on a high bar for code quality.
Even for more sophisticated customers, I've left comments ranging from security vulnerabilities (e.g. SQL injection), errors in boolean logic, recommendations for improved test coverage, recommendations for simplifying code (e.g. creating reusable functions), preventing race conditions, and more. I've also reviewed candidate assessments to help unburden senior engineers so they can focus on writing code.
Sometimes, the proof is in the pudding. There's a market for these services and that's why some companies pay for them and why I get to review code on demand. I periodically get feedback from the teams I help that I've done 'Nice Work', receiving positive ratings from the developers I review for. I'm proud that I can lend my expertise to make code better.
Re: Code Review as a Service
#124I'm a reviewer and a firm believer in PullRequest. I do believe that some of the concerns expressed here are valid but I think they belie a fundamental misunderstanding of "what you're getting" from PR. Having an under-experienced contractor review your code without context, pointing out things that static analysis could/would catch sounds like a terrible proposition, but that is NOT what PR provides.
Speaking from personal experience, the reviewers are very knowledgable professionals who are not doing this for money as the primary motivation. The pay is great but is more of a perk/reward for doing something we enjoy, and doing a great job at it. The staff at PR does an amazing job of coaching and guiding reviewers on how to provide the most value to the client and also encouraging us to do our best work. It is never anything like "You need to be faster and bill less, do more, etc" it is quite the opposite, we are encouraged to "keep the clock going" while we research, gain context, etc.
Everything is focused on providing value to the client, and IMHO a stellar job is done. Every review comes with detailed information on who the client is, the make up of their team (seniority, etc), recommendations on what to look for (and what NOT to look for) etc. Essentially you are putting your code in front of people who have been there, done that for a long time and are acutely aware of not only risk but also pain points and how to avoid tech debt. We are providing insight, recommendations and even code snippets on how to avoid repetition, speed things up, or make them easier to maintain.
Re: Code Review as a Service
#125Earlier quoted context omitted.
In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to mai…
In my experience, splitting the testing team out of development materializes refactoring as costly. "What parts of the system did this impact?" "Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system" "Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even wo…
Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline.
It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.
Re: Code Review as a Service
#126Im a 1 MAN SHOP and i hire contractors ( engineers). I am not sure if this a good fit for me? My main concern is of course cost. Do you provide feedback on what todo with the software stack? ( can my guys implement a new plan provided by you?)and 2nd question is do you provide pay for service, for example if i am interested in a new software architecture and my guys just code it up / follow your plan / recommendation. Thx
Re: Code Review as a Service
#127Earlier quoted context omitted.
> Reviewers earn anywhere between $50 and over $3,000/week. They are operating just like a freelancing platform, right? How many hours is a "week" for them? 40 hours? > PullRequest’s payment rates are comparable to those of a senior-level engineer based in the US. Like include life and health insurance, paid vacation, profit-sharing, a generous signing bonus, and more?
Quit perpetuating the tying of these basic things to the standard employment model. Get 'employers' out of the business of managing access to health care for employees. Let people 'pay' for their own vacation. You can provide 'profit sharing' to non-employees. Give me $3k/week and let me manage this myself vs giving me $2.5k/week and telling me how awesome my 'health insurance' is. I want my access to health care imp…
$3k/week is not a metric, if you don't define a week. 40 hours? 168 hours?
Re: Code Review as a Service
#128I've been a reviewer on PR for a couple of months now and it's been amazing. I've gotten to help dozens, maybe hundreds of developers improved their code, fix security, readability, testing and lots of other issues. Sometimes the PR is short and the review is short but sometimes it's much more involved and I've had the opportunity to really explain things and educate people in a way that no lint checker could. I'm able to apply the wealth of my experience and knowledge with specific guidance based on things I've learned from building software for 22 years. I can't think of another way that a company could gain access to that kind of guidance for only $699 a month.
I can go into detail explaining how to safely and reliably structure something and the feedback I get from the developers is positive and appreciative. I also collaborate with other reviewers about things we're seeing and I've learned a ton in the process because the other reviewers they've all got such a depth of experience and knowledge in different areas.
I don't do reviews full time, I have a day job, but I've been earning about $1000 a week doing it just some nights and weekends and that has been really great too.
Overall, I think PullRequest is an enormously positive thing for its customers and the reviewers. We're not trying to replace people's existing review processes if they have them. Our goal is just to add to our customers' capabilities and I think we're going very well at that.
Re: Code Review as a Service
#129I'm all for this if the person reviewing my code will know the context, history and all the details and conversations we had as a team. But in order for that to work, I'd probably be taking most of this reviewer's time. And obviously in order for them to get up to speed with our practices, conventions, architecture, code style and whatnot, they'd probably need to start by doing a whole lot of development on our proje…
Having done more than a few PR reviews and code security reviews for their platform as an Android/Kotlin dev, I've found that the opposite problem is more common. A lot of organizations suffer from insular thinking and their own team often comments LGTM even if there's something glaring.
Writing reviews as an outsider, there's something freeing about knowing that you can review honestly and professionally and not overly worry that a colleague might get offended when you're simply trying to help. It's also not a chore anymore. Since the review is the job itself, it doesn't feel like a distraction. And since you're an outsider, you might know about best practices at your organization that the client hasn't been exposed to.
When I review code, I read the summary explaining what that org likes in a review, but I also make sure to include tools and practices that they might not be aware of. In many cases, I can see they're lacking automated static analysis like ktlint/detekt and point it out. I might notice performance or security flaws that their own team wouldn't consider in a typical PR.
While I actually enjoyed the style of work where reviewing a PR isn't a chore, there are a couple issues I'd like to see improved. Their rates could be improved for the best engineers. Also, the number of jobs isn't always enough for the number of reviewers. Gig work is much nicer if you can actually choose the hours and have more flexibility.
Re: Code Review as a Service
#130I understand NDAs are a thing, but I still don't think I'm too comfortable with the idea of letting a bunch of third-party people look at a bunch of my internal information. And I understand this is targeting startups a lot more than large established companies. But to me that's even more concerning because as a startup you're really trying to move fast and hoping someone doesn't beat you to the punch, and you're handing a bunch of people you don't know how much of your secret internal information, and hope that they don't go talking to other people about it.