Tags: developer

45

sparkline

Ooops, I guess we’re full-stack developers now.

Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.

Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.

It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry

7 absolute truths I unlearned as junior developer

This is a wonderfully written post packed with hard-won wisdom.

This are the myths that Monica dispelled for herself:

  1. I’m a senior developer
  2. Everyone writes tests
  3. We’re so far behind everyone else (AKA “tech FOMO”)
  4. Code quality matters most
  5. Everything must be documented!!!!
  6. Technical debt is bad
  7. Seniority means being the best at programming

Defining Productivity — Jeremy Wagner

We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.

I’m a Web Designer - Andy Bell

Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.

I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.

CSS Frameworks Or CSS Grid: What Should I Use For My Project? — Smashing Magazine

Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?

It turns out there are plenty of reasons that people give for using frameworks—whether it’s CSS or JavaScript—but Rachel shares some of my misgivings on this:

In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?

Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.

Why do people decide to use frameworks?

Some sensible answers to this question here…

…of which, exactly zero mention end users.

Breaking the Deadlock Between User Experience and Developer Experience · An A List Apart Article

Yes! Yes! Yes!

Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.

Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.

Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.

This is a great article about evaluating technology.

The “Developer Experience” Bait-and-Switch | Infrequently Noted

JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.

Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

I have a feeling that this will be a very bitter pill for many developers to swallow:

If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.

Oh,captain, my captain!

Tools that cost the poorest users to pay wealthy developers are bunk.

“Designer + Developer Workflow,” an article by Dan Mall

Dan compares the relationship between a designer and developer in the web world to the relationship between an art director and a copywriter in the ad world. He and Brad made a video to demonstrate how they collaborate.

PWA: Progressive Web All-the-things - Tales of a Developer Advocate by Paul Kinlan

Very valuable observations from Paul on his travels, talking to developers and business people about progressive web apps—there’s some confusion out there.

My personal feeling is that everyone is really hung up on the A in PWA: ‘App’. It’s the success and failure of the branding of the concept; ‘App’ is in the name, ‘App’ is in the conscious of many users and businesses and so the associations are quite clear.

I Don’t Believe in Full-Stack Engineering • Robin Rendle

A good ol’ rant from Robin.

HTML and CSS and JavaScript have always been looked down upon by many engineers for their quirks. When they see a confusing and haphazardly implemented API across browsers (HTML/CSS/JS), I see a swarming, writhing, and constantly improving interface that means we can read stuff that was written fifteen years ago and our browsers can still parse it.

Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”

Developer happiness considered harmful (sometimes)

Thoughts on my favourite design principle (because I’m that much of a design principles nerd that I have a favourite).

Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.

Am I a Real Developer?

A Voight-Kampff machine for uncovering infiltrators in the ranks.

Amber Wilson: What Am I Looking For?

If you’re looking for a Brighton-based junior developer, you should snap up Amber right now!

SA Labs | Just a Developer

I like this distinction between coders and developers.

The Coder is characterized by his proficiency in a narrow range of chosen skills.

By contrast the Developer’s single greatest skill is in being an applied learner.

I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):

Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.

I prefer Charlie’s framing. It’s not about speed, it’s about priorities:

I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.

Mozilla Developer Roadshow - Singapore - YouTube

I had the honour of being invited along to kick off the first leg of Mozilla’s Developer Roadshow in Singapore.

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.

So You Want To Be a Senior Developer? | CSS-Tricks

I like Chris’s list of criteria for the nebulous role of senior developer:

  • A senior front end developer has experience.
  • A senior front-end developer has a track record of good judgment.
  • A senior developer has positive impact beyond the code.
  • A senior developer is helpful, not all-knowing.
  • A senior front-end developer is a force multiplier.

The Amazing Women of CSS

Rachel lists some of the best CSS developers working on the web today:

You Might Not Need JavaScript

Una has put together a nice collection of patterns that use CSS for interactions. JavaScript would certainly be more suitable for many of these, but they still provide some great ideas for robust fallbacks.