Hacker News Reader

Comment by pizzaman09 | Hacker News Reader

Credentialing. Seriously. Have a Bar Association for developers. When anyone can do a few weeks of Googling and claim to be a software developer, you're going to get mostly crap candidates. Offload that process to a formal body, like lawyers, doctors, and engineers do. You can hire unlicensed developers, but you do so at your own risk. Then once you're talking to someone licensed in an interview, you can focus on just getting to know them and talking about their past work.

Edit: wow, I've clearly touched a nerve. Good thing your doctor is licensed to prescribe something for it instead of a rockstar named Chad who read about MongoDB once but can basically build Uber by this point.

View on HN

Part of the problem is that the discipline is very wide, and there's different mixes of skills needed:

    +-----------+
    |\ business | - excel macros
    | \     +   |
    |  \  users | - web dev
    |   \       |
    |    \      | - back end dev
    |     \     |
    |      \    | - framework dev
    |       \   |
    |        \  | - tooling
    |         \ |
    | coding   \| - OS / compiler / database dev
    +-----------+

There's no simple cutoff that can mark someone out simply as a developer. And the diagram above doesn't reflect the fact that within each slice of the coding wedge, there's a different mix of technologies, different rates of technology turnover, requiring a different mix of e.g. aptitude to pick up new technologies quickly, vs depth of experience in existing technologies, quite apart from what the specific technologies are.

Conjoined triangles of success!

This is maligned and dangerous. It has been shown that credentialing hurts the marketplace and consumers. Having a credential authority would not cause there to be a skill bar, it would just require all of us to pay money to a worthless authority.

> it would just require all of us to pay money to a worthless authority.

Today these authorities are universities.

HackerRank-style test are one of the few ways into a good career for lower-class people who have the skills but can't afford the credentials.

It has been shown where? Please don't forget that inexperienced practitioners also hurt the marketplace and customers. Every data breach because someone kept a plaintext password field in MySQL hurts the customers. Every lost hour of productivity because of shoddy code hurts customers.

Big companies already spend a lot of time and money interviewing candidates to figure out if they should be hired. Credentialing will turn that into either a standardized test (which is known to be inferior) or simply require a degree (which will exclude too many good candidates).

Under a hypothetical licensure system, companies would be more than welcome to hide rockstar Chad from the local CS department. They would just, for example, be more liable for damages or something. We can think of all types of licensure schemes, with all types of consequences. What makes you think software engineer credentialing will automatically work out poorly? Moreover, have you also considered its benefits? Oftentimes the world exists in shades of grey, where a system has good parts as well as bad parts. Lawyer credentialing, for example, isn't perfect, but it's better than nothing at all.

Lawyer credentialing exists because individual clients are unable to vet lawyers otherwise. Same with doctors. In both cases, the consequences of getting a quack doctor or lawyer can be disastrous... death or imprisonment, for example. General contractors can cause quite a bit of damage to your home so they often have to be licensed and bonded, electricians can cause fires so they're licensed, and bad plumbers can do plenty of damage to your house too. All of these people are likely to be hired by private individuals.

A bad programmer could rack you up AWS charges, or leak your clients' credit card numbers to an attacker, or other things like that, but these are just financial losses for businesses that don't do their due diligence (nobody's dying, going to jail, or having their house burn down).

> Moreover, have you also considered its benefits?

I don't think the benefits have been adequately explained to me. Maybe I could consider them if you told me what they are.

doctors

Because the healthcare job market is such a success! Remember those accusations against tech companies for colluding to depress wages? Now imagine the same, but with State immunity!

The anti-trust class-action lawsuit Jung v. AAMC alleged collusion to prevent American trainee doctors from negotiating for better working conditions. The working conditions of medical residents often involved 80- to 100-hour workweeks. The suit had some early success, but failed when the U.S. Congress enacted a statute exempting matching programs from federal anti-trust laws.

I never said "let's make software licensure exactly like healthcare licensure". There are parts of healthcare licensure we could also criticize, but that's not my point. If you'd like to discuss specific parts of softwares licensure, I'm more than willing, but don't engage in faulty reasoning.

You don't get to decide how it'll shape up; public choice and markets don't work like that. The decision to mandate licensure unleashes forces that very often lead to the kinds of problems that I described above.

Unless you have a very good reason why it won't in this case, you're just playing with fire.

You are just adding a lot of useless bureaucratic overhead. Are you sure that the problem you are trying to solve will not just be replaced with an even worse one?

No, I'm not, but that's, to be rather frank, a stupid fucking reason not to try. :)

There is powerful opposition in our line of work to this type of thing, particularly the standardized tests. I don't fully understand it because I think that certification exams, etc. have clear, if limited value.

I think it stems from an intrinsic starting point among many developers that programming is a true meritocracy and that all hiring questions can be settled with a judicious study of what the person is truly capable of (eg. the fabled personal github account filled with side projects). And that anything other than "hacking on the code" is a waste of time.

Of course this isn't how the real world works. In fact almost no one has the time, energy, or inclination to do impressive side projects. Gauging skills on the basis on resumes and very short interviews is quite hard and time-consuming. Hiring decisions are made on the basis of essentially social interactions and personal references.

I do think there is room for an informal credentialing process in principle, but there are longstanding mental blocks that will need to be skirted. There will need to be leadership from the top to make this happen, ie. the best, most-respected programmers will need to take it seriously first.

Another solution is law. Establish a formal licensure body and then slowly make it necessary for things like government contracts, or even private contracts.

I don't know from where it stems for the majority of opponents. For me, it stems from a complete lack of faith that the system would be well designed and even relatively free from corruption, and therefore that it would not make things much worse, while not actually solving the problem it's supposed to solve.

Certification exams already exist, and employers are free to require them to avoid the "crap candidates". Other problems, like security flaws affecting the users, can be better solved by imposing real penalties on companies.

For the professions this is quite simple as there are standards, Doctors, Accountants etc are all trained to the standard qualifications that are often internationally recognised.

How could you do that for software engineers? There are so many programming languages, frameworks out there that are constantly evolving and companies have different demands.

I think it would be a really hard problem to generalise.

> There are so many programming languages, frameworks out there that are constantly evolving and companies have different demands.

An idea that I have thought of is to standardize on some programming language/frameworks/demands that are known to be supported for a very long time (15 years?). If you need something from this buffet, you are fine and have the advantages that this provides. If you have special demands, you are on you own - which is not a problem per se, but as all special demands this simply needs to increased risk or cost.

I would love to see some sort of standardisation and rationalisation within software engineering. It's so fragmented and ego driven. Every framework is better than the last, my programming language is better than yours. Thought is rarely given to longevity. I'd much rather work with a more dated ecosystem that I know will be around of true next 20 years than the continual paradigm shifts we endure just now.

I'm exhausted and frustrated with the field as it exists just now.

Fair point, but consider that software engineering is a MUCH younger profession than, say, accounting. Consider that "double entry book-keeping" dates back to around 1340, and accounting in general is even older than that.

We've had about 60 years to figure this stuff out, and arguably the ground is always moving beneath our feat as the nature and scope of the systems we build keeps changing.

I'm exhausted and frustrated with the field as it exists just now.

Likewise, but I'm not sure what choice we have, except to hope Ray Kurzweil is right about some of this life extension ideas. If we can survive another 300-400 years, maybe things will be better.

I'm not sure of anything, but if I had to pick one thing to bet on it would be that none of us, or our children's children['s children] will be here in 400 years.

There are many jobs like that; it's not hard to some Java shop maintaining some CRUD software for over a decade, with no signs of switching. Hell, a colleague of mine just got a decent offer to develop in Informix 4GL.

It exists: https://ncees.org/engineering/pe/software/

No one cares though.

Hence our dilemma.

I would love to sit for a PE exam, except my state requires you to apply for permission, and one of the requirements is 4 years of professional experience working under another PE, after you're already approved as an Engineer-in-Training, which itself required 8 years of experience if you don't have an engineering degree. 15 people sat for the software PE exam last year nationwide compared to nearly 1,000 for some other disciplines.

With those kind of numbers how is anyone with the 12+ years of experience required who doesn't personally know a software PE (of which it seems there are maybe 100 in the United States based on the age of the test and pass rates) supposed to get the certification? I totally accept that my Poli Sci degree means I'll need more professional experience that a Comp Sci or Comp Eng graduate, however the requirement to work under another PE eliminates the vast majority of potential applicants.

Reply on news.ycombinator.com