I do not agree fully with this article, but it does give food for thought and have some valid points:
- don't blindly jump into a new architecture because it's cool
- choose wisely the size of your services. It's not binary, and often it makes sense to group responsibilities into larger services.
- microservices have some benefits, moduliths (though not mentioned in the article) and monoliths have theirs. They all also have their set of disadvantages.
- etc
But anyway, the key lesson (which does not seem like a conclusion the author made) is:
Don't put a halt to your product/business development to do technician only work.
I.e if you can't make a technical change while still shipping customer value, that change may not be worth it.
There are of course exceptions, but in general you can manage technical debt, archtectural work, bug fixing, performance improvements, dx improvements, etc, while still shipping new features.
At my last employer Elastic we definitely ran into these limits on the cloud SaaS team moving Elastocsearch node containers from our proprietary orchestration to k8s. I’m not sure how they eventually solved it but I believe the plan was essentially sharding ES clusters to different regional k8s clusters.
Jira used to be self hosted, dunno if they still are, but this space for a self hosted enterprise product is already pretty saturated so you should have lots of options.
Any initiative to make a fast powerful UI is a good one imo.
Some features, like clipboard history and window management (i.e "tabs") are better left to the desktop environment though. Every app shouldn't need to reimplement this logic.
The homepage probably to broaden the audience talks about tabs but as can see in screencasts, in-program, they're called (borrowing from Emacs) buffers. In contrast to tabs, buffers don't belong to a specific window and can switch to one within another window.
I remember only one lecture from university, one in presentation technique.
The idea of the (guest) speaker was that when you hold a presentation, say the most important things first.
If anyone gets up and leaves, or the presentation is cut short, you should've gotten the most possible value out if the time.
Then dig into details as the presentation progresses and answer questions or concerns right away.
Answering right away does not mean side track the whole presentation, give the major response and take details later.
I.e "TL;DR" your presentations, oral or written alike.
A simple example is: you've been given the task of estimating the cost and work involved in developing a new feature.
When you present your result, don't start by listing all the things needed to be done and all the investments needed to be bought.
Start by giving the receiver what's on her mind: what is the price, when can we deliver, how many persons do need.
Then dig into the overall details of how you ended up in that, perhaps that the tools needed to be purchased are X, Y and Z.
Then dig into why we need those tools, and so on.
If you have to interupt early, or if you have a big trust from the receiver, the main point has been delivered and the the remaining 80% of the time can be invested in more important things.
I've applied this in my life, privately and professionally, and it's been working out well. I also hope this response was a good example of what I tried to pass on.
- don't blindly jump into a new architecture because it's cool
- choose wisely the size of your services. It's not binary, and often it makes sense to group responsibilities into larger services.
- microservices have some benefits, moduliths (though not mentioned in the article) and monoliths have theirs. They all also have their set of disadvantages.
- etc
But anyway, the key lesson (which does not seem like a conclusion the author made) is:
Don't put a halt to your product/business development to do technician only work.
I.e if you can't make a technical change while still shipping customer value, that change may not be worth it.
There are of course exceptions, but in general you can manage technical debt, archtectural work, bug fixing, performance improvements, dx improvements, etc, while still shipping new features.