Hi Ian, I’m not sure that there is any solid research out there on this kind of thing. Much of the information seems to be anecdotal or wisdom earned from experience.
I’m not sure exactly what your role is there, but I am guessing you are responsible for how the development gets done; lead dev, engineering manager, or some such? If that is the case, then the bigger problem is why you should need to have this kind of conversation at all. If your founder feels it is necessary to micro-manage the engineering process but yet has no understanding of how codebases can quickly deteriorate then I suspect you have a bigger problems than just finding articles to back up an approach you want to try. I suggest getting some decent static code analysis tools onto your codebase and showing your founder the decline. Once you have a baseline to work with you should be free to try different ways of working and observe your agreed measures to see what approaches have a positive effect. There is nothing like a few objective measures for taking the opinion out of an argument. You should probably further have a conversation with your founder about who is responsible for what. There is nothing more frustrating than being responsible for code quality and speed of features to market but not having the autonomy to implement approaches that you believe will allow you to be successful. Cheers, Adam On 23 August 2016 at 12:47:33 PM, Andrew Harvey (and...@mootpointer.com) wrote: Hey Ian, I can't bring to mind any articles that would support you here, but I agree with your sentiments (and Glenn & Rufus'). Firstly and as you mentioned, the codebase gets messier. Juniors given small tasks aren't pushed to understand them as part as a bigger system, so what you end up with is small pieces of micro-complexity being added without refactoring where a senior (knowing more about how the whole thing works and how software tends to evolve) might avoid the accrual of technical debt by refactoring earlier, rather than layering on a "minor" feature. While none of these changes may be terrible on their own, the sum of them is an increase in surface area Secondly, you end up stunting the growth of your team and limiting knowledge sharing. Juniors don't learn when to refactor, or about the broader system, because the deep knowledge of the app has been siloed away from them. Seniors don't learn how to mentor and communicate. They lose an opportunity to become mentors and leaders, instead get their superiority complex re-enforced by working on "big features". You might attempt to ameliorate this by having the seniors do code review. The problem is, code review tends to end up being a rubber-stamp process where the senior might pick on some style issues (so there are some changes), but rarely will they address the substance, because that will require them to get involved in a minor change which are beneath them, and will steal time from them working on "big features". But you already knew all that :) I'm not sure how you can really sell this. Founders might feel like they're "wasting" senior engineers by having them work with juniors or on "easy stuff". I can imagine it's pretty hard to convince them otherwise. There's only so many times you can go around yelling "false economies" while waving your arms in the air. All I can add is "good luck". A. On Mon, Aug 22, 2016 at 3:02 PM Ian Tinsley <itins...@gmail.com> wrote: > Hi, > > I need to explain to a founder how having senior engineers work on 'big > features' and junior engineers working relatively unsupervised in a > separate team on 'bugs and small tasks' has been a major factor in > destroying the codebase. > > I was going to write up some examples of what clean well-factored code > looks like and how it turns ugly given inexperience and inadequate > supervision but i'm hoping there is a well written post already out there > which says it so much better than I could? > > Anyone seen anything like this? > > cheers > > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rails-oceania+unsubscr...@googlegroups.com. > To post to this group, send email to rails-oceania@googlegroups.com. > Visit this group at https://groups.google.com/group/rails-oceania. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceania+unsubscr...@googlegroups.com. To post to this group, send email to rails-oceania@googlegroups.com. Visit this group at https://groups.google.com/group/rails-oceania. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceania+unsubscr...@googlegroups.com. To post to this group, send email to rails-oceania@googlegroups.com. Visit this group at https://groups.google.com/group/rails-oceania. For more options, visit https://groups.google.com/d/optout.
