throwaway0asd
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 thought of giving up programming many times myself. I love programming, building software applications, and shattering boundaries. I really detest all the self gratifying limitations imposed by autistic cowards.
For example many people tell me software cannot be written without large frameworks. I know this is wrong because I write more ambitious things without a framework telling me how to do it frequently. The most common reason people tell that frameworks are mandatory is because they tried once without a framework and it didn’t work so therefore it cannot be done. It’s the gift of being surrounded by stupidity.
The result is every piece of corporate software requires large frameworks, is bloated/slow, repeats the same mistakes, and finds excuses to point blame elsewhere. The best gift of writing your own software is that there is no one else blame, so instead you are limited to productive decisions improving software.
Here is how I have learned to interpret software competence in the workplace:
* Degree of automation in the process of writing software. The best way to lower risk is to automate the shit out of it. That means aggressive lint checks, explicit data types everywhere, fast test automation, CI/CD, etc.
* Do they measure things, with numbers? People always tell how fast their software is, but typically it’s slow as shit. They have no idea because is a guess with wishful delusions. If I can load a complete GUI with 10+ windows written in JS running in a browser in less than 200ms then why the fuck does your mostly static website take 10+ seconds to load?
* Do they write original software or internal tools? Most of JavaScript is dominated by autistic cowards demonstrating extreme Invented Here Syndrome. Your product can never be better than the swamp of failures of your countless dependencies.
* Do they train people?
These problems advance from failures to nightmares when people become defensive. Defensiveness and pointing fingers is the last refuge of the truly fucked.
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.
* Automation - I am automating the shit out of it. I am automating my documentation, bundling, compilation, and a few other things as much as possible in my build step, which is under 4 seconds. I use TypeScript to type absolutely every declaration. I use TypeScript-ESLint to enforce use of TypeScript declarations and a bunch of custom rules to eliminate known bad practices like "this", bind, call, and apply.
* Framework - What a dirty word. I am not using any of this nonsense. TypeScript is good enough. I have a simple 4 step solution for state management, otherwise I just work directly to the DOM and my current application is an OS GUI. Don't knock it til you try it.
* Performance - You don't know how slow you are until you measure things with numbers. Today I managed to reduce my page load time with state restoration (an OS GUI in the browser) from about 300ms to 192ms by eliminating a CSS reflow and removing 90%+ instances of innerHTML. In the browser the performance tab/graph in the developer tools is fantastic. In Node I prefer to write my own performance tools that typically intertwine with test automation. I eliminated the css reflow by visually hiding all dynamically rendered elements until everything is fully built into the DOM. To dynamically size things vertically I removed some JavaScript arithmetic based upon parent container clientHeight and instead am using CSS min-height:100%.
You have two options: transparency or dark patterns.
A GC bottleneck is encountered when information processing frequency sustainably exceeds processing speed for long enough to encounter a problem. This is extremely unlikely to encounter in real world operation but easily produced during performance stress tests. I have found that I can send web socket messages up to 450,000 per second (on my laptop) with a total message processing frequency of about 60,000 per second. That means I can send messages fast than I can process them on the receiving end, which produces a storage problem. After about 450,000 messages message processing drops to a speed of about 300 per 5 seconds waiting on GC. Since this is a per socket problem I cannot imagine this ever becoming a real world problem. Nonetheless, I don’t suspect Go would have such a bottleneck.
Sounds like corporate software. Software typically doesn’t make money and everyone is aware (except some developers). The business makes money and funds internal software to establish automation which streamlines the business to make money more efficiently. As such automation is the business goal for funding that software. Most corporate developers are not well trained to think in terms of automation. They think in terms of data and code. This is a massive disconnect resulting in wildly different expectations which is compounded through hiring practices and reliance on third party software developers don’t have to write. These things solve for code but fail to address automation in any direct or meaningful way.