I recently had the opportunity to be conducting interviews since we were looking for more developers to join our small PHP + (1 Python) developer team. We wanted a mix of Permanent and Contractors. The contractors were hired to get a few pressing features out of the way to be quarterly goals.
I usually conducted the first level interview of getting to know a developer and if they come across convincing enough, we proceed to the second stage which depending on whether they are Permanent or Contractors involved pair programming or architecting a solution to a problem we had.
After several weeks of having these interview sessions, I observed something about learning ecosystem in the development space. There is an endless supply of HOW TO knowledge and very few of WHY and WHEN type of knowledge.
When interviewing, I noticed that a lot of the contractors wrote code, had a lot of working experience but didn't seem to subscribe to Programming principles. Yes, they did their thing, maybe got the code working and left but how maintainable is the work they have done?
The primary framework we use is Symfony and if you have a months worth of Symfony experience, you will definitely come across the use of Repositories and Services. As a matter of fact, the SOLID principle is something at some point you will need to be aware of. Some will say Symfony developers are purist and I use to say that but now I feel I understand why and maybe becoming one of them as well with good reason.
One of the questions we ask is fetching data from a CSV file and being able to filter the contents of the file according to business rules, what layers of your code will be responsible for what? Even before working on simple I did hear about SOLID and tried to learn what it meant, I never understood all of it at one point especially the L and I but Single Responsibility Principle at least got nailed down. This question surprisingly tripped a few candidates up. The worst bit is having a candidate litter their CV with all sorts of abbreviations like BDD, DDD, MVVM. When the said candidate was asked what is the difference between TDD and DDD? He sort of described TDD as testing first and DDD as testing after.
I also observed that people who seemed to have worked in more permanent roles for a longer time in their career faired better in principle-based questions. Could it be because they had to spend years maintaining the systems they worked on?
One might argue, well you don't need to be an expert in theories, it is about practicality. I feel there is time for enough theory and practicals. Practicals without a theoretical foundation is akin to using that single hammer for every nailing job in the house. Theories come first then practical application afterwards.
Being able to distinguish when to use one approach over another will depend on the knowledge and principles governing each approach. In an object-oriented language, we have design patterns, we have fundamental OOP concepts like polymorphism, encapsulation etc but when you have Abstract classes all over the place as a mean to share re-usable code without really understanding the principles behind it. When do you use an Interface, an Abstract class or when will a Decorator pattern benefit you the most?
For learning purposes, it is good practice to not focus on the HOW but also look at the WHY and WHEN. There are a lot of Youtube videos that quickly show you how to do a thing, however, I find books to really contain a lot of information that would need days of youtube videos at a stretch to cover (video editing is hard).
I understand that we all have different ways to learn but would you shy away from a goldmine because it is located in a place you don't feel comfortable with? I have had to get back to my books and plan to read them from cover to cover. Going back to the basics I say to myself. Getting back to the fundamentals that transcend the latest framework. Frameworks will come and go but the principles remain the same.
My current reading list at the moment is - Clean Code and Clean Architecture by Robert C. Martin (Uncle Bob). I have watched a few of his talks, taken notes of the points he highlighted but reading the book has a lot more. I am now more conscious of simple things like function naming, make sure the code is easy to comprehend I don't necessarily need to litter my code with comments to explain what it is doing. This is also something we strive for within our team during code review sessions.
A good resource for learning about Design Patterns and when to use them is https://refactoring.guru/refactoring.
I have also been looking out for materials on Git especially around commit messages practices and found a couple of videos and even attended a few workshops on them. We can't keep writing git commit messages that sound like - "SOME CHANGES"
I hope this encourages you to look back and ask why you do what you do? Why your project structure is the way it is, are there principles governing your approach? Do you do what you do because you saw someone do it that way?
I will never call myself an expert but I am always keeping an eye out for best practises, patterns used by others and if you have any reading materials worth mentioning please share.
Top comments (1)
Look to work under someone, that was the best thing that happened to me, if that person is very talented, you'll get some spills :D
Learn some production ready techniques, but everything will come slowly.
Most important thing: every 3 months, ask yourselves, "What did I learn in last 3 months not at home by myself but here at work" as soon as your answer changes to "nothing" or "not much", it's time to move :)