The reason I don’t say, I have 10+ years experience, since I’ve been “programming” since 1998, is that I really didn’t spend all of that time on experience. When someone says, “They have 10+ years of experience…” and nothing about what they learned, then I only come to accept that they know nothing. I have met people online who have said they have so many years of experience, only to be disappointed by what they didn’t know.
What makes someone an expert is not how long they have been working, but how much they have learned in those many years. The common example is the guy who uses the same libraries, techniques, and coding standards from project to project for 10 years. The person doesn’t experiment, doesn’t challenge him or herself. So in all reality, that person only has the experience of 2 years, the one year of learning the language and the one year of mastering the libraries.
Web authoring with HTML is not programming, because markup is not code. Therefore my 11-12 years of HTML experience is meaningless, except for how infrequent I have to look up a tag and its attributes (it is a rare, even for the tags I don’t use very often, thanks in part to IDEs that include that information). Of course, the knowledge in this case goes hand in hand with experience, because web authoring requires you to either know what you are typing or looking it up and if you look it up often enough, you no longer have to look it up. Same concept can be applied to CSS.
Programming is different, in how the solutions are implemented. Programming isn’t just knowing the function name, what parameters it has and what it does. Programming involves forming solutions, which are NOT black and white. The only difference between one solution and the other is how often it needs to be maintained, how efficient it is, and how easily someone else can pick it up to continue it.
A Team Leader does not require a lot of programming knowledge, only how to manage teams and projects. Therefore, it is acceptable for the Team Leader or Director to not know something that his or her underlings know, it is not acceptable to belittle something a team member does based on ignorance of programming concepts, being them simple or complex.
In which case, it is not for the team member to explain simple or complex programming concepts to the Team Leader, only for the Team Leader to trust that the programming techniques employed by the team member is acceptable or provide another method of achieving the same or similar goal. If the Team Leader wishes to govern every step, then there are paradigms that can be used to achieve that. However, it moves away from “Getting Stuff Done” and more into “Getting Stuff Done Right.”
As a developer, I am happier doing solutions correctly or “right” as opposed to just slapping something together. As a developer, I’ll do it, but usually, the work environment doesn’t give much to correcting poor solutions. That is, until a new solution is developed, or if there isn’t enough time for that, refactoring the crap out of it slowly over time. It is my experience that when you apply, “Getting Stuff Done,” it usually has to be done twice to get it right.
I try not to judge people based on a “first impression,” because usually, it is wrong. It is only when you talk to someone for a while or test their knowledge that you gain how much experience and knowledge they have. Even then, someone may score very high in one area, but fall short in others. I’m have knowledge and experience in some areas, but not enough to call myself a senior developer. I have a few more languages to learn, and many more projects to complete and topics to learn.
Programming in generally doesn’t usually have black and white rules on development, which is why it is difficult arguing solutions. Solutions have to be evaluated per each project. So I mean, I usually use PDO for every project, but other projects might require SQL abstraction to allow for switching or supporting multiple databases (well you can still use PDO).
I’ve read the blog post at techrepublic, listing the rules for what makes a better programmer and #2: Practice makes perfect, strike me as relevant.
“A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.”
Possibly Related Posts:
- Easier APIs for WordPress
- Libraries Should Use Liberal Licenses
- Why Writing Documentation Wasn’t a Waste of Time
- Contradiction of Good Object-Oriented Design
- WTF Are People Still Writing PHP Template Engines