Are OO skills important when someone has a good technical knowledge
-
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.
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
-
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).
KramII wrote:
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).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
-
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.
I was hoping someone would point out that design patterns are not part of OO.:thumbsup:
-
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
But after being stuck in FORTRAN (77/90/95) for the past 6 years, I can say that that tool set makes a large number of problems easier to solve and I miss that dearly.
-
But after being stuck in FORTRAN (77/90/95) for the past 6 years, I can say that that tool set makes a large number of problems easier to solve and I miss that dearly.
-
KramII wrote:
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).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
-
:wtf: Ouch! In my last post I was almost going to say you could write OO code in any language if you were good enough. But I am not sure I know anyone who could do it in FORTRAN. I feel for you.
I've incorporated as many elements as I can without being able to go with the kludge of a OOP language that they attempted to make with FORTRAN 2003. The liberty that they've taken with operators alone would make your blood boil. Languages designed by committee rarely result in anything usable. But hey, I was able to get some people to start using pointers and dynamically allocated arrays. That was a MAJOR accomplishment. Oh and recursion was another thing that I taught some people. Just imagine what you would have taught a person in a high school computer science class about 18 years ago and that is what I'm stuck trying to bring people up to. :) But all in all, I don't mind all that much, since I do get to work on interplanetary spacecraft for NASA.
-
I've incorporated as many elements as I can without being able to go with the kludge of a OOP language that they attempted to make with FORTRAN 2003. The liberty that they've taken with operators alone would make your blood boil. Languages designed by committee rarely result in anything usable. But hey, I was able to get some people to start using pointers and dynamically allocated arrays. That was a MAJOR accomplishment. Oh and recursion was another thing that I taught some people. Just imagine what you would have taught a person in a high school computer science class about 18 years ago and that is what I'm stuck trying to bring people up to. :) But all in all, I don't mind all that much, since I do get to work on interplanetary spacecraft for NASA.
OO FORTRAN??? :omg: :wtf: :confused: I haven't written FORTRAN in 20 years. I had no idea anyone had tried to morph it into a OO language. Frankly FORTRAN was fine for what it did. It would have been smarter just to added recursion to FORTRAN 77 and then make it possible to call FORTRAN libraries from another language and left well enough alone.
-
OO FORTRAN??? :omg: :wtf: :confused: I haven't written FORTRAN in 20 years. I had no idea anyone had tried to morph it into a OO language. Frankly FORTRAN was fine for what it did. It would have been smarter just to added recursion to FORTRAN 77 and then make it possible to call FORTRAN libraries from another language and left well enough alone.
They finally turned it into what we'd almost think of as a full citizen in the procedural world with pointers, recursion and the like in FORTRAN 90/95. It still is missing major bits that each compiler has a tendency to try to fix in different ways. If there were a good universal way to call FORTRAN libraries from other languages, I would be using it, as having to write code that ends up needing to be compatible with Linux, Windows and OSX is just plain painful when attempting to put any type of standardized TCP interface on it. I eventually just gave up due to lack of time/money, so we just run the code on whatever platform and log onto that machine to use it.
-
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
:) We are planning to hire him.
Navaneeth How to use google | Ask smart questions
-
KramII wrote:
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).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
...which could be applied to anything at all.
I'm not sure what you mean. They certainly wouldn't to the "all we care about is the deliverables" school of thought that I (mistakenly) attributed to the original comment. There is far more to good practice than producing an apparently good result for the customer, but which neglects the longer-term interests of both the cleint and the developer.
The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern.
Absolutely! But that really can be said about pretty much any skill.
And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs.
I don't think I said "by itself". I think I said they are *one* of the tools we have available to us. Combined with those other tools (some of which are, I admit, *far* more important) patterns can indeed lower the cost of maintenance. Moreover, the I am convinced that the language of patterns (including their names, the literature) can be a useful comminication tool between developers. And good communication leads to lower costs.
There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction.
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
Patterns are quantification of common practices that existed before the term "pattern" existed.
Of course. But were they as widely used? As well understood? A tool for communication?
And good programmers (presumably) created them without knowing either the names or attributes of them.
And we will continue to do so. But not all of us are "good" programmers - at least not all the time. Not all of us want to re-invent the wheel. And some of us see the benfit of a shared language and approach. Don't get me wrong. I really do think there are more important things than patterns - perhaps they are over-emphasised in some circles - but I also find them a useful tool in providing best value for my clients.
-
...which could be applied to anything at all.
I'm not sure what you mean. They certainly wouldn't to the "all we care about is the deliverables" school of thought that I (mistakenly) attributed to the original comment. There is far more to good practice than producing an apparently good result for the customer, but which neglects the longer-term interests of both the cleint and the developer.
The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern.
Absolutely! But that really can be said about pretty much any skill.
And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs.
I don't think I said "by itself". I think I said they are *one* of the tools we have available to us. Combined with those other tools (some of which are, I admit, *far* more important) patterns can indeed lower the cost of maintenance. Moreover, the I am convinced that the language of patterns (including their names, the literature) can be a useful comminication tool between developers. And good communication leads to lower costs.
There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction.
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
Patterns are quantification of common practices that existed before the term "pattern" existed.
Of course. But were they as widely used? As well understood? A tool for communication?
And good programmers (presumably) created them without knowing either the names or attributes of them.
And we will continue to do so. But not all of us are "good" programmers - at least not all the time. Not all of us want to re-invent the wheel. And some of us see the benfit of a shared language and approach. Don't get me wrong. I really do think there are more important things than patterns - perhaps they are over-emphasised in some circles - but I also find them a useful tool in providing best value for my clients.
KramII wrote:
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
No. I did however just take another look at "Rapid Developement" by the same author and nothing jumped out at me. So perhaps you could provide a summary of one of the points and the savings that it generated.
-
KramII wrote:
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
No. I did however just take another look at "Rapid Developement" by the same author and nothing jumped out at me. So perhaps you could provide a summary of one of the points and the savings that it generated.
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
-
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
"design patterns, handling the class responsibilities etc." Keep in mind that, until relatively recently (~1994), the term "Design Patterns," didn't exist. The patterns themselves existed, but they didn't have commonly used names. I've been programming for 27 years, so when I learned all these patterns, they were just known as "good architecture." When I started my current job, one of my colleges was steeped in these design patterns, and when we would talk programming, he'd throw out these terms all the time, and I wouldn't know what he was talking about. Turned out all of the design patterns are just things that I already know and use. I just didn't know the commonly-used terminology for them.
-
_Damian S_ wrote:
Hire him and expand his knowledge to include OO if that's important to your company/project.
Problem is I can't take the final decision. My company management is a crap and they think OO is the biggest thing in the world.
Navaneeth How to use google | Ask smart questions
N a v a n e e t h wrote:
My company management is a crap and they think OO is the biggest thing in the world.
I think this really sums up your problem. Based on your own description, the candidate is clearly capable. And I can tell you from doing interviews that the pool of capable candidates on the market is quite small. If your company is unwilling to invest time in a candidate who has most of the skills they need, that's not a good sign. I mean, let's face it, most programmers are short somewhere. But fundamentally, if your management is crap and they're responsible for the direction of your career, do you really want to bring this guy on to sinking ship with you? Maybe you should both be applying to work with whatever competitor is likely going to win the war in your industry.
-
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
-
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
Navaneeth, all of these writers have excellent thoughts and all should be considered. I would keep the position open a little longer and interview other candidates to see how your one guy compares with the others. Someone mentioned that problem solving skills are the best set of skills to have. I would consider bringing him in for a second interview, but also let him know about which design patterns you work with. Give him time to study them. When he returns, ask him about his thoughts, the strengths and weaknesses of some of the patterns, where they can be used best, and his general thoughts. This will also give you a perspective on how his problem solving skills are as well as his research capability. Yes, sometimes, you need to research Google and other sources to get the pertinent information do your job. If he is serious (and sufficiently hungry), then he will do an excellent job and wow you with his new found knowledge and thinking. Design patterns are nice to know and use in conversation when expressing a design idea. But, over reliance on it or fitting the design to a pattern is not justified in its efficiency. And, yes, I prefer simplicity over complex patterning.
-
OO is way more than a "tool" - it is a way of thinking and designing (checks and balances). If you think of it only as a tool, you have missed the whole point.
If you think that a method of thinking and designing isn't a tool, then you are in the wrong profession. The most important tool you have in this game is how you think. If the only way you think is OO, then there are whole classes of problems that you won't come up with an optimal solution for. Having a hammer is great if all you ever work with is nails.
-
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
KramII wrote:
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
You said that they were "important" from you first response when I stated that there were proven methodogies that do improve code which do not have specific impact on code production. What you posted is a negative assertion. As an analogy I would suppose that code without any line breaks at all is going to be hard to understand. And in both cases a code review/walkthough, which is one of the proven techniques for increasing code quality, would discover both of those. I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
-
KramII wrote:
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
You said that they were "important" from you first response when I stated that there were proven methodogies that do improve code which do not have specific impact on code production. What you posted is a negative assertion. As an analogy I would suppose that code without any line breaks at all is going to be hard to understand. And in both cases a code review/walkthough, which is one of the proven techniques for increasing code quality, would discover both of those. I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
jschell wrote:
I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples. I agree with your comment about the benefits of code reviews - these can be very useful for improving code.