Are OO skills important when someone has a good technical knowledge
-
I'd beg to differ. What if a candidate isn't exposed to any kind of design pattern mumbo-jumbos at all, for all the years of his work? I've seen and worked with some excellent developers, who can write fast and efficient code, but don't know a thing about design pattern. I'd see knowing design patterns and other flashy stuff a plus, but I'd never miss a good developer who has a solid grasp of the fundamentals, with problem solving skills, no matter what he knows or not knows about design patterns. A good developer can always learn this stuff and cope with your organization (if design pattern and other buzz is a part of your organization's culture). Just my thought though... :)
It is a crappy thing, but it's life -^ Carlo Pallini
I reiterate, it is not neccessary to memorize GOF design patterns or even know all of them.
Rajesh R Subramanian wrote:
A good developer can always learn this stuff and cope with your organization
As I said, for 1-3 exprience I will hire the candidate becaue at this stage he can start learning and become good in OOP. Beacuse at this stage the developer can learn very fast. One who has 5+ year experience in modern days should have already done that. At least they should have known some OOP concepts and some patterns. For example, Factory method and Abstract Factory is too common to miss in 5 years.uage If developer does not know it, it only implies that the developer is not a good learner. Of course the exception to this rule is one who does not have experience with C++/C#/Java or other OOP language.
-
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing? :)
modified on Thursday, August 13, 2009 12:45 AM
Joe Woodbury wrote:
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing?
COMis quite outdated, even atMicrosoft.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Joe Woodbury wrote:
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing?
COMis quite outdated, even atMicrosoft.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]CPallini wrote:
COM is quite outdated, even at Microsoft.
Really! How come most of the new windows 7 stuff is in COM: Jump lists, Ribbon, Direct Write, new Media APIs.
-
CPallini wrote:
COM is quite outdated, even at Microsoft.
Really! How come most of the new windows 7 stuff is in COM: Jump lists, Ribbon, Direct Write, new Media APIs.
Ah, OK:
COMis the blazing MS technology of the moment! My bad: I supposed they blowing on theNETfire! :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
The ability to get on with the job and produce solid, maintainable code is far more important than being able to articulate the ins and outs of OO or know all the latest buzz words or can decribe th einner workings of the 'Useless' pattern. Besides, most people wouldn't know or don't understand OO anyway: many of the companies I have worked at ask lots of questions about OO and patterns at interview but when you get to working they never use them anyway or the workers on the ground don't have a clue.
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
There is a common myth that OO and patterns are inherently related, and knowing OO means you have to know patterns. This is a complete nonsense - a pattern is merely a fancy way of saying that somebody has solved a particular problem in a particular way. It's a formalisation of a recognised problem and solution, that's all - and it's perfectly possible to go through your career writing good solid code without having a clue about what a particular pattern is called. It's completely acceptable to be able to write code that reproduces the Chain of Responsibility pattern without knowing that's what it's called. Ultimately, if your code does what it's supposed to in an efficient and maintainable fashion, that's far more important. I'd be more concerned to find out if he understood techniques like composition and aggregation. It doesn't matter if he doesn't know what they are called - as long as he can explain the basic principles; and you'd find this out by giving him problems to solve that are best solved using the relevant techniques. It's disturbing that so many people are putting emphasis on coding skills, without realising that design skills are just as important for a developer. At some point, you have to come out from the code editor. A good coder must, at some point, be able to pull a design together - if you can't, you're just a code monkey.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
In the end, the client is only happy with the solution, not the way how it was implimented. Internally you should care if his code is understandable, robust etc... but who cares if it's not according to pattern A or B?
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveI can't agree. My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
-
I can't agree. My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
note that I didn't say that design patterns aren't useful, on the contrary. as you said:
KramII wrote:
Design patterns are tried and trusted methods of solving certain classes of problem
but a client, in the end, wouldn't give a sh*t :-D.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
There is a common myth that OO and patterns are inherently related, and knowing OO means you have to know patterns. This is a complete nonsense - a pattern is merely a fancy way of saying that somebody has solved a particular problem in a particular way. It's a formalisation of a recognised problem and solution, that's all - and it's perfectly possible to go through your career writing good solid code without having a clue about what a particular pattern is called. It's completely acceptable to be able to write code that reproduces the Chain of Responsibility pattern without knowing that's what it's called. Ultimately, if your code does what it's supposed to in an efficient and maintainable fashion, that's far more important. I'd be more concerned to find out if he understood techniques like composition and aggregation. It doesn't matter if he doesn't know what they are called - as long as he can explain the basic principles; and you'd find this out by giving him problems to solve that are best solved using the relevant techniques. It's disturbing that so many people are putting emphasis on coding skills, without realising that design skills are just as important for a developer. At some point, you have to come out from the code editor. A good coder must, at some point, be able to pull a design together - if you can't, you're just a code monkey.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Good one.
Navaneeth How to use google | Ask smart questions
-
Depends on the seniority level at which you are hiring. If he has 1-3 years experience yes definitely hire him 3-5 years experience it is a maybe 5+ years experience then don't hire him also he might not know a pattern by name but he might be able to design something which looks iike one of the pattern or the design is very good. Then definitely hire him. Knowing pattern names only is no qualification.
-
note that I didn't say that design patterns aren't useful, on the contrary. as you said:
KramII wrote:
Design patterns are tried and trusted methods of solving certain classes of problem
but a client, in the end, wouldn't give a sh*t :-D.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
Code looks perfect to me.
Navaneeth How to use google | Ask smart questions
In that case, (on a serious note) you could refer him to me if you didn't happen to take him in. We are looking for C++ (on Windows) developers. :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
Well IMO it strongly depends on the project and on the role the guy will play. If you are designing a framework and need an immediatey productive high-level coder, then OO practices will sure be mandatory. On the other hand, if your project does not have such specific requirements, I think he will do more than fine.
2+2=5 for very large amounts of 2 (always loved that one hehe!)
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
Hmm. I'm old enough that my formal academic training predates both object-oriented programming and the notion of design patterns. As I see it, OOP and design patterns formalized and documented practices that more capable and experienced programmers used to develop reliable, maintainable software. I picked up a lot of these practices over the years through solving my own problems and by looking at the code of others. I've seen great object-oriented code written in assembly language. I've seen abominations written in C++ and C# that ostentatiously applied design patterns. I think it's important, perhaps vital, that you understand the ideas behind object-oriented programming and design patterns. Being able to recite pseudo-code for the Observer pattern, or to diagram a design using UML, is less critical.
Software Zen:
delete this; -
Depends on the seniority level at which you are hiring. If he has 1-3 years experience yes definitely hire him 3-5 years experience it is a maybe 5+ years experience then don't hire him also he might not know a pattern by name but he might be able to design something which looks iike one of the pattern or the design is very good. Then definitely hire him. Knowing pattern names only is no qualification.
However - those of us with over 30 years of programming experience - haven't got the the buzz words. I have to bone up on those damn things every time I need to talk to clients. I had no problem learning the OOP style of programming - (I had been trying to program that way for 25 years without the support of the languages) however I had a hard time beating my way through the f...ing terminology. And design patterns ... It is called programming skills.
-
Good one.
Navaneeth How to use google | Ask smart questions
I used to write design patterns without knowing that there was a pattern for that I think you should hire that guy If he is so good, he is not gonna have trouble learning design patterns But if you hire him, you should give him some homework (read the entire Gamma book). You people has no problem if they have to do something for work at home if they think that is a good thing.
Saludos!! ____Juan
-
Use my statement to your boss/management... You can teach a good programmer OO more easily than you can teach someone who knows OO but is a bad programmer to improve their coding... Of course, you could just let it unfold, let them break it, then smugly say "I told you so", but I don't think that will help!
I don't have ADHD, I have ADOS... Attention Deficit oooh SHINY!! Booger Mobile (n) - A bright green 1964 Ford Falcon - our entry into the Camp Quality esCarpade!! Do something wonderful - make a donation to Camp Quality today!!
I couldn't disagree more. There are those who grok OO and those who don't. No matter how much you can teach someone the theory of OO if they don't get it they're never going to apply it well if you force it upon them. This should in no way be taken as a judgement on a person's programming ability, you can write fantastic code in a non-OO manner. It's just a culture thing, and having a few dissenting voices in the team may not be such a bad thing depending on your style. Me? I don't get RDMSs. I can use them well enough, but they always seem somewhat arbitary to me. I don't think I'd get along (coding-wise) with someone who tried to use tables for everything for example.
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
In terms of OO skills, one should be competent at writing classes with a good understanding about OO concepts. However, remember OO is a concept. It is also a concept that has been proven over the years to be an utter failure which SOA has already begun to mimic. OO has not been failure because of what it is but how it has been applied. Its most touted feature has been that of re-use but an in-depth study in this area (Unfortunately, I can't remember the paper...) has demonstrated that re-use after all these years has been dismally, almost nill except at the small group level. Inheritance, which is another touted feature has been touted as the second coming in programming panaceas. Nothing could be further from the truth. Most inheritance hierarchies have been a nightmare to develop and even worse to maintain. It has very little real use in business applications except in specific cases. Ted Patton, of COM\COM+ fame in his second book on the subject described the nightmarish results of the over enthusiastic use of inheritance hierarchies. Most are poorly designed and subsequently produce maintenance fiascoes. Design Patterns are solutions looking for problems. This is not to say they do not serve a purpose but how many people develop projects looking for the proper design pattern to implement first... Not many. Though in some cases it would serve them well if they had. The reason is that design patterns are natural outgrowths as to how most of us as developers think when designing processes. we don't think about using an MVC for example, but many of us implement some level of MVC in many of our projects. Design patterns are best used when used as a guide for particular types of processes but when you start limiting yourself to that type of thought you become very narrowly focused. So how do you look at all this? OO is about one thing only! Organization and encapsulation of both data and logic. This is where OO truly shines way beyond procedural programming. However, it comes at a cost since most OO is not very efficient internally, especially when using polymorphism. It also can lead to as much confusion when written in esoteric fashion as any other programming language construct. I have been in the field over 35 years and still going quite strong at it as a senior software engineer. Everything has its place and its good points but putting too much emphasis on concepts and not enough on the natural abilities of the candidates you interview will have you always looking for the wro
-
However - those of us with over 30 years of programming experience - haven't got the the buzz words. I have to bone up on those damn things every time I need to talk to clients. I had no problem learning the OOP style of programming - (I had been trying to program that way for 25 years without the support of the languages) however I had a hard time beating my way through the f...ing terminology. And design patterns ... It is called programming skills.
LenaBr wrote:
I had no problem learning the OOP style of programming
... and that's what is more important as I said. An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
-
LenaBr wrote:
I had no problem learning the OOP style of programming
... and that's what is more important as I said. An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
Rama Krishna Vavilala wrote:
An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
Somehow, I missed it in your previous post. Now, it all makes perfect sense. :)
It is a crappy thing, but it's life -^ Carlo Pallini