Wednesday, May 23rd, 2018
Monday, May 21st, 2018
Some ideas on the best of use of time in sprint zero of an agile project.
- Understand your context
- Identify risks
- Understand the business process
- Get testing infrastructure
- Understand quality attributes
- Get to know the people
- Prepare an initial product backlog
- Build a walking skeleton/spike
- Build a learning backlog
Friday, May 18th, 2018
I had some problems with my bouzouki recently. Now, I know my bouzouki pretty well. I can navigate the strings and frets to make music. But this was a problem with the pickup under the saddle of the bouzouki’s bridge. So it wasn’t so much a musical problem as it was an electronics problem. I know nothing about electronics.
I found it incredibly frustrating. Not only did I have no idea how to fix the problem, but I also had no idea of the scope of the problem. Would it take five minutes or five days? Who knows? Not me.
My solution to a problem like this is to pay someone else to fix it. Even then I have to go through the process of having the problem explained to me by someone who understands and cares about electronics much more than me. I nod my head and try my best to look like I’m taking it all in, even though the truth is I have no particular desire to get to grips with the inner workings of pickups—I just want to make some music.
That feeling of frustration I get from having wiring issues with a musical instrument is the same feeling I get whenever something goes awry with my web server. I know just enough about servers to be dangerous. When something goes wrong, I feel very out of my depth, and again, I have no idea how long it will take the fix the problem: minutes, hours, days, or weeks.
I had a very bad day yesterday. I wanted to make a small change to the Clearleft website—one extra line of CSS. But the build process for the website is quite convoluted (and clever), automatically pulling in components from the site’s pattern library. Something somewhere in the pipeline went wrong—I still haven’t figured out what—and for a while there, the Clearleft website was down, thanks to me. (Luckily for me, Danielle saved the day …again. I’d be lost without her.)
I was feeling pretty down after that stressful day. I felt like an idiot for not knowing or understanding the wiring beneath the site.
But, on the other hand, considering I was only trying to edit a little bit of CSS, maybe the problem didn’t lie entirely with me.
choose the least powerful language suitable for a given purpose.
Still, most of the time, the build process isn’t a hindrance, it’s a help: concatenation, minification, linting and all that good stuff. Most of my frustration when something in the wiring goes wrong is because of how it makes me feel …just like with the pickup in my bouzouki, or the server powering my website. It’s not just that I find this stuff hard, but that I also feel like it’s stuff I’m supposed to know, rather than stuff I want to know.
On that note…
Thursday, May 10th, 2018
James shares his experience of teaching a class of 9 and 10 year old children how to code, and offers some advice:
- Don’t dumb it down
- Use real-world examples
- Make it hands on
- Set clear expectations
- Award certificates and/or stickers
As members of the web community we have a responsibility to share what we have learned. I can’t think of a better way of doing that then helping kids get started.
Thursday, May 3rd, 2018
The latest explainer/game from Nicky Case is an absolutely brilliant interactive piece on small world networks.
Following on from Ben’s post, this is also giving me the warm fuzzies.
I, in no uncertain terms, have become a better designer thanks to the people I’ve had the pleasure of working alongside at Clearleft. I’ll forever be thankful of my time there, and to the people who helped me become better.
A useful design strategy exercise from Marty Neumeier.
Wednesday, May 2nd, 2018
I really enjoyed chatting with Mark and Ben on the Relative Paths podcast. We talked about service workers and Going Offline, but we also had a good musical discussion.
Ben is moving on from Clearleft. I’m going to miss him. I found this summation of his time here very moving.
Working at Clearleft was one of the best decisions I ever made. 6 years of some work that I’m most proud of, amongst some of the finest thinkers I’ve ever met.
He also outlines the lessons he learned here:
- Writing and speaking will make you a better thinker and designer.
- Autonomy rules.
- Own stuff.
- Aim high.
Should you ever choose to work with, or work for Clearleft, I hope these words will give you some encouragement — it is an exceptional place to be.
Monday, April 30th, 2018
A good developer…
- follows the KISS principle (and respects YAGNI)
- knows how to research
- works well with others
- finds good developer tools
- tests code
Monday, April 23rd, 2018
Sara describes the process of turning her site into a progressive web app, and has some very kind words to say about my new book:
Jeremy covers literally everything you need to know to write and install your first Service Worker, tweak it to your site’s needs, and then write the Web App Manifest file to complete the offline experience, all in a ridiculously easy to follow style. It doesn’t matter if you’re a designer, a junior developer or an experienced engineer — this book is perfect for anyone who wants to learn about Service Workers and take their Web application to a whole new level.
Too, too kind!
I highly recommend it. I read the book over the course of two days, but it can easily be read in half a day. And as someone who rarely ever reads a book cover to cover (I tend to quit halfway through most books), this says a lot about how good it is.
Sunday, April 22nd, 2018
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.
Tuesday, April 17th, 2018
Two technical editors worked with me on Going Offline.
Jake was one of the tech editors. He literally (co-)wrote the spec on service workers. There ain’t nuthin’ he don’t know about the code involved. His job was to catch any technical inaccuracies in my writing.
I deliberately didn’t wait until I was an expert in this topic before writing Going Offline. I knew that the more familiar I became with the ins-and-outs of getting a service worker up and running, the harder it would be for me to remember what it was like not to know that stuff. I figured the best way to avoid the curse of knowledge would be not to accrue too much of it. But then once I started researching and writing, I inevitably became more au fait with the topic. I had to try to battle against that, trying to keep a beginner’s mind.
My watchword was this great piece of advice from Codebar:
Assume that anyone you’re teaching has no knowledge but infinite intelligence.
It was tricky. I’m still not sure if I managed to pull off the balancing act, although early reports are very, very encouraging. You’ll be able to judge for yourself soon enough. The book is shipping at the start of next week. Get your order in now.
Monday, April 16th, 2018
Lesson learned: the discoverable and understandable web is still do-able — it’s there waiting to be discovered. It just needs some commitment from the people who make websites.
Sunday, April 15th, 2018
The audience for Going Offline
I didn’t want to overwhelm the reader with lots of code up front, so I’ve tried to dole it out in manageable chunks. The amount of code ramps up a little bit in each chapter until it peaks in chapter five. After that, it ramps down a bit with each subsequent chapter.
This tweet perfectly encapsulates the audience I had in mind for the book:
I pre-ordered it, and I’m excited about it. I’ve been curious about service workers for a long time, but have been nervous about actually writing one.— Matthew J Derocher (@mjamesderocher) April 13, 2018
Some people have received advance copies of the PDF, and I’m very happy with the feedback I’m getting.
Seriously applauding the author for explaining how to run a local server in passing, in like 3 lines.— Lívia De Paula Labate (@livlab) April 5, 2018
People do not understand how this is a massive barrier to designers who are interested but don’t know how/are new to coding.
Here I am all self-congratulatory “yes, yes, I am understanding service workers much now…”— Lívia De Paula Labate (@livlab) April 6, 2018
How is this happening: it did not tell me upfront I needed to learn it, it did not even tell me it was going to teach me.— Lívia De Paula Labate (@livlab) April 6, 2018
Ok, I’m done reading @adactio’s Going Offline book and as my wife would say, it’s the bomb dot com.— Lívia De Paula Labate (@livlab) April 15, 2018
You can check the thread above for some impressions, but definitely read it. It is a _very_ gentle introduction to technology we are going to use A LOT.
Honestly, that is so, so gratifying to hear!
Words cannot express how delighted I am with Sara’s reaction:
Today I finished reading @adactio ’s new book: Going Offline. As someone who rarely ever reads a book cover to cover, this alone says a lot about how good the book is.— Sara Soueidan (@SaraSoueidan) April 13, 2018
It is *so* good. So, so good. I cannot recommend it enough: abookapart.com/products/going-offline
I’ll tweet about this in time, but for now: THANK YOU for a WONDERFUL book. I can’t believe how approachable you made SWs with your writing style. I’d recommend it to everyone in a heart beat.— Sara Soueidan (@SaraSoueidan) April 12, 2018
She’s walking the walk too:
I’m expecting weird or inconsistent behavior / bugs at this point (still need to test!) BUT I can finally say that sarasoueidan.com is now officially a Progressive Web App. 🎉— Sara Soueidan (@SaraSoueidan) April 13, 2018
✅ HTTPS (long ago)
✅ Service Worker (since yesterday)
✅ Manifest (added today)
That gives me a warm fuzzy glow!
If you’ve been nervous about service workers, but you’ve always wanted to turn your site into a progressive web app, you should get a copy of this book.
A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.
Wednesday, April 11th, 2018
The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.
Tuesday, April 10th, 2018
It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!
In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.
Friday, April 6th, 2018
In the past, when I brushed off new advances or updates to technology and processes I preferred to stick with a simple path of “it still works fine,” but in doing so I realize now that I have l lost a lot beginning with the ability to function with current best practices in certain areas of my skill sets and the degradation a few projects, especially Airbag.
An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.
It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:
- CSS grid,
- variable fonts, and
- service workers.
From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”
My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.
I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.
Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.