Link tags: team

31

sparkline

Generative AI Is Not Going To Build Your Engineering Team For You - Stack Overflow

People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.

The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.

The origins of the steam engine

The fascinating pre-history of steam power, illustrated with interactive widgets.

Design Engineering - Snook.ca

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

Exploring the future of… Design teams | Clearleft

I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.

There are still some spots available—it’s free to register. The discussion won’t be made public; the Chatham House Rule applies.

I’m looking forward to it! Come along if you’re interested in the future of design teams.

What will the near-future look like for design teams? Join us as we explore how processes, team structures and culture might change as our industry matures and grows.

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.

How to build a bad design system | CSS-Tricks

Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.

Who hurt you, Robin?

We are Oxvik

Ooh, this is an exciting collaboration! Jon and Brian have teamed up to form a lovely little cooperative.

Accessibility for Teams

I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:

Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:

  • Product management
  • Content design
  • UX design
  • Visual design
  • Front-end development

Superfan! — Sacha Judd

The transcript of a talk that is fantastic in every sense.

Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.

Building and maintaining a design system | susan jean robertson

Susan writes about the challenges when trying to get widespread adoption of a design system. Spoiler: the challenges aren’t technical.

Change is hard. Communication and collaboration are absolutely necessary to make a system work. And the more people you can get involved from various disciplines the better chance you have of maintaining your system.

Strong culture = less process – The Man in Blue

For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.

Tips for in-house teams in a free market software culture

A great in-depth report from Alice on creating, running, and most importantly, selling an in-house design system. This makes a great companion piece to her Patterns Day talk.

Where internal teams seem to go wrong is not appreciating that the thing they’re building is still a product and so it needs to compete with other products on the market.

Full-Stack Developers | Brad Frost

In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.

INTERNETARCHIVE.BAK - Archiveteam

The most ambitious project from Archive Team yet: backing up the Internet Archive.

We can do this, people! Moore’s Law and all that.

Let’s Keep Helping Molly Holzschlag

Molly has contributed so much to the web and to the world. This is quite literally the least we can do.

It would really mean a lot to me if you donated to help cover her treatments.

Play Steamshovel Harry, a free online game on Kongregate

Such a classic game, well worth playing again.

▶ 100 Robots - Spaceteam - YouTube

See that helmet? That’s my helmet. Jim borrowed it for this video.

And now I think that the Future Friendly posse has a theme song.

100 Robots - Spaceteam

ARCHIVE TEAM: A Distributed Preservation of Service Attack - YouTube

Jason’s rip-roaring presentation from Defcon last year.

ARCHIVE TEAM: A Distributed Preservation of Service Attack

Starpunk | booktwo.org

James Bridle is my favourite Blogpunk author.