Almost gave me a sinking feeling:

> If you behave that way you miss out on the part of the curve that we call “mastery.” That’s a state to the right on this curve, where there are still problems. Everything still sucks but it feels manageable.

> The grim paradox of this law of software is that you should probably be using the tool that you hate the most. You hate it because you know the most about it.

If you hire people that are more interested in solving the problem, then they are the tech ... the problem goes away.

Using some 'fancy, risk new thing' has utterly no appeal to someone trying to do XYZ by a certain time with a certain quality.

This is one of the biggest dissonances between Eng. and many business roles.

I've personally gone through the 'perspective shift' over my career, and I don't want to look at my younger self as desperately naive, but really it looks that way from a business perspective.

Even doing Engineering now, I generally could care less about the tech, and that makes you think very differently about it. I almost cringe the moment someone brings up something weird. The risk is of course being the 'crusty naysayer' but in most cases, it makes sense. New Tech is still in R&D, unless there is something very specifically and overwhelmingly advantageous to that tech with regards to your business, it's just a risk. To Zoom ... Mongo, Rust and Scala probably are not there yet in terms of the obvious advantages, whereas a new video codec might might meet the threshold of 'we have to look at this'.

Interestingly, this kind of boring can be measured. On the other hand, the kinds of things that one finds fun is idiosyncratic and subjective. I think it's an important distinction: we can argue about "boringness" with data, but a discussion of "exciting" software is much more like a discussion of personal tastes.

Take Elm for example, it's a highly reliable system for building front-end web apps, so in that sense it's very boring (in a good way!) but whether or not you find it exotic or exciting has a lot to do with your personal experience with Functional languages and such. To some people Elm seems like a toy, while to others it's a strange new world.

By a tool, i mean, we still use boring algorithms (which exist long before the tech is born to adapt it efficiently).

So, boring tech or not, it's not the point, as long as it serve your purpose.

I’ve noticed that the very same ilk of leadership/managers who would balk at the complexity of adding a linter or json schema validation and cite “someday, that would be nice, but for now we’ve got to get quick wins and ship features” would not hesitate to let a golden-boy architect who’s also a drinking buddy add a CQRS microservice written in Go communicating in some hand-rolled bespoke protocol—-just because it wins some folks cool points.

That is basically the inverse of Clarke’s First Law: Any sufficiently understood magic is indistinguishable from boring technology.

[0] https://www.quora.com/Are-Google-software-engineers-really-d...

> I learned a lot. It kept me motivated through hard times with no customers, as I kept saying to myself if this won’t work, at least I’d learn something.

This is where I am at right now. I am trying to moonlight my own learning platform with two kids and a full time job, using a new-to-me technology is what keeps me going. It removes the stress of success because, no matter what, I succeed in some corny kind of way. Both myself and my existing employer get a better version of myself I’m the end.

>I don’t know if this makes sense for fashion or what have you, but I really think there is something to this.

Johny Bravo was conserving his brainpower all along !

I kind of like this idea, will probably try this, jeans + long and short sleeved versions.

- 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.

I did add meanwhile some extra parts on top to improve the development and releasing process, but those parts can be changed and removed at any point and the project would still work as expected.

Isn't this true in many facets of life? Like.... taking a new job... having your first kid... visiting a new city...

Are there processes for engaging in any new experience that enable you to know the outcome is going to be net positive before commencing?

"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.

I was thinking more along the lines of "imagine they are writing a post-mortem after the proposed initiative succeeds". Even if everything goes perfectly, what do we honestly expect to have at the end? A system without problems? Nonsense.

To be fair, engineering-savviness and willingness to be management (especially the kind of management that are legible to investors) are substantially anticorrelated.

The idea is that I am not actually aware of what the final product will look like, when I start, so I take a very careful approach. I spent 27 years, working for a "Waterfall-based" corporation, where the system had to be 100% designed up front, and the end result would "meet spec," while still sucking. I am not particularly thrilled with many agile approaches, either, as I see many of the same problems. It's really just shifting the tech debt around.

My approach actually results in my having to throw away a lot of really good, tested, code, but I still end up moving lightning fast, and coming out with good results. If you look at my portfolio, you will see a whole bunch of small, heavily-tested module projects. Many of these were things that I ripped out of other projects, but didn't want to throw away. Some of them are crazy useful, like the Persistent Prefs Utility[1], or the Generic Swift Toolbox utilities[2], which show up in most of my work. The fact that they are treated as independent projects, with heavy testing, means that I can reuse them with confidence.

The Spinner project[3] was an example of a UI I designed to be a central aspect of an app, then decided not to use it, as it deviated too much from the user workflow I had in mind. It will be back, but not until it's the best approach. Eye candy is nice, but it still needs to be usable.

That modular approach is not new at all. I think I may have been doing it since the early nineties.

True, there is flexibility, but that flexibility is implemented as a single-point hinge, not a bendable continuum. It's very clear where the flexibility goes, and that point is well-tested. I just got done refactoring the server, where I added a more flexible way of allowing users to implement security postures, and I'm really, really glad that I did things the way that I did. It was a pretty big job, adding personal tokens (the new functionality), but a lot of the work was making sure that I stuck with the "philosophical" domains of each layer, and testing the living bejeezus out of the code.

And each point of flexibility has a very clear domain. For example, the ANDISIOL layer is where the SQL turns into functions. You can rip out everything below that, and replace it with whatever you like, as long as the same functional API is presented to BASALT. That's a fairly classic pattern.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

[1] https://riftvalleysoftware.com/work/open-source-projects/#RV...

[2] https://riftvalleysoftware.com/work/open-source-projects/#to...

[3] https://riftvalleysoftware.com/work/open-source-projects/#RV...

At the end of the day there are not large enough differences between say ruby and python to justify different teams choosing ruby or python at the same (medium-sized) company. If you have this level of difference, you've effectively permanently engrained conway's law into your organization.

I set it up, so that all the security stuff was sequestered into its own "silo." This allows things like using monitoring and logging, or a hardened host, without affecting the main datastore.

The deal is, is that I expect the tech to get swapped out, down the line, for something more modern, and it might not even use SQL. But security is quite important (especially with the target user base of the initial release). I went kind of overboard with some structural support for security. I am quite aware that I could get better performance from a single, related DB, but I wanted to start off with an infrastructure-level support for security, with the anticipation of future tech making up for any performance issues.

In my experience, security is often spackled on, after the fact, and I think that it's important to start from scratch, with security.

Also, note the ridiculous simplicity of the DB schemas. That was because I used...yecchhh object-oriented design as the Model, and the datastore actually represents a generic base class state. This allowed me to write a whole bunch of code, early on, and test it, then never have to look at it again. The implementation was done in layers, over a period of seven months. Each layer was treated as a standalone project, with its own lifecycle and testing. The idea was to develop a robust structure that I could consider reliable, then build on top of that.

It worked fairly well.

Erlang (and more broadly OTP), however, definitely qualifies IMO, at least depending on point of view. And given that Elixir is just an alternate language targeting OTP on Erlang's VM, there ain't much stopping folks from treating it as exactly that (and sticking with things like Yaws and Mnesia/CouchDB instead of the latest Phoenix hotness).

But looking at what it actually is, it's a layer over the much older underlying technology, which is Erlang, once you look at the frameworks used, they are basically implementations of things we consider old approaches, despite including new features. Some examples:

- Phoenix - it's a MVC framework, it's not much different from any MVC framework except it doesn't have the "model". You can entirely use it in that "boring" CRUD app way and it will be a great choice. It's performant and has a templating system for HTML, a plug system that looks like middlewares. But if you need to use web sockets without ceremony or want to try something shiny like live views, you can as well. You're not forced to though and you don't need to use nodejs for your js either (as an example)

- Ecto - It looks like an ORM but isn't an ORM, it's default choice for database is Postgresql. It's a library that mimics SQL itself (the helpers and the way you use it are as they would be used in SQL but designed to be chain able and sanitised), it also has easy ways of executing SQL while still sanitising it and also of writing raw SQL. So, pretty boring in all senses except the slight change in syntax to write the queries in elixir. This means for instance a distinct clause would be distinct(query, [table_mentioned_in_query], asc: table_mentioned_in_query.platform) This is not written as sql, but it maps to sql one to one. It uses schemas which are just that, schemas that map how values are dumped and cast from the DB, they're not models/objects, they're just data structures. But if you want to get fancy it also has embedded schemas if you want to use jsonb for instance, that allow you to use jsonb columns while still maintaining a "typed" schema from dump to read.

What may look a bit alien is perhaps the access to OTP libraries that Erlang offers, the way the VM works and certain abilities that come from the way you will structure an app, but even those when we think about them, it's basically what any OS does, or the way kernels work. You have processes, they have identifiers, you can name them, you can run a lot of them concurrently, they can have separate lifecycle trees/dependencies, they have interfaces, you pass "messages" between them. Maybe what's "new" when you compare it to other languages is that this is not usually available to them but I would argue that most of our systems are implemented exactly in that way because it's the most reasonable outside very specific constraints/needs.

When you use Elixir, Phoenix and Ecto you don't need to use these (or understand them deeply), usually the libraries take care of that for you. You can start as if you were writing a nodejs, rails, .net, python or whatever application. But then if you actually need you have a host of utilities and a runtime that I think is excellent for the kind of things most apps out there need, in a single runtime, and you can take it pretty far before you need to extend the stack and that has value in itself I think.

They pretty much ghosted us soon after that meeting. Though they did not specify that as the reason, it seems most likely that their advisor told them we don't know what we are doing technically.

No argument from me there.

But they were a medium sized company. They were absolutely crushed under the weight of FAANG "best practices" and technology. They lost time rewriting perfectly fine code. They chased the microservice fad. And they lost market share.

It's in the interest of FAANG to maintain this idea of needing k8s, this massive CI pipeline, certain processes, etc. etc. Because it slows down competition. It halts startups. It slows progress. They want to throw as much overhead as possible at smaller companies.

The thing people need to realize is that FAANG are entrenched. They are as risk-adverse as can be. They will happily write unit tests and maintain 100% test coverage and do all of this crap because they are more scared of losing market share than innovation. They are in full defense mode. Google is implementing all manner of protectionism to maintain their ad market, for example. Plus, they have the deep pockets to pull it off. Any company smaller than FAANG will sit there with their wheels spinning.

Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.

> The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors

It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.

Amazing bit of self-justification you have there.

If you want to argue against what the author wrote, by all means. If you intend to argue against a straw man you have concocted out of a three word title, then you will seem a fool.

Just to correct the misinformation, Java has been steadily improving since the Oracle years whether you like or hate oracle — the JVM is an absolute workhorse and new exciting features are underway.

That way the reader can decide for themselves. I'm less inclined to object to hasty responses to discussion points than I am to top level comments, but that's just personal choice.

If you instead use cheaper 3rd party hosting companies, you may have hurdles to growth and future migration cost since those companies do not have many of the certifications required.

From an investor POV, paying a little extra now is often worth it to reduce risk and remove barriers to explosive growth.

This also goes some way to explain the leetcode, "hiring only the best from Stanford/MIT" hiring nonsense for pretty mediocre cookie-cutter products that could be perfectly well executed by couple mid-range developers: your developers' resumes are as much a part of any potential acquihire package as the codebase and user data.

2. It is actually increasingly hard to get an industry wide reputable hosting provider ( Cloud, VPS , Metal or not ) that many investors could agree upon. Just like you said which makes DD harder.

3. Amazon actually offer heavy discount and even lots free credit to startup by accredited VC. Meaning the difference in the first few years is actually tiny. And in your example, if it can be run on $500 budget elsewhere you can bet it will literally be free on AWS from those startup.

There is such a shortage of people that know the basics of programming, that selecting for such l33t skills is out of the question.

The hiring process right now is not about selecting the best, it's about selecting those that pass some low bar.

This is such an important point. For whatever reason it has become ingrained in people's heads that the simplest solution must by reductionist logic be the easiest one. And therefore the easiest solution is the simplest one and it is good to be lazy and just introduce complexity everywhere.

You see this a lot with writing as well. It's very easy to ramble on, it's very hard to concisely convey your point.

If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.

So if that isn't part of the deal, I don't even bother.

IMO this would be a case where if you're dealing with a relational domain and the engineers really don't know SQL you should either (a) rethink your hiring policy or (b) spend one of your innovation tokens in having everyone learn SQL.

(I have to add the inevitable disclaimer that I actually love JS and do not want my words to be misinterpreted as a cheap dig at it)

For SNS, what does it offer that RabbitMQ doesn't? I've always found RMQ to be rock-solid and wouldn't use SNS anyway.

Fuethermore, when a join is desired, the best practice is to implement not just a service that joins the data but maintains it in a table/materialized view of its own, along with a message server such as Kafka. The services responsible for the tables to be joined (customers and orders, for instance) put events on this message bus which the joining service subscribes to in order to know when to update its view. See: https://microservices.io/patterns/data/cqrs.html

And don't get me started on how you do transactions that touch multiple tables in this setup: https://microservices.io/patterns/data/saga.html

I have seen these deployed and advocated as the modern way to write business applications in the wild.

It was a calculated risk. Since the company I was working for, at the time, was never going to use Swift, my "bread and butter" was at no risk, whatsoever. We were a C++ shop. I just started working with it on nights and weekends.

Being a C++ shop, however, we were quite familiar with Lattner and LLVM, so we were aware of his propensity for WIN. That gave me some confidence, going forward. Also, Apple didn't just announce a language. They also announced a full system API, as well as a product roadmap. The API showed they were serious about it. Those don't come in Cracker Jack boxes. They take some serious work and investment.

It was definitely a risk, but I'm a conservative, scarred veteran of many errors in judgment (can you say "OpenDoc"? I knew you could!). I wasn't about to run into a burning dumpster, half-assed, and I thought it was worth it. I knew it would take four or five years to mature, and it has. I tend to play the long game. I learned that, from all those years, working with the Japanese.

Webcomponents in plain JS are also great to not have to deal with JS class/HTML Element binding and lifecycle yourself.

Why not add a bit of Flutter or React for a few features, but for most pages it's going to be an expensive overkill.

The most compelling feature is the guarantee of no runtime exception. It language is pretty stable with glacial release cycle. It also has a ui library called elm-ui which allows to develop ui components without css.

There are lot of posts criticizing Elm of slow release cycle and that the community does not take feedback properly. But atleast for my use-case it does not matter.

I like that the language is very opinionated and just works.

Few plusses for Elm: - Static language - Informative compilation language - Awesome tooling. You just nees to install Elm compiler. No npm required. - < 1s compilation - The Elm Arcitecture(TEA) for ui event handling - Beginner friendly community

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 will redux (it's already pointless) and all the convoluted bullshit like redux-saga. If you learn to build stuff using just react and other basic dependencies (like express on the back end), you'll be in a good position going forward. None of that stuff is going anywhere.

I would definitely consider pointers pretty fundamental if you're a C++ dev.

It is pretty hard to believe that 50% of candidates don't know what a pointer is. I've barely touched C/C++ and still know what pointers are and how they work.

Preact is a good alternative if you have a small app, but the reason it's so small is because it doesn't have a scheduler which might cause issues with larger apps.

I'm stuck on this idea that the best UX is a native app for performance reasons (responsiveness, memory, CPU, battery), aesthetic reasons (assuming your like your native platform) and longevity. On my desktop I often run applications that are a decade or more old. How many web apps rolling out today can sit untouched for the next decade and continue to do useful work?

You can make it work with more maintenance, but you did ask the question what's wrong with it!

1. 10 Things I Regret About Node.js - Ryan Dahl - JSConf EU (https://www.youtube.com/watch?v=M3BM9TB-8yA)

2. Brendan Eich: JavaScript, Firefox, Mozilla, and Brave | Lex Fridman Podcast #160 (https://youtu.be/krB0enBeSiE)

Ok, but that came later and wasn't present in 2014.

> they did a "hard-sell" with Swift

I agree with that. :-)

> "Full System API" is the native frameworks; UIKit, AppKit, WatchKit, etc., as well as things like WebKit and MapKit.

Swift did of course have bridging to Objective-C and the preexisting Objective-C API. I find it strange to equate language bridging with announcing a full system API — an API originally announced around the turn of the century (can't believe I'm using that phrase now). Cocoa-Java, which no longer exists, also had such bridging, as does PyObjC and MacRuby/RubyCocoa. Still, most of the system API to this day are written by Apple in Objective-C.

Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.

Java and .Net are more common in longer-lived, larger projects, or when performance matters.

The default assumption for any production React application is that it will need Redux at some point. It’s much more efficient to start the React project with Redux, than trying to bolt on Redux after React project is underway after a while. Redux Toolkit does make things bit easier.

It’s like how React pretends that JSX is optional, when we all know JSX is requirement in React projects.

Thanks for all the work on Redux and Redux Toolkit.

And a GOOD Java dev will likely leave far more maintainable code than an AVERAGE Python dev.

I mean, in most cases it doesn't really matter what tech you choose as 1. Most products don't really need "massive scale" 2. It's more important to be proficient in the tech you pick rather than it being the "best tech ever". I mean Facebook still uses PHP no?

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.

Things have improved a lot since 2009 however, IMO. There was barely a concept of modularity at that time, the tools (e.g. AMD / requirejs / r.js) were way worse and managing the state of the DOM was a pain, jQuery or otherwise.

Also, Java’s “verbosity” is pretty much only a constant factor, and not even necessarily in terms of LOC, but width. What research also show is the benefits of static typing. Also, I am fairly sure there is some survivorship bias working in the background, where an ugly java version of a complex domain survived because the language’s great observability sort of kicking it into a working spaghetti code state, while other projects died a premature death.

That being said, modern Java is quite terse (var, streams, default interfaces, and now records and pattern matching, etc.).

I expect Template TypeScript and Liquid TypeScript are not far off.

My enthusiasm for it has died, and I enjoy just doing a plain old <script src="myfile.mjs"/> on my own projects.