I don't think a lot of the points in the article hit home for me.
On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.
It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?
In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.
People who 'give a shit' want to do it long term. They want to work on something that will stand the test of time, that they can make meaningful contributions to.
They want to be resourced enough with other workmates that they can be effective at their job without sacrificing their personal life.
The first half of the article is right - but it takes a complete nose dive when the true intent comes out. It's not people who 'give a shit' the writer want. It's people who will chase money as points, and do anything to increase their points. That's who the writer truly wants.
The moral implications are important. That's why it's a marginal rate being proposed in the USA, only on income over 10 million.
Taxing higher rates on much higher income amount is morally better than taxing that same rate on a lower income.
This is because of the impact it has on the earners well being. Income after 10 million has a much lower impact on that persons well being than say, their first 1 million.
Using a publicly funded and regulated government institution? We are a nation of laws, and you don't get to reject laws piecemeal because you just want more money.
I don't know about other companies, but here's a generalised description of officially what a senior software engineer does.
- Relevant tertiary qualification
- min 5 years experience
- long list of proficiency relevant to particular area of work
- Proven ability to take a lead role in the design and development of a feature from start to completion
- Establish technical feasibility of assigned projects
- Uses diagramming appropriately to convey technical details and features
- Create, Document, Maintain technical design approaches
- Mentor other developers
- Lead debugging investigations and report results
- Present results of research and investigation, to team meetings, or at conferences, etc.
+ Everything a normal/jr dev does
I think it's a pretty good/comprehensive definition, and it seems clear enough to me in my work environment.
On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.
It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?
In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.