Tinned Fruit Missives February 2017


Tinned Fruit Missives February 2017

Hi! Me again with another clutch of vaguely associated links about front-end engineering and anything else that I found interesting in the last month or so.

This month, I’ve noticed a growing trend of front-end specialists marketing themselves as Front End Architects. I can understand that experienced developers might want to separate themselves from the pack, but using Architect as a personal job title has always irked me. This is mostly because of my negative experiences of architects sitting away from delivery teams and making proclamations from afar. A certain well-known UK broadcasting organisation was particularly fond of this approach. The architecture itself never survived its first contact with the developers that were tasked with implementing it. The architects didn’t even seem to mind.

That’s not to say that architecture – as an activity – is not valid. Of course it is, and front-end architecture is a valid part of it. What I have seen work well is where those with more experience and specific expertise help teams to make architectural decisions themselves. Often this is more about communication and facilitation than imparting technical wisdom, though.

Front-end developers have historically had to fight to get involved in system architecture, but now that we are more often accepted as equal members of the team, it seems churlish to try to distinguish ourselves again by giving ourselves exaggerated titles.

Enough of that. On with the linkage.

– Jim


Sacrificial Architecture - Martin Fowler

https://martinfowler.com/bliki/SacrificialArchitecture.html

Somehow I had not previously come across this discussion of disposable architectures by Martin Fowler. I started out in my career working for agencies, and if I had suggested to clients that we ‘create code optimised to be thrown away’, I’m not sure that would have gone down too well as a selling point.

It struck me when reading this that most front-end code should be treated as sacrifical. Lots of things put pressure on front-end code durability: product change, the popularity of lean practices and experimentation, the fluidity of design trends and front-end architectural patterns, and not least the rapid development of browser capabilities. No wonder front-end developers want to change everything every five minutes.

Unfortunately we tend to treat front-end code as if it is more durable than it really is. We can spend far too much time looking to create snapshots of perfection promised by the latest framework. Unfortunately we don’t always optimise for change, but for transient satisfaction of a job well done.

Front-End Developers, Pick Your Battles Wisely - Jay Freestone

http://www.browserlondon.com/blog/2017/01/pick-your-battles

On a similar note, it’s all too easy to focus on the shiny promises of new approaches, tools and frameworks, and to forget why you’re making an improvement.

I’ll just leave this quote from the article here to illustrate the point:

The hardest part of front-end development today is not, despite popular belief, keeping up with modern frameworks and technology. It’s having the discipline to take a step back and assess the real-world value of each new tool for both your users and your team.

Bingo.

Why Every Element of SOLID is Wrong - Dan North

https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong

I’m not a big fan of [X] is wrong or [X] Considered Harmful articles, but this is quite funny and in the form of easily digestible slides from a talk Dan North gave recently.

This appeals to me, because as a psychology student who never got round to properly studying computer science, the SOLID principles confuse me and strike me as arbitrarily obtuse. And ‘write simple code’ is far easier to remember, even if it is annoyingly hard to achieve in practice.

Same same…but different - Bryan Rieger

https://medium.com/@bryanrieger/same-same-but-different-ea8f872a54f

Food for thought, and a welcome challenge to our preconceptions of the web’s place in the world. My day-to-day thinking is mostly constrained by the boundaries of what happens inside the web browser, and it’s healthy to remind ourselves that this mental model is increasingly rare.

Be sure to check out the educational video from 90’s embedded in that article. Get out there and surf!

Join my daily mailing list

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.