Comment by tokenadult | Hacker News Reader

Comment by tokenadult | Hacker News Reader

The article kindly submitted here notes, "I would submit that the appearance of hard work is often an indication of failure. Software development often isn’t done well in a pressurised, interrupt driven, environment. It’s often not a good idea to work long hours."

I would submit that this applies to many "professional" occupations. A lawyer has to produce a draft of a brief or of a contract in time to meet a deadline set by the client's schedule, so the work output just has to get done. But the draft brief or draft contract works best to meet the client's needs if it is developed after thought, and being just-plain-busy isn't the same as thinking. "There is no expedient to which a man will not go to avoid the labor of thinking."[1] So, yes, whether you are a manager of programmers, or a manager of lawyers, or a manager of physicians, or of any other kind of professional, you have to know the professional's craft well enough to know what good work looks like, and you have to make sure that the professional has time to think, and usually time to confer with colleagues to get a reality check on the thinking. (The article kindly submitted here gives the example of the author learning from the original coder of a body of code how the code worked. The code was elegant, but it wasn't easy to see the elegance at first glance.)

[1] https://en.wikiquote.org/wiki/Thomas_Edison#Misattributed

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.

Steve 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.

I 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.

These 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.

I 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.

I was specifically relating to the world of software.

Sorry, 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?

> what, precisely, would be the rating

Peer review aka open source.

I'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.

A lawyer has to produce a draft of a brief or of a contract in time to meet a deadline set by the client's schedule, so the work output just has to get done. But the draft brief or draft contract works best to meet the client's needs if it is developed after thought, and being just-plain-busy isn't the same as thinking.

Right, but this goes back to a point higher up in this thread.

If Lawyer A writes the contract from scratch every time and takes two days, but Lawyer B has a modular contract-assembly system she optimised earlier and just needs to make a few tweaks -- which will take two hours -- which lawyer will you pick?

That human nature thing again: we'd distrust the person who can get it done too quickly. (Though, we might be able to grok the situation enough to appreciate B's initiative and, especially if we wanted a lot of contracts, might be able to override our instinctive reaction that she hasn't had enough time to think about it properly.)

Reply on news.ycombinator.com