Hacker News new | comments | show | ask | jobs | submit login

A lot of it comes down to the fact that this isn't engineering, and we aren't engineers.[0] The field has a very low barrier to entry (much lower than a bachelors degree). The standards are low, the expectations are low, and there's a strong anti-intellectualism streak. Don't believe me? try talking about "esoteric" stuff like category theory, logic programming, LISP or writing functional specs. At the workplace most of your fellow professionals will stare at you blankly, and even on self-selected places like here or proggit, half the people will rush to dismiss it.

There aren't - as an example - mechanical engineering "bootcamps" because mechanical engineering is an actual engineering field, with high standards, real accreditation, and professionalism. We don't have that, we have middle aged men giving talks in t-shirts and saying stuff like "ninja" and "awesome".

I think we need to face up and rectify the fact that we aren't engineering before we can advance. And yes this requires excluding people who aren't up to standards. We're not the equivalent of chemical engineers - we're the equivalent of alchemists.

[0] with the Caveat that stuff done in Avionics, or Medical Imaging, or anything else with very high standards and rigorous processes could probably be called that.

We're the last market-driven field. So most companies take the attitude of "Take your approach. I'll see you in the market". This isn't anti-intellectualism or realism or pragmatism. This is a different fitness function for software. Bug-free programs aren't inherently good.

If I'm building X-ray scanning software I'm going to be careful. But if I'm writing a Slack lunch bot in Coq for anything but the fun of it, I'm making questionable choices.

You know the old saying: "Anyone can build a bridge that stands. It takes an engineer to build a bridge that barely stands."

I'm not talking about anything as ambitious as making all software be formally verified.

All I want is for the people in this industry to take it seriously, for us to have standards as an industry, and some kind of professional certification to exclude those that don't know the basics. Software is rife with cowboys and it harms the image of those of us who actually care.

> category theory, logic programming, LISP or writing functional specs

But does it fix my problem? I'm sure category theory is interesting for it's own sake, but it won't help my boss add this extra attribute to our product, so it won't help me get paid.

Given that I've already added fifteen form fields this week, my mind is too overburdened to care much about category theory, which will have exactly zero relevance to my next week of adding form fields.

If your role in a company is so removed from the business or stakeholders that you're being assigned tasks like "add 15 fields", then IMO you're already in trouble.

That's part of a larger issue though, where we actually let non-technical people dictate technical specs to us.

I remain open-minded to the idea that category theory could help me make better computer programs, but I have yet to see anything that suggests to me that it really would.

FWIW, I understand how monads work in Haskell & co, and I definitely see their value. But I don't consider myself to know any category theory at all.

SQL and category theory have a fair degree of overlap so there is that.

Are you suggesting that reading a book on Category Theory might make me better at writing SQL queries?

Mechanical engineers are overseeing a software sub-culture with regards to many of their creations being physically manifested. CAD/CAM that spits out g-code to run on mother machines, aka cnc machine tools. I personally would like to see the existing macro primitives available on cnc controls formally structured and abstracted up to enable "normal programming" to occur. Eliminating the fragile, spaghetti code mess that seems to be entrenched. As a g-code programmer I am unable to constructively edit anymore, but this need not be the case.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact