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.
CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that.
> More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution
It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today.
> 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.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
> CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that.
It doesn't though. It's very easy to manufacture reasons why "shiny new thing" is the objectively right fit for something, even when it's not.
The word "boring" is well-chosen because it's addressing a bias most engineers have towards the interesting and new. It's a reminder: that fun new tech you really want to try here may not be, probably isn't, the cold-hearted best choice, if you're being practical and business-minded.
On a meta level, this thread shows how rejecting boring leads to bickering.
Our natural default as engineers is to choose exciting tech that invites debate. At scale, across many choices, those debates become drama. For some people, that drama is fun. For most people, that drama is the worst kind of boring. Most people would want to limit that drama by setting a sensible, sane default.
As I see it, the objection to boring-as-default reflects a tolerance for drama that uses "technical" arguments to override business priority. It's a signal that we engineers can't manage our own impulses, let alone our complexity budget, so management has to step in to baby us.
Replacing one bias with another feels silly, I can justify bad decisions just as well either way. Just have real discussions about the technical merits, not that crazy of an idea.
I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
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.
The point is exactly that - bad decisions happen when your reasoning is based on silly terms like "boring" or "hyped" or whatever. The solution is to discuss the merits of each solution as it pertains to the problem space, which "boring" does not help with (and obfuscates).
While it shouldn't be the absolute guide for every technical decision, it helps to have abstractions to capture the intuition and years of experience that goes into choosing a solution. It can make the discussions smoother.
When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
There are scenarios where all that criteria is met but it's still a bad fit. Boring <> Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.
If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
> When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
I'm sorry but it doesn't seem like you've actually read, or at least internalized, the article? These are direct quotes:
> The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
Well understood software directly coincides with support, rollout, and patterns.
I've read it a dozen times at least since it's been released. I don't think you're understanding my criticism. The payoff of the article is and has been that people say "choose boring technology", which is bad. The substance of the article is that "boring" is a valuable proxy word for things that may actually have value, which is a bad thing.
This article is bad. It has led to bad things. It has a bad premise. It has bad ideas.
The correct solution to the problem it wants to address is that engineers should justify technical solutions by mapping product level issues to technical solutions.
What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.
I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.
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?
its incredible the sentiment on TfL API without realising your country even has an API for your public transport. Thats a huge leap in itself, let alone an actively maintained one
Thanks! You're project looks awesome!
I'd be very keen to learn some more about the reason you've been building it, who you are hoping to target with it and plan to do with it if you are :)
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
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.
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.
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.
> 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.
But in theory type checks could be cached too. Why this isn't currently done is because it's probably more work and requires very deep knowledge of the typescript language and parsing. Meanwhile the bundling itself is a simple affair of combining text files together. So these tools instead just fork the typechecker for some minor gain but in practice you could absolutely cache type information. That's what every IDE does with their intellisense database. I think in this thread we are essentially talking back and forth over the current state of bundlers and most here rationalize why it's okay (if not better!) for type checking to be separated from the compilation but the reality is that it's a fairly arbitrary state of affairs. It could easily all be efficient so that type checking is just as parallelized and incremental as bundling and therefore requires no separation into a different process. As we know, after all a binary produced by c++, rust or c# is also a "bundle".
Actually this painfully reminds me why I found it so weird that tsc doesn't simply offer bundling itself. Why wouldn't it? It should be very easy for the compiler to do this as it has all the information and on top of that, tsc also has an incremental mode already. That definitely means 'incremental' for type information.
tsc already has incremental mode, also there's the LSP, the bundler in watch mode could keep a persistent TS language server running. if the typecheck succeeds the bundler emits the new bundle, easy peasy.
If I remember correctly gulp(js) was perfectly able to do this.
but how do you do it? this is not as easy as it may seem. Of course it's possible but the value here is that I don't have to do this for every IDE and/or the LSP when I use webpack where waiting on the typecheck is an integrated feature.
I don't think that's an integrated feature of Webpack, though. It is a feature of TypeScript's own compiler (`tsc`), but that's about it. Nothing about Webpack supports typechecking (or TypeScript) natively.
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.
> 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.