Live data from Hacker News

Speak English to me: The secret world of programmers

github.com

271–280 of 334 posts

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

#271

Earlier quoted context omitted.

> I'm frequently stumped by man pages, and end up having to hunt down an example of how to use a particular command line application on Stack Overflow. If you're not aware of tldr [0], I highly recommend it. [0] https://tldr.sh/

man(1) pages on linux are almost all terrible. Unworthy of inclusion in any manual. Proper manuals have examples of use. Many linux man pages don't even discuss (or list, even!) return codes or failure modes.

> Proper manuals have examples of use

This is what microsoft did well with powershell's help system. They have examples. Tons of them.

Why man pages do not is beyond me when most of the time, an example or two is all we need. I bet most people go to the man pages and then google for examples because the man pages weren't helpful.

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

#272
post #226
post #85

Earlier quoted context omitted.

> Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works. this right there. except, it IS easy to learn actually. it's visual, you can click around and find out. if you forget the spelling of some formula, no probs, there is a help button. the interface is what makes it easier, markdown is also an interface. except it's not AS exposed to the user as excel is. peo…

> except, it IS easy to learn actually. it's visual, you can click around and find out. That's not easy at all. I am an actual Excel 2007+ virgin. I switched to OpenOffice (there was no Libreoffice yet; Oracle had not yet bought Sun) before high school. Before I finished university, I abandoned all traditional office tools in favor of open-source tools that use entirely different paradigms from Microsoft Office, e.g.…

Complicated tools are hard to learn. There's no general fix to this. The only way to make complicated tools easier to learn is to watch a bunch of different people try to learn them and tweak little details based on what you see. In Excel 2003, Microsoft had 20 years of doing this. When they moved to the "ribbon" in 2007, they threw a lot of that learning away. So you're right that the ribbon makes Excel harder to learn than it needs to be.

But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

> Searching with your eyes, especially when some options are hidden behind additional clicks as they are on ribbon menus, is so unbelievably slow compared to searching through a comprehensive manual by typing a couple of words

Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures, vs. standing there and asking "What do you want?" ... um, I don't know, what do you have!? The latter is how it feels for new users to be presented with "> _".

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

#273
post #97

Slight tangent from the original post: I wish "normal" people were more tech-literate. I don't think they realize just how much of their autonomy they've given up by choosing to use Microsoft Products/Reddit/Twitter/Spotify/Facebook/TikTok/Apple Products/ etc. We're at a point where now the average person depends on several layers of technology that they can't even conceive of, and often the companies building that t…

The reason is we only have so little time and yet so much to do. For the vast majority of people, understanding technology is simply not worth their time. They have other, more important things to worry about. You don't know nor care to understand how telephones and cars and electricity work. Nor how and where the food in the supermarket comes from. Water comes out of the faucet because faucets dispense water. You ha…

The same can be said for education in general. Many people openly state that it's not worth their time. But most of us would agree that "life's short, ain't nobody got time for education" approach would be devastating for society.

The problem with technology is that people are using it everywhere without having any clue of what it does, let alone how it works. Common sense stops working the moment anything tech becomes involved. Businesses and governments have clearly noticed, and is actively exploiting this. Invasive tracking, DRMs, illegal mass surveillance, or the constant encryption ban proposals might not have gone this far if people had a little more understanding of computers.

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

#274
post #118

Earlier quoted context omitted.

Perhaps these devs prefer the "fix it ship it" mode and don't see the value of learning particular skills. I find it a balancing act to be pragmatic and it involves being skeptical about investing time learning new tech. With everything there is to possibly learn, you have to ignore almost all of it... until (at the latest) it's industry standard in the niche you specialize in and then you have to be open minded that…

Solid thoughts - I neglected to let on that in my case the seniors lament about how new tech sucks, like python being just another perl… etc. They are “tear down prove it to me while I call things retarded” sometimes. Thats where mgmt should step in. Its really only a couple people.

You might be surprised how even people as aggressive or stubborn as this might still find it embarrassing or unreasonable to refuse a lunch-and-learn. Maybe sending a mass invite to a meeting on Python would be seen as passive aggressive, so just start socializing smaller ideas with key people. It sounds like you'd have to be cautious about upsetting people but I think it's always worth it to at least find the most polite and diplomatic ways to suggest things you want at opportune moments. The times I see this backfire is when people let it monopolize their attention or bring negative tone/attitudes.

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

#275
post #89

Earlier quoted context omitted.

I was taught how to get around a UNIX box in CS 101 at a state school.

Purdue CS in the mid/late 1990s. All coursework, if it wasn’t handwritten on paper, was developed and submitted with your account on the department UNIX cluster. I switched majors so didn’t have any freshman courses; I certainly hope they taught people how to use the system. You couldn’t pass a class, let alone graduate, without being able to use UNIX. There were a few side benefits to this setup. First, it allowed y…

Oh, hey, IU in the mid 1990s here. We were doing Scheme on DEC ULTRIX boxes. (Which is also how I ended up being an emacs user. Oh well. Nobody's perfect.)

Good times indeed!

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

#276
post #139

Similarly, many non-programmers can do tasks that some programmers must hire a professional for (like repair drywall, install a ceiling fan, basic car maintenance, etc). Empathy is one of those skills that is as, or more, valuable than any particular programming language.

Empathy, but also boundaries. If someone asks for help it's important to tell them that sure, we can help, but "IT support" tends to be a lot less like "help me assemble this furniture from IKEA", and a lot more like "sure, let's install the ceilig fan, but oh it turns out the ceiling is cursed and now we have pierced the heavens and for 30 days every midnight you'll be visited by the mailer daemon, also we need the…

For sure, that's true of all relationships in life. I'm sure abuse of professional's time unrelated to the task being paid for is common in many fields. "Sir, your total is... But hey what about...."

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

#277

Earlier quoted context omitted.

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.

I've always used Android phones, but my company recently stopped supporting them and told me they have to issue me a new phone - this time an iPhone.

And I'm utterly lost. At one time, Apple was said to be the high priests of user experience, with intuitive interactions that would just work the way you expect. This seems to have fallen by the wayside, pushed out by making it more sophisticated I suppose. Because things that I do instinctively on Android, I just can't figure out how to do. I've had the phone a week now, and I still haven't figured out how to do a "Switch App" (like Alt-Tab). A few times I've accidentally hit it, but I can't figure out what the trick is.

I don't mean to say that it's objectively bad, but it sure has erected a wall against anyone who might migrate from Android.

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

#278

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 feel like there's a fundamental understanding of man-pages that we are just missing. I find myself in the same boat quite often.

man pages started out as a problem. If you don't already know a lot of foundational stuff, it's very difficult to bootstrap yourself with it. There are so many things that say something like "see man fizzlewizzle (3)" or something. I've been a developer for nearly 40 years (mostly in Windows, barely dabbling in linux) and I've yet to figure out what the heck that number means, or how I might predict what the correct number is when I want to look something up myself.

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

#279
post #81

"Normal" people see other people as technologies - you sort of give your problem to the person, maybe mix some money in and then the problem goes away. This is how the relationship with people like lawyers, doctors, salespeople, etc, etc work. They know that engineers (and programmers) are in the same rough class as all the other professionals. These conversations showcase the confusion as they try to figure out what…

In the most kind way possible, this is a truly dark Ayn Rand view on society that fails to understand relationships are far more complex than just goods and services but Empathy. Someone is asking for help on their terms. That means putting yourself in their shoes, understanding, and empathizing. Here is the secret: You are a normal person, every "professional" is. Just because you are a engineer doesn't make you som…

In this case the reason "normal" is in quotes is because the article starts with "It feels sometimes like programmers and normal people speak a totally different language and use computers in totally different ways."

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

#280
post #133

Earlier quoted context omitted.

Building the long-term solution first is often wrong even when you need one. I use the quick and dirty method until I know I'll do that task more regularly and I know enough about the problem so I don't need to make wild guesses about the design.

Not everyone do that tho. And that includes pretty good senior engineers I work with.

Learning to work "quick and dirty" is something I'm actually working on improving, personally.

I don't necessarily do BDUF or anything, but I generally do more "engineering" than is often directly necessary. Partially, it's my personality. But part of it is that in my experience, prototypes have a way of becoming production systems.

Last time I had to do a prototype for work, I split the difference: working quick and dirty, just meeting the minimal requirements, but also documenting what we would need to do if we decided to move forward with it. That felt like a good balance.

Post reply on HN