On Fri, Mar 04, 2016 at 06:12:07AM +0100, Martin Bähr wrote: > Excerpts from W. Trevor King's message of 2016-02-28 23:29:13 +0100: > > To Martin's earlier point about small businesses and training [4], > > the small business I work for doesn't have the capacity for hiring > > non-programmers for programming positions and training them on the > > job. We do have the capacity for hiring people for technical, > > non-programming jobs and then gradually helping them transition > > into programming jobs. Martin pointed out that that doesn't > > always work, but if the non-programming job is a good enough > > match, you have a longer timespan for the programming training and > > there's no need to transition completely. > > yes, that's where we are struggling. can you elaborate on how you do > the training? what resources do you use, what process? > > we are only 3 people, so no one can take any significant amount of > time to do any actual training. other than pair programming sessions > and "here go study this topic" we have not come up with anything > that could help.
Our pair-programming sessions aren't very formal, but we'll have “I'm about to do something you haven't seen before, want to tag along?” or “I'm stuck, can you help me out?” screen-share sessions. We also do a lot of asynchronous, teach-by-example sorts of things. For example, when fielding a bug report, I'll post my initial feeling (“This is likely a problem with the foobar, because…”) and follow it up with notes as I work through debugging (“In a Django shell on my development database, walking through the code behind that view gives… which is surprising because…”). That's pretty much “want to tag along?”, but it's easier to link later ;). I also include business-logic background, random explanatory chatter, and lots of references in commit messages. I answer business-logic questions with links to the relevant code and an English translations (ideally just a link to the commit message that landed that code ;). In the end, it *is* a fair amount of time. But the extra documentation is a nice resource (e.g. when something similar breaks later, other people can diagnose and fix the new breakage with help from the old notes). Writing out the motivation for a particular commit and looking up docs to reference often helps me notice implementation bugs or missed cases while I'm constructing the commit, so I introduce fewer bugs than I would otherwise. And it makes it easier for me to debug later, when I go back to figure out why a bit of code is the way it is, so I can fix it without introducing a regression. There are no magic bullets, and folks who want to start writing code still have to do a fair amount of legwork on their own, but we get better bug reports pretty quickly this way. I think the rest of it helps provide a supportive environment and an approachable code base. That's useful for new coders in particular, and new hires and maintenance in general. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
