Hacker News Reader

There's still plenty of awesome things you can do in IT without ever touching code

I spend a lot of my day working in a 'no code' visual programming environment and the difference between the solutions created by the people who know how to program and those who don't know how to program is massive. Those who don't know how to program tend to fail at coming up with non-trivial solutions and are not really able to debug the 'code' when it fails. They also always come up with the most 'brute force' solutions and can't really reason around performance.

Yup. That's because programming isn't just learning the vernacular. It's, first and foremost, learning to express concepts in a structured, super-precise way; learning to evolve systems in your head step by step, according to a set of arbitrary rules; learning the nature of computation.

Familiarity with this type of thinking is visible not just in computer-related endeavors, but often in everyday life matters as well.

IMHO, before all that, programming is admitting before yourself that you are very often wrong (either when coming up with a usable mental model or when applying that mental model or when observing the unforeseen effects).

It's the first leap and as you make it you can manage the emotions and the growth will happen.

We gotta keep beating this drum though. You get people saying programming is just learning Node.Js or learning X or learning Y, and you end up with bootcamps and no computer science. Just reading this thread has been a true journey.

Reading this thread was extremely frustrating for me as I have this idea in my head that everyone on HN is a seasoned software engineer. But obviously that’s not true, which is a good thing! And I certainly shouldn’t be frustrated at other people’s perspectives, it’s making me think about complexity a little more.

I think there’s a lot of misunderstanding of complexity by newcomers of programming. A lot of people are pointing to the current state of the Unix command line as an example of being overly complex and bad. And certainly you could point to this or that command line tool and say that could be better designed and you’d probably be right. But all the command line tools we are familiar with weren’t designed in one go, they grew over time to fill needs. It could not have been done in one go, the different needs of different users and the overlap and disconnect is too great to know all beforehand. And the same thing would happen if we started from scratch today. We would design something we think is great and multipurpose only to realize it doesn’t quite fit this new requirement so we will have to add an edge case. Maybe we could do better than the current standard, but it won’t be perfect, there will always be corner cases and competing requirements.

For some people, bootcamps could be the right entry point. I started by building websites in a wysiwyg editor :)

> They also always come up with the most 'brute force' solutions and can't really reason around performance.

Neither can most programmers if modern software is anything to judge by.

This is a variant of the no-code mindset where people expect coding to be easy.

What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.

When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.

I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.

The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.

In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.

> I don't think I've ever met anyone who was naturally good at thinking logically

I've heard, though, that declarative programming (prolog, haskell etc) was a LOT easier for people who aren't trained in imperative programming. Whereas those who are actually have a hard time picking it up... As was my experience.

@op have a look for declarative programming. You might like prolog :)

I'm someone who learned declarative after imperative. In my experience, there are two things to understand about any declarative language: what it expresses, and what it actually does on the machine. The latter is often considered an implementation detail, but - at least for the people with imperative programming experience - it's actually crucial to gaining full understanding.

I remember my final breakthrough in grokking Prolog was realizing that the engine hides a glorified DFS that walks a graph of concepts for you. Suddenly, all the reasoning and non-deterministic features wasn't mysterious anymore, and performance-related implications became clear. Similarly, for people who struggle with async, it's beneficial to understand that async means somebody hid an event loop from you.

Both Prolog and Haskell make memory management really hard, and without good memory management you can’t reason about the run time of software.

Of course the solution is to learn a lot on the low level details of the compilers for these languages, at which point it’s not easier than imperative coding.

Doubt it. To do anything beyond basic stuff in Prolog you need to understand its resolution algorithm. And it is not enough to understand 'what' it does but also the 'how' which is basically a backtracking algorithm.

My main problem with declarative/functional programming languages is that they force developers to separate the logic from the state (they are not co-located based on concerns) and this often causes developers to neglect the separation of concerns principle altogether; which is by far the most important principle in my experience.

Most developers never learned proper blackboxing/state encapsulation.

It's impossible to create truly modular code without colocating related logic and state.

Yes! Being able to hide state is a blessing but sometimes also a curse. However Monads kind of allow you to hide/abstract over state too. I find it way more difficult though.

> But just like it's hard to become a good musician if you shy away from sheet music, programming is hard if you shy away from command line and a little web searching to know what $PATH is.

I like this analogy a lot. You can't just write code and then say "here, I'm done" most of the time. You need to know the environment it's around and what it needs to interact with/what will interact with it.

> just like it's hard to become a good musician if you shy away from sheet music

A bunch of world famous artists would disagree with you there.

https://www.themusicstudio.ca/blog/2017/11/909/

Those are literal rock stars, people who's fame and proficiency at one very narrow thing has given them the clout to hire and work with people who do all the things they don't know how to do or don't want to know. They're the exceptions which prove the rule.

If you want to be a professional musician who works with other people rather than just doing their own thing, you need to know sheet music, especially within certain sub-domains like orchestral settings.

(To be fair, as someone who is on the periphery of the music business, the above is a simplification. I'm not trying to imply that the "rock stars" get to skate by, often they're working harder than everyone else to be/remain successful. But they are still exceptional in many respects. Your average person trying to make a living as a musician absolutely needs to know sheet music or at least it's simpler cousin, the lead sheet, to be taken seriously.)

I think you have a good point.

I know an fairly good amateur folk musician who can't read music at all. He relies entirely on his ability to learn music by ear. But he can usually play something after listening to it a few times, and he mostly plays solo folk music. So because he's talented and happy in his niche, he can get by without many typical professional skills.

Similarly, I know a CS researcher who hates to use anything but MatLab, and his MatLab code is not exactly an example of good software engineering. But he's published a stack of really great papers. He's brilliant and he works in a niche.

But the average novice would not be well served by imitating either of these people. They can do what they do because they're above average in specific skills, and because they've found a niche where they can thrive.

In that article, none of the artists is quoted as saying what they did was easy. The previous article on the same blog said it's best to learn both playing by ear and to read sheet music, because without reading it's hard to play anything new you haven't heard.

Didn't say it's impossible. I know great developers who don't like the command line.

Dude, it's just a metaphor.

Could you elaborate on which UIs for machine learning you are referring to?

I'm thinking in particular about Kibana (part of elasticsearch stack). I used it, it's absolutely awesome. It's a paid feature though.