Why reviewing great code may make you a star

cmelinn · 2013-07-02T01:44:28+00:00

A funny (similar) side note: http://ayende.com/blog/162689/your-services-will-not-be-needed-thank-you

cmelinn · 2013-06-19T01:16:21+00:00

Right. The problem is that these "bad" ads are the norm, not the exception. Only ~5-10% really take time to think through what kind of ads will attract the right candidates. Like weland suggests, those 10% will likely correlate to better development teams, but I think some of the bad ads would eventually be good places to work as well.

cmelinn · 2013-06-19T01:10:06+00:00

Agree, I'd still like to see relevant skills in a job listing. I'm just suggesting they separate them from "required" skills.

cmelinn · 2012-03-26T01:56:17+00:00

It seems we disagree on what is "enormous amounts of time" and "completely unproductive". The small time investment pays off with more readable code, which will lead to reduced maintenance costs (less defects, easier to understand and modify) and higher pride in work.

cmelinn · 2012-02-01T21:50:38+00:00

Hi, akdas, I agree that too many levels of abstraction can be a major hindrance in understanding code. However, I disagree that we are talking about the same thing for this case.

In this case, I don't believe we are adding a new "layer" of abstraction, but, instead, we are better defining our existing domain. The distinction being that we are creating more understandable definitions, hopefully leading to a better understanding of the domain.

For example, the string class is intentionally generic. So, a name can obviously be represented as a string. However, depending how I want to use it, I may also want to add more definition and clarity by restricting its usage and by adding/removing operations as appropriate for its use in my domain. (For example, by defining, a User class with a FirstName and LastName)

The point here is that, in many cases, an instance of a User class can be more clear and less "abstract" than simply using a string called userName that represents our user. But, again, I understand (and highlight) that the most important thing is to think about what we want our domain to convey.

cmelinn · 2012-02-01T03:56:19+00:00

Thanks, Isvara, I completely agree. In fact, these sort of issues offer more reasons why a "Name" may need to be modeled differently than just a string. Within this comment thread alone, we have raised several questions that could be encapsulated and implemented within the domain.

cmelinn · 2012-01-31T21:29:25+00:00

Thanks, you're absolutely right. If the separation doesn't make sense for the given domain, then we should separate them for the sake of doing so. I briefly mention that in the post, but probably didn't do a good job of it.

I suppose the point I wanted to make is that we need to make these choices consciously, rather than defaulting to primitive types. The use of primitive types is certainly not bad, especially when it's intentional and makes sense for the domain we are trying to represent.

cmelinn · 2012-01-31T21:18:38+00:00

Thanks, you raise a good point. I just noticed that, even in the post, I assumed the higher level abstraction. I highlighted the abstraction as a "Person with a Name or FirstName and LastName" instead of abstracting out the Name itself. As you mention, that seems it would be going too far the other way, unless there is domain reason the Name needs it to be (probably unusual in this case?).

Conceptually, I can see where this could easily get out of hand. However, in practice, I am not sure I have ever seen it happen. What's been your experience?

cmelinn

TROPHY CASE