Link tags: engineering

49

sparkline

Midweight Design Engineer | Clearleft

Want to work with me? If so, come and be a design engineer at Clearleft!

What’s a design engineer? A front-end developer at the front of the front end who values accessibility, performance, and progressive enhancement.

We’re looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production to join our friendly and supportive team in the heart of Brighton.

Even if this isn’t for you, please spread the word …especially to potential candidates who aren’t mediocre middle-aged white dudes (I’ve already got that demographic covered).

Web Browser Engineering

It’s heavy on computer science, but this is a fascinating endeavour. It’s a work-in-progress book that not only describes how browsers work, but invites you to code along too. At the end, you get a minimum viable web browser (and more knowledge than you ever wanted about how browsers work).

As a black box, the browser is either magical or frustrating (depending on whether it is working correctly or not!). But that also make a browser a pretty unusual piece of software, with unique challenges, interesting algorithms, and clever optimizations. Browsers are worth studying for the pure pleasure of it.

See how the sausage is made and make your own sausage!

This book explains, building a basic but complete web browser, from networking to JavaScript, in a thousand lines of Python.

239: New CSS Tricks and Design Engineers | CSS-Tricks

We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.

Design Engineering - Snook.ca

Here’s a seven-year old post by Snook—this design engineer thing is not new.

How to Build Good Software

The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:

  • Reusing good software is easy; it is what allows you to build good things quickly;
  • Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
  • The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:

  1. Start as simple as possible;
  2. Seek out problems and iterate; and
  3. Hire the best engineers you can.

Aegir.org | Canvassing

Strong same:

I’m glad I have this site to play with things, almost all web development and ‘front-end’ stuff leaves me cold these days. It’s all so process driven, so full of unnecessary complexities and dependencies, it’s as if the entire industry wants you to forget you can write HTML by hand and upload it somewhere and it’s a working website. It’s complexity for complexity’s sake, like what accountancy software companies did to the tax code: “Oh this is too complex you need to pay us lots of money to sort it out.” Annoying. I can see some resistance to it and there are still people making blogs and playing around with stuff, so hopefully the professional professionals will calm the fuck down at some point.

The tangled webs we weave - daverupert.com

So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight.

The technologies within technologies that Dave lists here is like emptying a bag of scrabble pieces.

The “modern” web stack really is quite something—we’ve done an amazing job of taking relatively straightforward tasks and making them complicated, over-engineered, and guaranteed to be out of date in no time at all.

The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.

Tolerance | Trys Mudford

Trys ponders home repair projects and Postel’s Law.

As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.

Make me think! – Ralph Ammer

This is about seamful design.

We need to know things better if we want to be better.

It’s also about progressive enhancement.

Highly sophisticated systems work flawlessly, as long as things go as expected.

When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.

Your blog doesn’t need a JavaScript framework /// Iain Bean

If the browser needs to parse 296kb of JavaScript to show a list of blog posts, that’s not Progressive Enhancement, it’s using the wrong tool for the job.

A good explanation of the hydration problem in tools like Gatsby.

JavaScript is a powerful language that can do some incredible things, but it’s incredibly easy to jump to using it too early in development, when you could be using HTML and CSS instead.

Performance, security, and ethics: influencing effectively

I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:

Performance engineers need to be an interesting mix of data-lovers and people-whisperers.

Bandstands: The industry built on Victorian social engineering - BBC News

As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.

Chaos Design: Before the robots take our jobs, can we please get them to help us do some good work?

This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.

So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.

I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:

Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?

BBC World Service - 13 Minutes to the Moon

I’ve been huffduffing every episode of this terrific podcast from Kevin Fong. It features plenty of my favourite Apollo people: Mike Collins, Margaret Hamilton, and Charlie Duke.

Hack the Moon

The history of Apollo’s hardware and software—the technology, the missions, and the people; people like Elaine Denniston and Margaret Hamilton.

(The site is made by Draper, the company founded by Doc Draper, father of inertial navigation.)

How to land on the Moon

Take a tour of the Lunar Module.

The LM (or “LEM”, as it’s pronounced) has the appearance of an aeronautical joke, with not a trace of streamlining. Instead, it’s an insect-like asymmetrical collection of legs, angles, bulges, and surfaces that’s very hard to visualize. Frankly, it looks like it was thrown together on a Friday afternoon by someone in a hurry to go fishing.

Building on Vimeo

Here’s the video of the opening talk I gave at New Adventures earlier this year. I think it’s pretty darn good!

Why Computer Programmers Should Stop Calling Themselves Engineers - The Atlantic

This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:

“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.

Simple & Boring | CSS-Tricks

Let’s take a meandering waltz through what other people have to say about simplicity.

Apollo Presskit Directory

Ah, what a wonderful treasure trove this is! PDF scans of Apollo era press kits from a range of American companies.

Categories include:

  • Official NASA
  • Earth
  • Launch
  • Lunar Module
  • Moon
  • Astronauts
  • Reveal

There’s something so fascinating about the mundane details of Isolation/Quarantine Foods for Apollo 11 Astronauts from Stouffer’s.