4 ms·
It sounds like what is needed is a guild of software engineers[0] that can quality review peers. Throughout this topic there is a thread of "only [talented] so
by eterm 13y ago
It sounds like what is needed is a guild of software engineers[0] that can quality review peers.
Throughout this topic there is a thread of "only [talented] software engineers can rate software engineers". So what is needed is an association of talented software engineers.
[0] with apology if you prefer programmer or other term.
- pnathan 13y agoSteve McConnell (of Code Complete fame) has posited this idea before. I keep circling back to it in my head, but I can't mentally untangle what, precisely, would be the rating. Would knowing GoF design patterns be the criteria? How about ability to use Monads? What about being able to accurately describe red-black tree uses? Perhaps a key dividing line would be the ability to spot bugs in a code review? Basically, what would the minimal body of knowledge be to be an accredited guild (union, professional org, etc) member? The IEEE has built what they call a software engineering body of knowledge. I think it's mostly academic bosh. Am I ignorant for not understanding their reasoning? Who builds the first criteria for what a body of knowledge should be? Having read academic SW engineering publications, I'm convinced that academia does not have the total answer. I'm convinced that, theoretically, there should be a professional organization, and an interview should be a conversation about people skills + a credential check. But I am - today - not sure how to bootstrap such a thing. If something comes along that I think embodies what is really important (both industrial and academic rigor), I will likely leap on that bandwagon and chug the kool-aid.
- krakensden 13y agoI think the problem with such a credentialing body is that within 5 years, the regulatory capture it would experience would make it perverse and useless. Just because you have a technical, or ex-technical, person in charge of your team doesn't mean it's going to be well managed. I'm sure that's something we've all seen. Every reason that is true will apply to the guild, in addition to the usual ugly prejudice, artificial supply constriction, and self-destructive conservatism that all real guilds, associations, and unions display.
- brc 13y agoThese things already exist, and are universally a failure. The top people don't need to join, because they are well known and have reputation. The people that do want to join are those who need the trimmings of an endorsement. So gradually it turns into a grouping of people slightly below average trying to improve themselves. Plus, the people who are attracted to this type of thing work in industries where others are bedazzled by credentialism, like academia and government. A group of people dominated by academics and public servants telling me how good they are? Thanks, I'll pass.
- pnathan 13y agoI don't know that I'd rush to call all unions and professional organizations a failure. Certainly, say, the AMA or the NSPE has a certain usefulness (if you disagree with that, I don't think we have a common ground to talk about this, I am afraid). But I do agree that structural questions about a credentialing/professional organization do exist and have not been adequately resolved in the sw development field.
- brc 13y agoI was specifically relating to the world of software.
- pnathan 13y agoSorry, I wasn't aware that you had confined your comment to our industry. I am in quite definite agreement with you that extant credentialing efforts don't appear to have been successful. I don't think they are intrinsically doomed to failure, however. Suppose that an organization was constructed by professionals from industry organizations who buy into the idea of a credential recognizing competence (as has been done, for instance, in the non-virtual engineering field in the form of the PE). What specifically would be the problem there in your eyes?
- dreamfactory 13y ago> what, precisely, would be the rating Peer review aka open source.
- dreamfactory 13y agoI'd put forward the proposition that not only is there no need to measure productivity of developers, but that this is a counterproductive management approach. 1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives. 2. Then you have the disaster zones - again they are easily recognisable. 3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term. If your development team isn't effective, it's a management problem, not a developer one.