Are OO skills important when someone has a good technical knowledge
-
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.
-
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.
KramII wrote:
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples.
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit. A positive assertion is where by doing something, like using patterns, there is a positive (and supported with data) gain.
-
KramII wrote:
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples.
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit. A positive assertion is where by doing something, like using patterns, there is a positive (and supported with data) gain.
-
jschell wrote:
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit.
Oh, I see what you're getting at. In that case: Use shallow nesting. Is that positive enough for you? :rolleyes: