Earlier quoted context omitted.
And what about the front end? What's the best, most boring choice there? I was on a project for a bit using React and although it felt like an obvious way to write things, I can't help but feel you can't create something that will last for a decade with it.
You absolutely can. React is the gold standard right now. It's already been king for 6 years and it's not going anywhere. The hype for angular died down. The hype for vue has started to die down. This little bit of hype svelte has at the moment will die down. React does have a ton of problems but they all come from the next level of dependencies down. Shit like Gatsby and Nextjs won't pass the test of time. Neither w…
Choose Boring Technology (2015)
181–190 of 374 posts
Re: Choose Boring Technology (2015)
#182Earlier quoted context omitted.
I think it's helpful if it brings awareness to the situation. I've spoken with 70+ different devs working on 70+ different projects of all sizes on my Running in Production podcast[0] and the choose boring tech phrase came up a whole bunch of times, and especially the idea of using innovation tokens. If it helps folks build and ship their app in a quick and stable way, that seems like a big win to me. [0]: https://ru…
It must have been a weird coincidence but I listened to a few episodes for your podcast and I've actually heard about boring technology in 100% of episodes I listened to
Re: Choose Boring Technology (2015)
#183Earlier quoted context omitted.
and Java?
The Java community has some great developers, but also a lot of Serious Software Engineers who will sabotage everything with extra complexity, and then everyone who learned Java in school and never felt like looking at another language (not even Kotlin). Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.
Re: Choose Boring Technology (2015)
#184Earlier quoted context omitted.
How much experience do you have working with JS?
I have been writing it full time about 13 years. I love writing in this language, and TypeScript even more. I am just frustrated by what appears to be some combination of insecurity, false expertise, and a vehement lack of passion in the work force. If I want to be happy I should move on to a different technology stack, but I really enjoy making products in this language.
Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff.
IME all the same people that overengineer everything with god awful dependencies are the same ones pushing super hard for typescript on every project I'm on. When they get their way (as always, since everything is decided democratically and everyone is dragged down to the level of the worst dev on the team), they write the worst typescript ever. On my last project, one of the people championing typescript defined some constant strings containing css breakpoints as the type 'string | int'. Rather than getting knocked back as one of the dumbest lines of code in the history of front-end, this somehow generated 3 pages of discussion in code review then got left in. I'd give the person a pass, assuming they'd never used a typed language before, except (a) they were senior and (b) they're the one that wanted types. These "seniors" lack even the most basic understanding of the shit they're using, but feel the need to impose their opinions about libraries, tooling and languages constantly.
I don't feel like I'd mind using TS at all on my personal projects, but on work projects with average devs it just adds another entire layer of complexity that they spend hours and days and weeks and months wrangling with instead of writing any code that might be remotely useful, by say, maybe implementing a business requirement, or doing anything that makes the company money instead of pissing away millions in salaries playing npm lego.
Plus, although I'm not familiar with any of it since I'm never the one pushing for TS, and so never the one setting it up, I've seen people spend absolutely ludicrous amounts of time tinkering with webpack and fussing over TS integration with 3rd party libraries and whatnot.
I'm surprised you haven't run into more of these people that just seem to use TS as a complexity multiplier for every bad engineering decision they make. Like spending 6 months setting up Gatsby or Next isn't costly enough for them, so they decide to tack on 3 months of TS integration and 'upskilling' for 3000 combo points, when they already (more or less, usually less) know how to write Javascript.
Re: Choose Boring Technology (2015)
#185- The slide with the jeep together with the "use boring technologies" slogan paints an interesting picture of the challenges of E-mobility in this century. There are going to be a lot of things no one expected.
- How would you call this style of presentations? Zen-like? One catchy thing per slide? I find it pretty well done, and when I compare it to my own "wall of text" slides, I am a bit jealous.
Re: Choose Boring Technology (2015)
#186Re: Choose Boring Technology (2015)
#187Earlier quoted context omitted.
> How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it? I think there is a tension between this kind of actively guiding anti-complexity management and hiring "top talent". The very best developers are capable, and avoid complexity. The next best…
Also it is almost never for "funsies," it is instead usually the "wrong solution" to a very real problem. The current system has bad performance, or doesn't support some new use case that is a major company initiative or whatever. But instead of fixing/augmenting the existing system the (probably multiple accumulated pain points by now) are used to justify an overly complex change. In fact the change probably becomes…
"for funsies" probably isn't that far off. Because the process is more like someone gets interested in something at some point. Then at that point +~1-6 months someone raises a problem and some senior dev gets stuck on the idea that the awesome thing they read about can solve it. Then before you know it whatever tool they want to use has more bells and whistles than the average mars lander and does everything short of curing cancer.
There's rarely any good correlation between the problem and the solution. That gap can just be bridged by buzzwords. The true correlation is usually between the solution and whatever the most senior dev on the team thinks is shiniest at the moment.
Re: Choose Boring Technology (2015)
#188Re: Choose Boring Technology (2015)
#189I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…
In the case of a lot of tech companies, the entire market is broken and leads to weird incentives rarely seen in any other industry: companies that aren’t profitable, don’t have a real product people pay for, don’t have a clear, plausible path to profitability and yet somehow stay in business because investors are happy to burn money. This completely reverses the typical market dynamics. The company is more focused o…
Re: Choose Boring Technology (2015)
#190So if you want a company that can do all that you are going to need specialists which typically come wielding specialized technologies. You can probably get away with generalists wielding 'boring' technologies for some period of time combined with SaaS solutions but it's hard to avoid the fast-moving increasingly specialized ecosystem forever.