Hacker News Reader

Comment by pavlov | Hacker News Reader

I'm a self-taught programmer with decades of professional experience and I don't think of myself as a "handyman". (My only college degree is a BA in film editing & post-production -- which was actually a very useful education, because that gave me the domain knowledge needed to start a software company in the visual effects space).

Your attitude is needlessly condescending towards programmers who don't work on something that you arbitrarily define as cutting edge.

You mention that architects benefit from a network of specialized engineers. That's really no different from what happens in software. The machine learning engineer is not automatically on some kind of unattainable pedestal compared to the UI expert -- they're professionals working towards the same goal.

View on HN

Sure: you're skillful, and you and your team can produce something of value.

However, you are not pushing frontiers in computer science. That's the key issue here: the physics autodidacts all think that they have an idea that can blow away several hundred years of well-tested scientific theory.

CERN and every single particle accelerator in the world can run only because Einstein's theory is taken into account.

GPS timekeeping works only because Einstein's work is taken into account.

My attitude isn't condescending, and there is nothing wrong with being a handyman either.

The truth of the matter is that unless you have a very good fundamental knowledge of computer science and primarily math there are things that you cannot tackle as "programmer" unless you are a unique case. A self though programmer is also unlikely to be working on optimizing databases or search engines, compression, driver/os architecture, various algorithms such as video and audio compression and many other things.

I don't claim to be able to do those things and I don't mind thinking of myself as a 21st century mechanic or handyman because in the end I know that my capabilities based on my knowledge and experience are limited.

I know self-taught programmers working in drivers, operating systems, video and audio compression... It's primarily about gaining a deep understanding the system and the problem domain.

A formal education is a starting point towards gaining that understanding, but it's not the only possible entry. (Who would you rather have working on the Linux kernel: someone who has been following development for 10 years and has read most of the source code, or someone fresh out of school with a CS degree?)

Maybe you're selling yourself short by assuming you wouldn't be able to do those things?

> Who would you rather have working on the Linux kernel: someone who has been following development for 10 years and has read most of the source code, or someone fresh out of school with a CS degree?

False dichotomy. I'd rather have a CS major who has 10 years of experience and has read most of the source code. There's some pretty complex stuff in there: http://cstheory.stackexchange.com/questions/19759/core-algor....

Ditto. I went to grad school for physics, and pretty much all the code there is written by self-taught programmers. I was, too, to some extent, though I did take a grad level algorithms class. A lot of the code was pretty rough.

Indicative example. I was writing code to characterize the datastream from an instrument. It was a compiler of sorts: the end user could write some domain-specific language file to specify certain metadata to observe, e.g. power spectrum in a certain band, etc. These could be reused by other users so one could have a global standard for some state of the instrument. So, I decided on a hash table to store these user-written rules since it was a constant time lookup, and the characterization program ran real time while the instrument was running. Talking with a senior physicist who only wrote Fortran 77, he asked me why I didn't just use an array since "everything ends up being an array, anyway."

There are some things that one may not pick up just from practical experience.

Did they introduce theoretically innovative concepts to any of these fields? It's one thing to write a great database that people love, it's whole another to make a contribution to database theory. And nobody's arguing that people with a formal education are very likely to have the chops either. It's that people who do end up making great contributions are very likely to have a formal education.

I would describe programmers you have described as "tradesmen", similar to electricians, plumbers, pipe fitters, etc. I see nothing condescending about that.

A chemical engineer designs a plant, but plumbers and pipe fitters (and others) are the ones who actually build the plant.

Programming is fundamentally different from building a plant in a number of ways.

To begin with, computer science theory is more akin to what you describe as "actually building the plant" in the sense that it's concerned with the details of algorithms rather than how to design software. Some schools make an honest attempt of the latter but it is in my opinion I haven't seen much useful come out of it. There's simply no replacement for reading other people's code.

Let's also not pretend that academic merits guarantee anything in itself. I've worked with people who couldn't reason about even the most trivial data structures or complexity who somehow had solid degrees in that very subject. How they went about that I do not understand.

I doubt you can reliably tell an autodidact programmer from a formally trained one. Computer science is much too young, and although we want to see us as just another math heavy engineering discipline, that's not all there is to it.

Surely a chemical engineer doesn't design a plant alone. There are numerous other professionals involved: architects, construction engineers, piping designers, structural modellers... These people are not tradesmen.

It's very strange to pretend that a certain class of people involved in designing software are the "real professionals", and the rest are just plumbers.

I use plant as a term of the art.

Calling a group just plumbers is to me condescending: it's a trade that requires creative thinking, knowledge, experience, and a willingness to (literally) deal with other people's sewage. Plumbers are the real MVP. But the same is fairly said for other professions and trades (excepting that, one hopes, the sewage is figurative). There is a difference between those who are self-taught or taught on the job versus those educated in academia, and there are many situations when it's useful or important to be able to distinguish between the two groups. The difference in training doesn't speak to the quality of work, but it does speak to expected capabilities.

I don't understand your first argument. Yes, those people are not tradesmen. They design the plant. However, they don't build the plant. Construction workers do. And if you tell construction workers to "build a plant", you're not going to end up with a good product. You're going to end up with a "bazaar" vs a "cathedral"

Ok, I see now -- I think we have a philosophical difference, because I don't think there are human "construction workers" in software.

Software gets built automatically these days. I make a design in a high-level language and click "Build" in my IDE, and that's the construction step. It can be repeated as many times as needed -- changing a line of code and rebuilding is the equivalent of tearing down a cathedral and reconstructing it from scratch just to change the position of one stone. In the world of bits, that's a perfectly reasonable thing to do.

Some 50-60 years ago, there used to be professions of actual "software construction workers": punch card operators, magnetic core memory weavers... But those jobs were automated away.

If I copy&paste a line of PHP, it's certainly not a great feat of design. But it's still design, just as dropping in a wall element in AutoCAD is design rather than actual construction.

Reply on news.ycombinator.com