bphogan

IT people tend to assume that everyone is just as interested in stuff as they are. It's not a great assumption to make. Just cos you think it's cool doesn't mean everyone does. And that's ok.

Metaphors can be terribly dangerous because of personal experiences. For example, I've seen people explain object-oriented programming using biology or automobiles. Those sound great until you think about how many people don't relate to those metaphors.

Other people don't care. I don't care how my cellphone works - I care that it works, and if you tried to tell me how it works, I'd tune you out. It's not in my scope of give-a-damn, you know?

If you feel you're terrible at explaining things to non-technical people, reflect on whether or not those people really need to know those things.

If you determine that they are interested, and that you are unable to adequately explain, consider finding situations where you can understand their side of things. A great way to do that might be to learn how to do something that they do. When I meet a new client, I ask them to explain very technical parts of their job to me. Then I am the person on the receiving end of that. I can observe how they explain things, and I can empathize with them when my eyes glaze over. :)

Hope that helps a little, or at least gave you some ideas.

Student feedback always suggested these were incredibly valuable lessons.

So "gets decisions right" sounds good as long as you agree with those decisions.

I happen to love working with Elixir and Phoenix. I find working with Ecto frustrating not because of the code, but because of the opinions the framework creators have made about where things go. They have good solid reasons for their opinions. And they are not wrong.

I just don't agree with them. And that's totally ok.

It seems to promote short-term gains over long term goals.

See IMSAI in the 1970s for a great example of needing to hit goals at all costs.

But my internet connection was rural, and 1200 baud. It was possible.

I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails."

Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea.

* your experience may vary. :)

I would love to know the context of this. Was this seriously a talk that was given somewhere? Do people actually accept this as actionable advice?

It's a little unnerving to me.

As far as graceful degradation, If I open a properly built page in a text-only browser, there are no styles. There's no real emphasis or bolding. There's just text. Because CSS didn't exist.

Now, if you want to live in the early part of the decade when it was OK to put inline styles and background colors in your HTML, that's fine. But the world evolved beyond that. HTML with <body bgcolor" is deprecated.

Because HTML is the content. CSS is how it looks. And JS is how it works.

So C-a-a still does beginning of line.

HTML is the content and description of content. You put a <strong> tag around text to make it strong emphasis.

CSS is the presentation. Your browser sees the <strong> tag and applies its default style of making it bold.

I hate, hate, hate having to alter my HTML to apply styles. The idea of

<h1 class="primaryColor">

totally creeps me out. I do it because other people refuse to use preprocessors and think that altering the HTML to include presentational details is fine (see Bootstrap.)

But it still feels gross to me.

Don't measure experience by how long someone's done things. Measure it by what they've done. It's that old quote about "10 years of experience, or one year of experience repeated 10 years."

I've also been following this individual. I don't tend to agree too much with what he has to say because my experiences are very different.

I met a dev at a meetup the other night as I was giving a talk on Elm. He's been doing web dev almost as long as me. He still does HTML with tables. He uses inline CSS. He's never investigated a preprocessor, and has never looked at Angular, Backbone, or React.

But he's successful, so, shrug.

So be wary of "appeal to authority" arguments. Yes, he's been around a long time. Doesn't mean he's right.

None of us are really right. Just weigh all the opinions and decide based on experience.

I'm too old and tired now to try to convince people I'm right and they're wrong. I'm more interested in saying "I think this is cool and here's why."

For the record, I think Elm is the future and you can pry Sass from my cold, dead hands. Those are just my opinions, and they may change. It doesn't mean anyone who uses jQuery and straight CSS is wrong.

It's quite a shock when you start noticing that $3 bottles of water start adding up.

"Google doesn't care, and these other sites don't care, so why should I care?"

I have found that validation serves a very important purpose - to guide your development. I have lost count of the times I have encountered CSS with all sorts of extra junk because things didn't look right, and the reason for it was that the underlying HTML was invalid.

Yes, the browsers are smart. But they are still guessing. If you leave out a tag, the browser will close it for you. Not always in the right spot. Invalid pages could also result in a DOM tree that's not quite right, so JavaScript could be affected.

Developers should validate their pages just as they lint their code, to ensure quality.

Of course, if you're using cutting-edge elements, they won't validate. But that's a little different story. It's not a reason to not validate, it's just a reason to filter out those errors.

If you rely on a third party for business, you need to plan for it.

The rule always applies: You will pay now or you will pay later.

Although I take issue with "when chat is down your business is at risk."

Pick up a phone. Use Skype. Send email.

Business was done for thousands of years before chat apps. :D

Seems like a quick script would set all this up for us :D

The tech is all there. It just sucks to set it up yourself and should just work out of the box.

I'm curious though.

What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings.

I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything.

If I had the resources and the money, I'd focus on a good modern IRC client and server.

Am I wrong?

But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.

Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.

:D

One of the things I've long known as a programmer for the web is that when you let a third party put content on your web site, you don't have control over what they do.

Whether it's a person entering content and you fail to sanitize it, or pulling in ads from an external network, the end result is that you get something like this eventually.

I don't have a solution, really, because nobody wants to pay for content, so sites have to use ad networks. But I'm surprised this hasn't happened much sooner.