<story><title>When hiring developers, have the candidate read existing code</title><url>https://freakingrectangle.wordpress.com/2022/04/15/how-to-freaking-hire-great-developers/</url></story><parent_chain><item><author>olliej</author><text>No, &lt;i&gt;every&lt;/i&gt; project I have worked on has review gated commits. It is a &amp;#x2F;basic&amp;#x2F; step in ensuring that a project maintains a high quality codebase. Review does cause delays, because reviewing takes time, but we&amp;#x27;ve generally found that the speed &amp;quot;gained&amp;quot; through poor change control is more than made up for through bad code.&lt;p&gt;Review also shouldn&amp;#x27;t be causing ego antagonisms. You&amp;#x27;re coworkers. You have to be able to work together. That&amp;#x27;s called having a job.&lt;p&gt;Every project I have worked on in a professional setting has had mandatory code review, with review acting as a gate. That&amp;#x27;s been required in order to maintain software quality despite the quality of engineers I&amp;#x27;ve worked with.</text></item><item><author>rileyphone</author><text>Sure there are a 1% of megaprojects that require additional process, but for the rest PRs are a method to control code quality socially. They introduce delays and foster ego antagonisms, so less methodical ways to control quality are optimal if the requirements are met (buy-in + skill) and complexity isn&amp;#x27;t too great.</text></item><item><author>anyfoo</author><text>I&amp;#x27;m sorry, no, there&amp;#x27;s plenty of code that requires much more than two sets of eyes, and outside discussion, for any project above a certain size. I trust your experience that the teams and projects worked out like that, but they must have been suitable to that approach, which is definitely not universal.&lt;p&gt;As one example, do you think cross-functional changes to the Linux kernel from even trusted contributors can just be merged without review and feedback from people across all affected subparts of the kernel, as long as they have been written through pair programming? That&amp;#x27;s a big open source example, but plenty of companies have plenty of projects for which that already applies as well.&lt;p&gt;&amp;gt; The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.&lt;p&gt;That is an easy trap to fall into (and wildly annoying), but it does not mean that PRs have no use outside of that.</text></item><item><author>BFLpL0QNek</author><text>Skipping pr’s is not equal to skipping code review.&lt;p&gt;If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo&amp;#x2F;quick mob session before commit. Then there’s a level of trust in your teammates.&lt;p&gt;PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of your team.&lt;p&gt;The best teams I worked on who delivered working code fast, efficiently even when they are some of the most complex projects I worked on committed straight to trunk, had a very good build pipeline (super import) and worked closely together for review. The standards where extremely high yet the general feeling was it was less dogmatic, micromanaged or kept behind a gatekeeper.&lt;p&gt;The projects I’ve worked on with dogmatic pr’s generally failed to deliver anything in any amount of reasonable time. The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.</text></item><item><author>zdragnar</author><text>&amp;gt; Bonus points for no PR’s and trunk driven development as that shows a very mature team.&lt;p&gt;Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it&amp;#x27;s extremely helpful for everyone to have a second set of eyes on work before it is merged in.</text></item><item><author>BFLpL0QNek</author><text>I like this approach.&lt;p&gt;Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard”  or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch.&lt;p&gt;At least being taken through existing code you know what you are getting yourself in to. Also looking at the current open pull requests and closed pull requests to see the standard and speed of delivery. Bonus points for no PR’s and trunk driven development as that shows a very mature team.&lt;p&gt;My simpler interviews have often been with companies that have held a higher bar than the ones with tougher interviews. Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived.</text></item></parent_chain><comment><author>chiefalchemist</author><text>Agreed. I&amp;#x27;d like to add that PRs are not only a means to review code to improve that code. They&amp;#x27;re also way for new hires and jr devs to learn new things, how the hive mind thinks, etc. This is, ideally, today&amp;#x27;s PRs help improve tomorrow&amp;#x27;s code as well.</text></comment>
<story><title>When hiring developers, have the candidate read existing code</title><url>https://freakingrectangle.wordpress.com/2022/04/15/how-to-freaking-hire-great-developers/</url></story><parent_chain><item><author>olliej</author><text>No, &lt;i&gt;every&lt;/i&gt; project I have worked on has review gated commits. It is a &amp;#x2F;basic&amp;#x2F; step in ensuring that a project maintains a high quality codebase. Review does cause delays, because reviewing takes time, but we&amp;#x27;ve generally found that the speed &amp;quot;gained&amp;quot; through poor change control is more than made up for through bad code.&lt;p&gt;Review also shouldn&amp;#x27;t be causing ego antagonisms. You&amp;#x27;re coworkers. You have to be able to work together. That&amp;#x27;s called having a job.&lt;p&gt;Every project I have worked on in a professional setting has had mandatory code review, with review acting as a gate. That&amp;#x27;s been required in order to maintain software quality despite the quality of engineers I&amp;#x27;ve worked with.</text></item><item><author>rileyphone</author><text>Sure there are a 1% of megaprojects that require additional process, but for the rest PRs are a method to control code quality socially. They introduce delays and foster ego antagonisms, so less methodical ways to control quality are optimal if the requirements are met (buy-in + skill) and complexity isn&amp;#x27;t too great.</text></item><item><author>anyfoo</author><text>I&amp;#x27;m sorry, no, there&amp;#x27;s plenty of code that requires much more than two sets of eyes, and outside discussion, for any project above a certain size. I trust your experience that the teams and projects worked out like that, but they must have been suitable to that approach, which is definitely not universal.&lt;p&gt;As one example, do you think cross-functional changes to the Linux kernel from even trusted contributors can just be merged without review and feedback from people across all affected subparts of the kernel, as long as they have been written through pair programming? That&amp;#x27;s a big open source example, but plenty of companies have plenty of projects for which that already applies as well.&lt;p&gt;&amp;gt; The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.&lt;p&gt;That is an easy trap to fall into (and wildly annoying), but it does not mean that PRs have no use outside of that.</text></item><item><author>BFLpL0QNek</author><text>Skipping pr’s is not equal to skipping code review.&lt;p&gt;If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo&amp;#x2F;quick mob session before commit. Then there’s a level of trust in your teammates.&lt;p&gt;PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of your team.&lt;p&gt;The best teams I worked on who delivered working code fast, efficiently even when they are some of the most complex projects I worked on committed straight to trunk, had a very good build pipeline (super import) and worked closely together for review. The standards where extremely high yet the general feeling was it was less dogmatic, micromanaged or kept behind a gatekeeper.&lt;p&gt;The projects I’ve worked on with dogmatic pr’s generally failed to deliver anything in any amount of reasonable time. The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does.</text></item><item><author>zdragnar</author><text>&amp;gt; Bonus points for no PR’s and trunk driven development as that shows a very mature team.&lt;p&gt;Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it&amp;#x27;s extremely helpful for everyone to have a second set of eyes on work before it is merged in.</text></item><item><author>BFLpL0QNek</author><text>I like this approach.&lt;p&gt;Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard”  or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch.&lt;p&gt;At least being taken through existing code you know what you are getting yourself in to. Also looking at the current open pull requests and closed pull requests to see the standard and speed of delivery. Bonus points for no PR’s and trunk driven development as that shows a very mature team.&lt;p&gt;My simpler interviews have often been with companies that have held a higher bar than the ones with tougher interviews. Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived.</text></item></parent_chain><comment><author>dhzhzjsbevs</author><text>People seem to have forgotten what code was like back in the bad old days.&lt;p&gt;Fuck that dogpile of bullshit.&lt;p&gt;You&amp;#x27;ve never seen a 1200 line diy function to parse XML have you?</text></comment>