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.
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.
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.
It would be neat if there was an option to make input and textarea use the script font as well and an image component that made a sketch of the image provided.
I think it's a great idea if it's done right. I miss freshmeat.net :-)
A database of open source software would help when looking for suitable products, personally I tend to scout for open source options before looking into closed options.
If it contained easily searchable/filterable information on license, "activity" (i.e how alive the project is), hosting/deployment options, development language, operating system, it would be great.
Also if it has info on how it accepts contributions, it'd be nice.
Probably you could scrape I formation from GitHub, gitlab and similar sites and you could also let projects supply information for you in a "oss-info.yaml/json" in the root dir of the project.
For example, in vscode if the sharer start a http-service the port can be port forwarded through the session so anyone in the session can interact with the service.
- 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.