People and tooling | susan jean robertson
I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.
I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.
Very clever stuff here from Jon in the tradition of Bret Victor—alter Sketch files by directly manipulating code (React, in this case).
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
PPK responds in his typically strident way to posts by Tim and Bastian. I don’t agree with everything here, but I very much agree with this:
It’s not about what works for you. It’s about what works for your users.
If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.
If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.
But it’s worth remembering this caveat too.
PPK writes of modern web development:
Tools don’t solve problems any more, they have become the problem.
I think he’s mostly correct, but I think there is some clarification required.
Web development tools fall into two broad categories:
It’s that second category that contain a tax on the end user. Stop solving problems you don’t yet have.