i_like_robots

Poor choices whether influenced by this article or engineers chasing CV points are no different. Boring technology is a tool or communication device like any other. I hope in your situation you were able to influence the engineers utilising it poorly to reconsider.

You seem to agree with the lecture/article but disagree with the title.

However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.

I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.

> What if you know NodeJS really well?

Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.

I've seen visualisations similar to this before, but this one is by far the most beautiful and I could watch it all day.

I echo the sentiments on the TfL API, I've built the same Tube Tracker app over and over for more than 10 years[1] as my go-to for learning new tools[2] or testing changes to frameworks[3] and I'm not sure it's ever improved. A chap called Chris Applegate wrote extensively about his battles more than a decade ago[4], did they ever add the stations between Latimer Road and Goldhawk Road on the Hammersmith & City/Circle line?

[1]: https://www.matthinchliffe.dev/2014/03/05/building-robust-we...

[2]: https://svelte-tube-tracker.vercel.app/

[3]: https://github.com/i-like-robots/react-through-time/pulls

[4]: https://web.archive.org/web/20150620042340/http://www.qwghlm...

Firstly, congratulations on launching - it's uncanny timing and similarity to the project I've been building in my 10% time at work!

Here's a screenshot of my own efforts so far: https://github.com/user-attachments/assets/6fac23c3-79ef-4c0...

Very cool - reminded me of https://github.com/creationix/dombuilder which I have... memories of. Shout out too to https://microjs.com/ for allowing me to relive some nostalgia.

Agreed! About 5 or 6 years ago I wrote a library to demonstrate to my teams that JSX a) was not magic b) not limited to React. After that was done I became a little obsessed with making the library the fastest JSX renderer - which I think is still true: https://github.com/i-like-robots/hyperons

Take a look on https://gifcities.org/ - I'm sure you'll find what you're looking for!

Congrats, this looks really nice! I recently finished a side project using Fastify and the Fastify Swagger plugin (which extends the built-in request and response validation and can dynamically generate an Open API definition) which was a good experience overall but the addition of request mocking and the solid documentation site shown here could tempt me to revisit it.

I mostly agree - that was the intention of the caveat - although I don't think there would be too much harm done if somebody started with ES5 then layered ES20xx features or new browser APIs on top as needed.

Perhaps look for web development books published around 2010-2012, before the large JS frameworks gained a major foothold. These will be missing some of the very valuable and useful developments in CSS and JavaScript (e.g. grid layout and promises) but for the other topics much of their content will still be relevant.

There's also the Indie Web wiki which has lots of getting started guides for hosting your own website: https://indieweb.org/Getting_Started

> Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time.

This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way.

To explain further for anyone curious; for TSC to work effectively it must construct and understand the entire "compilation". To do this it starts by performing a glob match (according to your include/exlude rules) to find every TypeScript file within the project. Resolving and type checking the entire compilation every time the bundler calls for a transform on a file is very slow due to lots of repeated and unnecesssary work so most TS bundler plugins have to work around this. Unfortunately, they're still relatively slow so type checking and bundling code separately is often the best way to go.

Like you I tend to agree that the effort delivering front end projects often seems to outweigh the value added over recent years. I can think of half a dozen projects I've seen over the last few years where the effort teams put into figuring out stacks of new tools was an order of magnitude greater than the value added (and most of the projects failed to deliver or became haunted forests soon afterwards which is even worse!) It's not sustainable, businesses are wasting far too much money and too many talented developers are left feeling inadequate.

The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.

With that in mind, my advice would be:

1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)

2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.

3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.

This is how we did it at the FT. We looked at on demand HLS or DASH via our CDN as well but this didn't become a requirement during my time there.

Yes.

Prior to my current company I think I'd only met two candidates face-to-face who had sent misleading CVs (one of whom memorably tried to tell me MooTools was a new Linux based operating system.)

But so far this year I've cut short half a dozen interviews once it became clear the candidate was hopeless, despite having good CVs. In some cases they seemed to struggle to even to use their own computer.

And in the last 12 months we've also cut ties with somebody who joined during lockdown after it became clear that they'd falsified details of their background and experience.

I work four days in my current role and will continue doing so in my next one. I don't have much choice in the matter so I always raise it at the earliest opportunity and have even added it to my CV to make sure I don't waste anybody's time.

I've found the majority of the companies I've spoken to over the last few years (in the UK) have been open to me working 4 days a week but I've also had the frustrating experiencing of being told this isn't an option after interviewing successfully.

At the moment people with my experience are in huge demand so having this leverage must be a big help and I'm happy to take advantage of it while it lasts.

Tell me about it!

"Chickenshit Minimalism - The illusion of simplicity backed by megabytes of cruft."

https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

(The article is also available on my personal site - about 18kb all in - for anybody who would like to read it not on a slow and increasingly walled garden website.)

I'm super pleased to see the FT towards the top of the charts. It's a couple of years since I worked on the project[1] to make it faster and it's really great the team have been able to keep it that way.

We bet on measuring site speed with user centered metrics early on which was going against the grain at the time - removing above the fold CSS, are you crazy!? It took a lot of demos to convince people that what we were doing was faster, and that they really needed to trust their own eyes even when the tools disagreed!

Keep it up, folks.

[1]: https://medium.com/ft-product-technology/designing-a-sustain...

Same, although I'd add it wasn't easy (in the UK.) I found most of the companies I spoke to the last time I was on the job market were open to me working 4 days a week. I made sure to raise my part time status at the earliest opportunity and added it to my CV to make sure I was only interviewing for positions where this could be accommodated.

However, when it eventually came to negotiating after successfully interviewing it was still difficult and I had at least a few companies - to my huge frustration - try to push me into a full time role or even tell me they weren't setup to handle my request yet but would be in future! With the role I eventually accepted I still had to work full-time during my probation period before I could reduce my hours due to limitations with their processes (apparently.)

To help answer the originl question, at my former employer - The Financial Times - a 4 day week was fairly common amongst folks with young children.

Agreed, and there are some innacuracies that could have been corrected with a little research. For example, the description under the Girl logo states "The company doesn’t only make skateboarding products for females, but it has launched skateboards for male skaters." but the company name never had anything to do with products for girls at all.

As an aside, I'd always assumed that the Birdhouse logo is what it is because it's based on the Bauhaus typeface and the names are similar... I'm surprised that's not picked up on here.

My experience is similar. I also "burned out" a couple of USB-C hubs (including a very similar Anker branded unit) so eventually upgraded to a decent monitor with integrated USB-C hub. Being able to switch between all the laptops in our household and my PC with only one cable has been really great. Although, we often find our Apple laptops have problems recognising the connected devices so we have to connect and re-connect a few times to ensure everything is working as it should. No such problems with the PC!

Absolutely, we can always try to assume that our predeccesors or past selves had the best of intentions but nothing beats writing down the context and problems at that moment in time for future reference.

I suppose we can only accurately define a problem when there are no big unknowns, so I wouldn't prescribe readme based development in every scenario - a quick and dirty exploration of the space which can then be scrapped is more important sometimes.

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.

I agree with a lot of the points made by the author (2, 5, 7, and 8 really resonate with me too) but I think this one is my favourite. One strategy I've used which is successful - but not very popular - is "readme based development". The concept is simple, if we're building something new then the first thing we should do is summarise the project in the readme. If we spend time describing the problem and scope of the project and finessing it down to a few sentences before we start coding then we should have a better chance of staying on track and have an easier time communicating with others. The bigger the project the more useful this can be but unfortunately the majority of folks I've worked with do not like writing.

I was a very early adopter of React and I am very grateful for it. It’s now it’s my job to listen carefully to the concerns of my teams and I’ve helped developers of all abilities and experiences through their troubles on all sorts projects over the years. In that time I’m sure I must have discussed all the good and bad things that can be said about React but if I’m honest I’m not hearing as much good nowadays.

I think the part of the reason React has been so successful is because its rules are easily communicated; components which render HTML or composed other components, state lives inside those components and props are passed down between them. How to deconstruct an interface into individual pieces and how data should flow through them really resonated with a lot of people.

But I think the shift to hooks means we’ve have lost the clear rules that made React so accessible to newcomers. Although hooks are still easy to get started with they seem to create confusion easily, and one wrong dependency or deriving state incorrectly and your laptop becomes a heater. This makes it more difficult for developers to focus on what they’re meant to be building because their heads are filled with an uncertain palette of distributed logic.

Now that the tiny API and rapid learning curve seem to have been abandoned I’m starting to think React may no longer designed to help solve the problems me and my teams are being asked to solve and perhaps the reason why hooks aren’t clicking for many people isn’t because they aren’t smart or willing enough, it’s because the mental model required to use React effectively no longer overlaps enough with the things we’re usually building.

This article helped me a lot, it's still a large amount of information to internalise though: https://medium.com/the-guild/under-the-hood-of-reacts-hooks-...

I'm hoping that module federation will enable multiple, separately deployed services to reuse assets so that users moving between those services may do so without redownloading the same things over and over.

We've been able to achieve this to good effect using Webpack 4 with some hackery (https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...) but I'd love to be able to point to something documented and official instead... this sort of looks like it might meet this need. Fingers crossed.

I used to use Perch regularly for the small sites I was building 8-10 years ago. It fit perfectly into my workflow when I was running a one person shop: 1. Design in Photoshop 2. Build the static HTML and CSS 3. Integrate the CMS and deploy. Perch always made the final step so easy and clients liked it, so I was very grateful for it.

I've used grid layout a fair amount in the last 6 months or so. It's very exciting but it can feel quite daunting; the new mechanics and new grammar do not make the spec an easy read.

Fortunately, I've found that it's quite easy to get to grips with - especially if you have been around long enough to have sliced designs into table layouts!

Now for a rather shameless plug for my own article on the subject (I hope with a closer to real world example):

http://maketea.co.uk/2016/09/28/css-grid-layout-is-a-step-ch...

No, not at this stage.

However `display: contents` may help plaster over the gap.

EDIT, reference: http://gridbyexample.com/video/subgrid-display-contents/