True, but I went with the aggressive tone intentionally while appreciating this concern. For some odd reason when I voice these opinions with more pleasant language the responses are highly hostile 50% of the time. When I use an aggressive tone the responses are rarely hostile (maybe 10% of the time) and more likely to be agreeable. That seems strange to me, but I guess misery loves company. The context of a given thread is likely also a factor.

I have thought about writing my approaches to performance many times. I want to be helpful and share things I have learned, but in the end I always question the value of that time commitment. I have experienced great hostility during my career when violating popular conventions and then doubt the value of my time to commit to writing things that, in the past, have resulted in such hostility.

I have been using TypeScript for almost 6 years and not experienced this problem. Like everything else keep things simple, don’t chase trends, and so long as do right by your product everything will be smooth. I also don’t waste time with large SPA frameworks.

> ii) Libraries are badly documented

I don’t use many dependencies. The DOM and Node type definitions are extremely well documented and inspired me to write better documentation.

> iii) Error messages are hard to follow

For me this depends on the complexity of a given object or type definition. When things are primitive the error messages are more clear. My only suggestion is to keep your interfaces primitive.

> iv) It requires yet more transpilation

I use SWC as a TypeScript stripper. My nearly 50kloc project takes about 2seconds to covert to JS, which pushes out my total build time to about 2.5seconds.

I have 20 years in this industry. It’s full of stupid people pointing fingers somewhere else. Any time this is pointed out developers play the special snowflake game and pretend that software is something special or unique, but it isn’t. Everything is measurable just like any other industry.

That is highly subjective and purely a result of both perspective and bias. While you can point fingers to say that someone is not yet smart enough they are likely pointing a finger back at you and claiming the same.

The only solution for something like Dunning-Kruger is humility. The only solution to find the best solution (objectively) to any criteria is by comparing measurements. The actual problem is that almost nobody measures things, because the effort is too great. Instead most people will compensate for their lack of measures with a hearty dose of confidence.

There are people who sell confidence for a living, such as salesmen and pundits. That is highly appealing to people who lack the necessary critical nature to ask the right questions or apply the smallest amount of doubt.

On the converse my primary programming skills have never been sharper. There is a caveat to this. I feel like I am an expert in what I do, which means I am confident in what I know and what I don't know. It also means there is a lot I have unlearned or intentionally avoided because such practices are anti-patterns or decrease productivity. Some of these things I deem "poor choices" are extremely common conventions which may indicate I am only a beginner from the perspective of a less practiced person who cannot live without such "poor choices".

I believe my programming skills are sharp because I am doing things outside of work that nobody else is doing. I have now reduced my OS GUI to a load time of around 165ms in Edge (130ms in Chrome). I saw a code package from Google on Github on the front page of HN either yesterday or the day before describing a means of file transfer cross-os. My personal JavaScript application has been doing that for years. Soon that personal JavaScript application will have a command terminal that executes in a web browser that works on both the local device and remote computers cross OS.

I once read about this in a book. I cannot remember if that was Blink, Outliers, or Good to Great. Performance follows practice, but the practice must be strenuous, such that you are continuously solving ever more challenging problems. Its the difference between a hobbyist whose skills will degrade over time, a professional whose skills are actively maintained but not advancing, and an expert whose skills continue to increase. As an example most senior developers I have met believe they are awesome because they are doing the same things they were doing 5 or more years ago, but now they are so much faster at it. That isn't awesome, its steady state.

On keyboard events there is a key property which names the keyboard key pressed to result in the event execution. This handler is only looking for the 4 arrow keys and modifying an object assigned to variable inputDir. What’s interesting is that inputDir is reassigned to a baseline on each key press irrespective of the keyboard key.

Objects in JavaScript are what other languages call a hash map, a key/value pair. Key names are always string data types and there is no type or value restriction on object values. This particular object has two keys assigned: x and y. Values are reassigned respectively to an arrow key press.

If you want to be awesome then go be awesome, but you will fail many interviews before you are selected.

* Most people will never voluntarily measure things. Instead people form intuitive assumptions and extrapolate performance and potential from that. This happens all the time for almost everybody.

* Business people need corporate promotions and incentive pay. The best way to achieve such is to pitch a popular idea full of shine and glitter. As an example have you ever participated in a "hack day" event? It does not matter what your final product is (or isn't). What matters is the 2 minute pitch at the end.

1) The inability to consider diverse perspectives

2) The inability to differentiate writing instructions from building something larger

For example many developers cannot imagine the career requirements associated with other careers. That could be due to lack of experience diversity, poor empathy, or weak imagination.

Likewise, many developers cannot write original software. The very idea is frequently both horrifying and disgusting. The alternative is just a little help from a tool or framework, because they write instructions not applications. The interesting part of that is how people respond when confronted about it.

* The DOM is most clearly understood when compared to file systems.

* You can do absolutely everything in the browser 8x faster by substituting web sockets for HTTP

In most of software there is no relation between being a good developer and being either highly valued or highly employable. Being good requires lots of practice solving tough problems. Being highly employable means high familiarity doing average things with tools incapable of solving tough problems.

I cannot imagine commercial software in any form where that is not the prevailing sentiment. I have heard of developers who actually measure things in the capacity of their corporate employment but in 20 years of doing this work I have only seen it once.

As such I don’t even bother mentioning performance or correctness at work (across all my employers) where evidence is so hastily discarded and inconvenient conclusions are a suicide pill.