Hacker News Reader

I think you're right.

There ought to be, if there isn't already, a phase in most peoples' journey with programming where they dig into and experience the fundamentals; the maths, structures, and practical application of theoretical techniques. The reason being that you're not going to get very far in any domain if you don't know how to deal with complexity.

I think there comes a turning point when you've mastered enough of the fundamentals that domain knowledge becomes more useful. Code becomes an artifact of solving problems in your domain. If you've mastered the fundamentals the correct code (for some appropriate definition of correct) becomes easier to develop. Regardless you end up becoming more of a domain specialist and programming is just your _force amplifier_.

Though I think this can get a little dangerous with some folks who might mistake our ability to "learn as you go," as some innate ability to understand and solve problems in any domain. I think this has an effect on our industry where programmers with little experience in a domain think they can write software to solve problems in that domain and iterate until they learn that domain and voila! Disruption!

The problem with that is there are some domains that require mastery due to ethical and legal constraints. There's a reason why you don't just become a civil engineer by following some blog posts and watching Youtube videos.

Still I think that if you are going to be a civil engineer -- if you know a thing or two about programming, like knowing maths, you will be a "10x civil engineer."

>programmers with little experience in a domain...write software to solve problems in that domain and iterate...Disruption!

I don't think that will change much until the overwhelming demand for more software is mostly met with a sufficient number of properly trained Software Engineers. At that point we should start seeing real competition on the quality of the solutions. (and a move towards professional licensing)

It seems likely that the first civil engineers saw a similar pattern. When you have a creek to cross and no one around is qualified to design a bridge, someone gives it a shot anyway. If it collapses they try to build a better one (iterate). Hopefully this can be accomplished without killing anyone.

Now that the world has a decent number of properly trained Civil Engineers though, we don't need to wing it most of the time; especially for the big, consequential projects.

It all has to start somewhere, I agree.

Why I still think we're in a dangerous area with this is that there are established industries with domain experts who simply are not programmers. Inexperienced programmers might come in with solutions to problems that have genuinely good intentions -- a bridge to help people cross the creek; but there are people who already know how to build reliable bridges and you have to be able to either become one of those people or understand enough of their domain to collaborate with them.

I find a lot of great developers become pseudo-civil engineers. If you ask them to switch gears and write a video transcoder they're going to be about as useful as an intermediate programmer with zero-domain knowledge; despite having been writing software for civil engineers for that last 20 years and being in the top of their field... it's the domain knowledge that makes a big difference.

I don't think you understand what domain knowledge means. If the civil engineer is a user of VLC, Youtube, etc. then they do not have "zero domain knowledge" when writing a transcoder.

Not to mention that if they really are a great developer they'll just fork an open source project and be pretty much done.

No matter who you are, the more virgin code you write yourself today, the more immature and vulnerable your application will be.

The notion of a regulated Engineering profession really came about when some very famous bridges started to collapse under load. In response to this, there was public outrage and distrust in governmental projects such as bridges. Thus, the government conceived a program where engineering labor supply is regulated through training and association standards.

Unless software creates such a large loss of life and disruption that the public has a similar outrage. The government will not act to regulate programming. In addition, it's neither in programmers or companies best interests to be regulated (except for programmers that are good at programming and companies that would like to pay a higher price for labor in exchange for quality).

> Unless software creates such a large loss of life and disruption that the public has a similar outrage.

The way things are going, I think that's a matter of time.

>In choosing between learning Haskell or learning 3d programming...

This is a false dichotomy: https://wiki.haskell.org/Game_Development

As the linked response from Rich Hickey pointed out, you can do anything in any (Turing complete) language.

I agree with the notion behind your decision to focus on real results though. I think that is actually closer to the mastery part of the progression from beginner to master. I think when one can deeply realize that programming is just a tool to achieve other things, then one is leaning towards the mastery end of the scale.

That's not a hard rule though, I think part of the problem we all have discussing this sort of thing is that we have a hard time consistently measuring where a person is on that progression.

> you can do anything in any (Turing complete) language.

Exactly. The point of the parent was what to choose between learning a new domain or a new programming language (when you already know python) and what would give most value combined. I agree that knowing python+3d will be more valueable than python+haskell.

Agreed.

Just to clarify one thing: I wasn't dissing Haskell or anything, I was just giving a real autobiographical detail. I actually did start learning Haskell, and at some point realised it wouldn't let me build anything new. I'd still love to learn Haskell and still plan to, because I like the art of programming. I just deprioritzed it compared to other things.

(And I totally forgot the Op was clojures’ author, that’s not the reason for the example!)

> But, end result, you won't be able to make something qualitatively different that you couldn't make using Python. Learning 3d will allow you to make new things.

Your point is well taken, but I think the particular example of Python and Haskell doesn't fit your argument. I find that many programmers are not exposed to functional programming, so learning Haskell will provide a very different perspective on programming for someone who only knows imperative languages like JS or Python.

I believe that what you make in a language is explicitly influenced by the grammar of that language. Some things simply won't occur to you if you don't have the right vocabulary. It's the old "if all you have is a hammer, everything looks like a nail" saying. If all you have is Javascript, then distributed systems are going to be scary and hard. But if you can think in Erlang, not so much.

Likewise, I would encourage every programmer to learn a declarative language like SQL or a logic language like Prolog. Languages like these have very different properties than run of the mill imperative languages, which will surprise and enlighten many developers.

I don't think it's an either-or thing. Getting better at programming will make you more effective in whatever domain you are working in. I think it's generally good to work on concrete projects but "what can I actually achieve with code I write" is heavily influenced by general programming skills. In my current domain of VR development the quality of product I can build is at least as influenced by my general programming skill set as by my domain expertise. Getting better results continues to require me to develop more expertise both in the domain and in programming (and I am already advanced / expert level in both so I don't think this applies only to relative beginners).

I (pretty much) agree. I would suggest that other domains (not unlike 3D programming) that Rich Hickey learnt in order to "do something" were "marketing", "OSS cat herding" and others.

I think, like everything, it's a trade off.