Comment by solardev | Hacker News Reader

Comment by solardev | Hacker News Reader

Parent Full thread

I wish we had industry-standard certifications that actually meant something, and were widely accepted. The closest I've seen in the real world is just "degree in comp sci". Other orgs have tried to come up with various certs, but they never seem to have any sticking power.

I guess it's a hard thing to certify when the landscape itself is constantly evolving and skills are obsoleted in 3-4 years. It seems even the pace of change is itself speeding up, and every year I see more technologies come to popularity (if not quite maturity) than I can even remember, much less learn. And it's not just languages and frameworks, but entire architectures... today's best practices are tomorrow's tech debt.

There should always be room for innovators to push the bleeding edge forward, but many businesses don't really need that. Instead, if there was just some shared certification for "good enough engineering" that can deliver a reliable, maintainable product somewhat on time, reproducibly, hiring and job-hunting would be so much easier. I'm so tired of trying to charm recruiters, impress managers, placate HR, all while hoping against hope that the actual dev 2 or 3 interviews later happen to have some overlap in languages, toolsets, shared pain points, etc. It's all such a dog and pony show, with many teams having ill-fitting skillsets and cultures between members because nobody really knows what they're signing up for or getting.

Credentialism is not good either.

And in general I've seen little correlation between credentials and quality, both in the software industry and elsewhere, so I don't think any such certifications will really solve anything either.

I think a more nuanced take on this is that very few companies need top quality, but nobody wants bottom quality.

Top-end devs make a name for themselves and don't really have to worry about hiring. Companies compete for them with crazy high offers.

Bottom-end devs try to make up for their lack of experience or skill by "hacking" the application or interview process somehow.

In between, "good enough" devs power the world's bog-standard apps. They're not going to win any awards or lead any talks, but they can do the jobs well enough to make the company money. They know they aren't top-end and can't just say "I'm quitting, who's hiring?" on twitter, but they are also competing with the hordes of less-skilled devs because there's no easy way to tell them apart.

I've never heard of "credentialism", but why doesn't it work in this instance, when it does for doctors, lawyers, engineers, etc.?

> I've never heard of "credentialism", but why doesn't it work in this instance, when it does for doctors, lawyers, engineers, etc.?

There are loads of bad doctors though, and bad lawyers, and bad engineers.

"Credentialism" refers to over-reliance on credentials, rather than just looking at what someone can do. I'm not against education, but education is not the same as credentials. People that can hack the interview process can also hack the credentials.

I've seen people with college degrees in IT employed as programmers that literally cannot program. I'm not talking "bad programmers" or "brain fart moment", I'm talking "consistently being unable to grasp even basic control flow over a period of months or years". Also some good programmers can be hard to work with for reasons other than their programming ability.[1] Plus not every programmer is suitable for every position or every type of programming or "jibes" with every other programmer in their sensibilities and approach.[2] The hiring process is just as much about that as testing basic skills.

No one thinks credentials are a guarantee of quality (people will always slip through the cracks no matter what), but I'm not sure they're even a strong indicator of quality either, certainly not for programming. This is hard to quantify of course, and just based on my own observations over my career.

[1]: https://news.ycombinator.com/item?id=21585958

[2] Simple example: I'm firmly in team "short names", but I know some people really hate it, but I'm pragmatic if nothing else and don't mind doing whatever works well for the entire team. On one extreme end I've worked in a team that insisted on the longest possible name for everything: every variable had to spell out the full name of the class where it came from, often >20 chars, otherwise people considered it "unclear what anything refers to!" I once added a mkdir() function, this was considered "obscure" so it had to be "CreateDir()", then someone said it may not be clear what "dir" is so "CreateDirectory()", and then another remarked it actually makes all intermediate directories too, so we ended up with "CreateRecusiveDirectoryTree()" – I'm not saying this is "wrong", but it does not jibe well with my sensibilities. Several other things also didn't, so I didn't last too long).

> I've seen people with college degrees in IT employed as programmers that literally cannot program. I'm not talking "bad programmers" or "brain fart moment", I'm talking "consistently being unable to grasp even basic control flow over a period of months or years". Also some good programmers can be hard to work with for reasons other than their programming ability.

Your link talks about "good programmers that lack social skills". In my experience, politeness is a finite resource and dealing with people on a regular basis fully unable to do their listed job is a severe tax on mine.

I wasn't talking about people who are well-intentioned but a bit abrasive if they're having a bad day, I was talking about people who are so unpleasant they "completely crush morale for the rest of the team or company".

I hear ya. Essentially, credentials aren't a good way to measure -- much less guarantee -- quality? That makes sense.

I've encountered several doctors, etc. who weren't very good, including one who shouldn't have been allowed to practice, IMO. Point taken.

Anyway, in your experience, what actually WOULD be a good indicator of candidate quality?

> Top-end devs make a name for themselves and don't really have to worry about hiring. Companies compete for them with crazy high offers.

Those who don't have to worry about hiring are not (necessarily) top-end devs, but good self-promoters and networkers. Not every top-end dev is a good self-promoter or good at networking.

Fair point.

It’s simply too free-form and the industries software is used in are… all of them. I believe it is better to certify the outputs (product features, uptime SLAs, security) than the inputs and how the sausage is made.

Software engineering is building a factory. The inputs are data. The outputs are data. All of the stuff inside the application are the different conveyor belts, elevators, gears, rollers, pounders, etchers, etc. to move and manipulate the data to make the output valuable. The factory can be constructed infinite ways without any care about physical dimensions, and the raw material can be duplicated to infinite amounts. The situation is beyond regulation and it should not be regulated. Only the product output should be regulated.

Reply on news.ycombinator.com