3 ms·
So many things can go wrong. But how do you assess, where to draw a line? What could be used as a guiding light? Currently I try to use the following scenario
by mtrn 10y ago
So many things can go wrong. But how do you assess, where to draw a line? What could be used as a guiding light?
Currently I try to use the following scenario as orientation: If a completely new developer would walk in and wanted to install or build or contribute to a current system/project, how much I would have to explain to this person? How many, "yes, true, but only if" style statements would I need to make?
The optimum here is, that a developer will contribute, without me needing to explain or motivate anything.
Do you use a certain approach? How would you describe it?
- WorldMaker 10y agoOther things that I find useful to consider: How big of an IDE and how many extensions/plugins to that IDE do I need to require? Recommend? Can you take a fresh code clone and hit the big green play button in your IDE and go straight into debugging? How long does it take to build that first time from a fresh start? Subsequent "average" attempts?
- sly010 10y agoIs this really that much different from any other industry though? The system in the story is clearly insane, but every organization (not just software companies) has it's own operational awkwardness, that might look weird for new employees. Imagine that Google has all their code in a single repository. How "insane" is that? My point is I don't see why is it a hard requirement for a new developer to be able to commit code on day 1. Of course if you have hundreds of developers, it makes sense to optimize the process, but personally I would prefer a new college to walk me through things (apprenticeship style) rather than throw me at a repo and go-figure-it-out.
- morgante 10y agoIf a competent senior developer can't come in and make a commit (even a simple one) on their first day, your system is too complicated and should be rethought.