A very simple rule
I have a very simple rule that serves me well: Don’t think too much about your life after dinnertime.
I have a very simple rule that serves me well: Don’t think too much about your life after dinnertime.
Stuart has written this fantastic concise practical guide to privacy for developers and designers. A must-read!
Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.
I concur.
Use the frameworks and libraries that make sense for you to deliver the best UX possible. But also learn the web platform from the ground up. Take time to understand how web browsers work and render webpages. Learn HTML, CSS, JavaScript. And keep an eye, if you can, on the new things.
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)
queries to break to layouts that allow for more real estate as it becomes available.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Excellent advice from Stuart.
Watch—and more importantly, listen—to this five minute video to get the full effect.
Pessimism always sounds smarter than optimism because optimism sounds like a sales pitch while pessimism sounds like someone trying to help you.
I usually hate these kinds of lists of bumper-sticker aphorisms but some of these have me pondering my own work, like this one:
People learn when they’re surprised. Not when they read the right answer, or are told they’re doing it wrong, but when they experience a gap between expectations and reality.
Or this:
There are two types of information: stuff you’ll still care about in the future, and stuff that matters less and less over time. Long-term vs. expiring knowledge.
If only all thinkpieces on complexity in software development were written in such an entertaining style! (Although, admittedly, that would get very old very fast.)
A layman’s guide to thinking like the self-aware smol brained
Write about what you learn. It pushes you to understand topics better. Sometimes the gaps in your knowledge only become clear when you try explaining things to others. It’s OK if no one reads what you write. You get a lot out of just doing it for you.
Lots of good advice from Addy:
Saying no is better than overcommitting.
An opinionated blog about writing. I’ve subscribed in my feed reader.
I’m not usually that keen on lists of pithy aphorisms but some of these really resonated…
- If you stop to listen to a musician or street performer for more than a minute, you owe them a dollar.
- Efficiency is highly overrated; Goofing off is highly underrated. Regularly scheduled sabbaths, sabbaticals, vacations, breaks, aimless walks and time off are essential for top performance of any kind. The best work ethic requires a good rest ethic.
- The biggest lie we tell ourselves is “I dont need to write this down because I will remember it.”
- Buy used books. They have the same words as the new ones. Also libraries.
- You can be whatever you want, so be the person who ends meetings early.
- It’s thrilling to be extremely polite to rude strangers.
Someone was asking recently about advice for public speaking. This was specifically for in-person events now that we’re returning to actual live conferences.
Everyone’s speaking style is different so there’s no universal advice. That said, just about everyone recommends practicing. Practice your talk. Then practice it again and again.
That’s good advice but it’s also quite time-consuming. Something I’ve recommended in the past is to really concentrate on the start and the end of the talk.
You should be able to deliver the first five minutes of your talk in your sleep. If something is going to throw you, it’s likely to happen at the beginning of your talk. Whether it’s a technical hitch or just the weirdness and nerves of standing on stage, you want to be able to cruise through that part of the talk on auto-pilot. After five minutes or so, your nerves will have calmed and any audio or visual oddities should be sorted.
Likewise you want to really nail the last few minutes of your talk. Have a good strong ending that you can deliver convincingly.
Make it very clear when you’re done—usually through a decisive “thank you!”—to let the audience know that they may now burst into rapturous applause. Beware the false ending. “Thank you …and this is my Twitter handle. I always like hearing from people. So. Yeah.” Remember, the audience is on your side and they want to show their appreciation for your talk but you have to let them know without any doubt when the talk is done.
At band practice we sometimes joke “Hey, as long as we all start together and finish together, that’s what matters.” It’s funny because there’s a kernel of truth to it. If you start a song with a great intro and you finish the song with a tight rock’n’roll ending, nobody’s going to remember if somebody flubbed a note halfway through.
So, yes, practice your talk. But really practice the start and the end of your talk.
Blogging isn’t dead. In fact, the opposite is true. We’re about to enter a golden age of personal blogs.
Make it easy for people to find you. Buy a domain name and use it to create your own website, even if it’s very simple at first. Your website is your resume, your business card, your store, your directory, and your personal magazine. It’s the one place online that you completely own and control – your Online Home.
Good advice. Also:
Don’t write on Medium.
Look, I get it. Writing on Medium is an easy way to pick up readers and increases your chances of going viral. But the costs exceed the benefits. Medium is terrible for SEO. You don’t own your content and the platform makes it difficult to turn one-time readers into loyal ones.
The more you can use platforms you own, the better. Rather than writing on Medium, do the work to build a personal blog. That way, you can have a central place to point people to.
A great tool is not a universal tool it’s a tool well suited to a specific problem.
The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them.
Good advice for writing:
- Think about what your readers might already know
- Write shorter sentences, with simpler words
- Constantly think about audiences
- Communicate with purpose
- Clear communication helps teams solve problems
Never mind Kevin Kelly’s 68 bits of advice, here’s Amber’s 24 nuggets of CSS lessons for people new to web development.
Dave shares some of his personal horror stories from public speaking, but also some of his practical tips for avoiding those kinds of situations.
This was a really fun podcast chat—nice and snappy at just 20 minutes.
Like Michael Pollan’s food rules, but for JavaScript:
- Plan your scripts out on paper.
- Stop obsessing over tools.
- Focus on solving problems.
- Maintain a library of snippets that you can reuse.
I got an email recently from a young person looking to get into web development. They wanted to know what languages they should start with, whether they should a Mac or a Windows PC, and what some places to learn from.
I wrote back, saying this about languages:
For web development, start with HTML, then CSS, then JavaScript (and don’t move on to JavaScript too quickly—really get to grips with HTML and CSS first).
And this is what I said about hardware and software:
It doesn’t matter whether you use a Mac or a Windows PC, as long as you’ve got an internet connection, some web browsers (Chrome, Firefox, for example) and a text editor. There are some very good free text editors available for Mac and PC:
For resources, I had a trawl through links I’ve tagged with “learning” and “html” and sent along some links to free online tutorials:
After sending that email, I figured that this list might be useful to anyone else looking to start out in web development. If you know of anyone in that situation, I hope this list might help.
Lots and lots of programming advice. I can’t attest to the veracity and efficacy of all of it, but this really rang true:
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
And this:
Blogging about your stupid solution is still better than being quiet.
You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.
Create a blog. Post about your stupid solutions.