Live data from Hacker News

Speak English to me: The secret world of programmers

github.com

241–250 of 334 posts

Re: Speak English to me: The secret world of programmers

#241

The problem is mainly one of discoverability. The non-programmer in the examples says "simple" when they mean "discoverable". The programmer says "simple" when they mean "not much code complexity". Of course you disagree. All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps…

I wish CLIs had better discoverability. That's one of the first principles of UX. There should be a library that makes it easy for developers to include a basic GUI with a CLI

> That's one of the first principles of UX.

And yet, in the world of GUIs, discoverability is getting increasingly rare. I don't think it's prioritized at all anymore.

Re: Speak English to me: The secret world of programmers

#242

Earlier quoted context omitted.

Most lol. You only hiring MIT and Stanford grads?

Stanford or MIT or UWaterloo

Bah. I took community college courses in highschool and the basic bitch introduction C++ course at that community college had the students using linux in the lab. The second-rate university I ended up going to after highschool required CS students to learn either Vim or Emacs to pass one of the required introduction courses, and all assignments had to compile and run on linux otherwise the TAs would reject them.

As far as I've seen, basic linux skills are taught if not required in the CS programs of colleges of any reputation or stature.

Re: Speak English to me: The secret world of programmers

#243
"Oh, you're a programmer, Can't you do $THING"?

This is the one for me. Yes, yes I could.

If I spent a year learning how to do $THING.

So after that exchange, I'm either stupid, or more likely "Well, if you didn't want to help, you could have just said so".

Re: Speak English to me: The secret world of programmers

#244
post #213

Earlier quoted context omitted.

Some of the manpages for utillinux (e.g., chsh, useradd) are pretty barebones and don't include examples, but off the top of my head I can't think of a major GNU utility that doesn't have EXAMPLES sections in its manpages. GNU coreutils, find, sed, and grep all have such a section in their manuals. What are you thinking of that is example-less?

GNU ls's manpage has no examples, but it's also a thousand words long so it hardly seems fair to characterize it as bare-bones. All in all, I find that manpages on Linux are usually pretty good, particularly compared to systems like MacOS where many daemons and utilities seem to have no manpage at all. People are far too quick to slag manpages, which probably has something to do with the `man` utility itself being a…

POSIX ls's manpage has examples. Well, one example, of `-laRF`.

But also I can't imagine what good more examples will do anyway. `-lahR` cover the vast majority of common uses.

Re: Speak English to me: The secret world of programmers

#245

I find a version of this even with fresh out of college programmers. They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE. And they also are reluctant to learn because they are se…

Absolutely spot on. A very good friend of mine went through a bootcamp and very much views himself as essentially “blue collar” —- do the job, go home. It’s for money, not passion, not at all. There’s nothing wrong with that per se, but with that mentality typically comes a distinct lack of curiosity. He’ll only learn new things when directed to, and unfortunately that means that he learns little and not often. Over time, that makes the experience of being a software developer very painful indeed.

We were talking about a recent problem he was having, getting his IDE and build server and virtual environments talking to each other, and it became immediately clear to me that if he knew what an environment variable was, he’d have solved this in about 5 minutes. Instead he’d been stuck for days, kind of just flailing.

I also suggested spinning up a dev VM or container so that he can make snapshots, nuke it and start over, etc as he makes progress figuring it out. He flatly stated that that “wouldn’t work” for reasons he couldn’t articulate.

I am almost obsessively curious about how computers work, and that curiosity led me to Linux and a nearly 100%-CLI workflow. That more than any other skill has paid off, even if viewed completely dispassionately: at least half the tools you’ll be using will have been written from this same POV, where a CLI-centric workflow and Linux are both first-class citizens.

A lot of people just want to “write code” but seem to completely ignore the reality that that doesn’t happen in a vacuum. You’re using tools, and those tools very often require some understanding of the computer they’re running on.

There’s some meme floating around out there about how “easy is hard” —- exercising is hard, but enduring the effects of not exercising is harder, etc. Now that I’m on the other side of it, I absolutely believe that working in the command line, ideally on Linux (but macOS will do fine as well), is the best way to pick up all the “glue” knowledge that allows you to reason your way through just about any situation you find yourself in. We do ourselves quite a disservice by calling most of these skills those of “sysadmin” or “devops” or what have you —- to me it just seems like it’s “knowing computers,” and when you’re spending your days writing instructions for computers to perform, that can surely only be a good thing.

Re: Speak English to me: The secret world of programmers

#246
post #160

Earlier quoted context omitted.

Yeah, that's the flip side of a simple tool that makes it easy to solve problems. It's not clear when "simple" stops working or how to recover from it. On the other hand, the bespoke software approach can have bugs too.

There are a lot of times where a low-level understanding of Computer Stuff lets me easily get problems in simple stuff. Like if I see a year that's 1969 or a number that's in the negatives and around 4 million, I know some kind of overflow happened and can work from there to diagnose the problem. I don't know the right balance, though. I know all this stuff because you just had to if you wanted to do anything with a…

Overflow to negative 4 million? I guess that would be signed 23-bit integers? I've never seen this in my life.

Re: Speak English to me: The secret world of programmers

#247
If you look at the learning curve of a lot of things that programmers favor over "normal people", they tend to have a thing in common, which is that they have some sort of step right at the beginning. Markdown, for instance, you have to learn the syntax, and then learn something to do with it in most cases (e.g., put it out on your blog). It's fairly easy after that in most ways, but there's that step at the beginning before you can do anything.

Most people receive the training where opening up Word is not difficult, and then once they've done that, there's no step up. They press "a", an "a" appears on the screen. They have buttons that do things like italicize. The first few steps are easy.

It may be the case that after that there is a brick wall in the difficulty curve, whereas the programmer-favored solution is a smooth easy curve for quite a ways. But that first step is sufficient to block most people, and people are often happy to just give up in the face of the brick wall.

This is not unique to programmers. A lot of the "maker" disciplines have a similar step curve. A lot of times it's just that first step that is the hardest overall. But it's enough.

Re: Speak English to me: The secret world of programmers

#248

The problem is mainly one of discoverability. The non-programmer in the examples says "simple" when they mean "discoverable". The programmer says "simple" when they mean "not much code complexity". Of course you disagree. All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps…

I wish CLIs had better discoverability. That's one of the first principles of UX. There should be a library that makes it easy for developers to include a basic GUI with a CLI

> There should be a library that makes it easy for developers to include a basic GUI with a CLI

There are. For example, in Python, Gooey provides that. [0]

[0]: https://github.com/chriskiehl/Gooey

Re: Speak English to me: The secret world of programmers

#249

The author argues that markdown is the best way to write text. I know many people who argue that LateX is the best way to write text, and they also have arguments. As a programmer I sometime prefer the world of clickety-click GUI instead that of command line. Doing something in a visual way, requires no knowledge. You just discover how to do things as you do them. Using the command line requires me to learn paths, st…

Latex and Markdown have different use cases. You would not want to write a maths book in markdown and you would not want to write program documentation in Latex. Markdown can be read easily as pure text but Latex is often not very easy to read.

Re: Speak English to me: The secret world of programmers

#250
The problem is most people do not try to put any effort into understanding what they are doing by the computer.

When you ask your wife to fetch you from work at 5 you don't have to explain:

* That she needs to take a car,

* That there must be enough fuel in it,

* That she has to plan some time for the drive and add extra if traffic is expected on the way,

* That she needs to let you know if there are unforeseen circumstances which will likely mean she won't make it.

And yet for some reason, whenever the topic of doing anything at the computer comes up between us, I feel like I have to start from scratch.

"The printer does not work again. Can you help?"

"Is the printer on?"

"Can you check it, you are better at it"

Checking the printer... of course somebody turned it off.

I think there is a combination of laziness and probably something else which makes some people treat computers as not their problem. For the most part the companies making hardware and software cater to these people making stuff they care about as intuitive as possible. They are fantastic when it comes to activities that make ads pop in front of your eyes.

The trouble is with everything else.

Post reply on HN