I love the way that Amber is documenting her journey—I think this is so useful for others making the progression from junior to mid-level developer.
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
This is a wonderfully written post packed with hard-won wisdom.
This are the myths that Monica dispelled for herself:
- I’m a senior developer
- Everyone writes tests
- We’re so far behind everyone else (AKA “tech FOMO”)
- Code quality matters most
- Everything must be documented!!!!
- Technical debt is bad
- Seniority means being the best at programming
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.
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”.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
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.
Some sensible answers to this question here…
…of which, exactly zero mention end users.
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.
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.
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.
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.
A good ol’ rant from Robin.
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 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.
A Voight-Kampff machine for uncovering infiltrators in the ranks.
If you’re looking for a Brighton-based junior developer, you should snap up Amber right now!
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.
I had the honour of being invited along to kick off the first leg of Mozilla’s Developer Roadshow in Singapore.
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.
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.