Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Experienced developers typically have an appreciation of the SOLID (or other) principles - why we have them, how they help, ways of adhering to them etc. This may be as a result of having written poor code in the past, then written good code (where good is adhering to SOLID principles) and seen the tremendous difference it makes, or otherwise had the time and experience to see their value.

How can we begin to instil an appreciation of these things in to apprentice developers?

Currently, at work, I have a group of apprentice developers straight of out college (UK, 18+), with no CS or real programming background. The company has a decent training programme for them to run through, but I feel it lacks the induction to writing high quality code that we would eventually like for them to produce.

My current approach to teaching them about these things is to flag it up in code reviews when I see it. For example, when I see a class (or function) which has more than a single responsibility, I do my best to explain the single responsibility principle (why we have it, how it helps), show them where the multiple responsibilities in their code lay, then talk to them about how they might separate that out.

However, that approach doesn't seem to be sticking. I'm still seeing plenty instances of exactly the same thing I flagged up in code review.

Are there better ways of explaining and giving appreciation of the SOLID principles? Or is this simply something which comes with time and experience?

share|improve this question

closed as off-topic by gnat, amon, Bart van Ingen Schenau, Doc Brown, GlenH7 Aug 31 at 15:35

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, Doc Brown, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers 2

up vote 8 down vote accepted

There are a few things for you to consider to help you keep your sanity:

  1. They won't get it right the first time.
  2. They won't get it right every time.
  3. Habits, both good and bad, take time to form.
  4. Good habits and high expectations are easier to form when there is someone there to help you along - a mentor, senior developer, etc.

Don't give in! There is no magical formula. Some may never get it without you being there to make them change it. Don't let them check in bad code. Make them do it over. Eventually, they may find a few of these errors in each other's code and in yours (Nobody is perfect.).

Too many programmers work in isolation and never have anyone to mentor them and show them the way. There is a benefit to trial and error, but we'd all be better off if we had better mentors early on in our career.

share|improve this answer

I would recommend running katas with them. Once they can learn to apply these principles outside of a production situation, they will start to learn to apply them in their day to day work.

Try focusing the exercises on each principle and gradually adding new constraints.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.