throwaway0asd

My observations contributing to the frustration:

* Developers believe performance is speed. It isn’t. Performance is a difference in measure between two (or more) competing qualities, the performance gap measured in either duration or frequency.

* Developers will double down on the prior mistake by making anecdotal observations without any forms of measurement and will vehemently argue their position in the form of a logic based value proposition. Example: X must be fast because Y and Z appear fast.

* Developers will further hold their unmeasured position by isolating their observations from how things actually work. Software is a complex system of many instructions. Except for the most trivial of toy scripts nothing executes in isolation. For example developers follow the value proposition that a grain of sand is tiny and weighs little, so therefore does not contribute to the weight or size of the beach. An example is that developers will argue to the death using querySelectors to avoid walking the DOM but in Firefox DOM walking can be as fast as 250000x faster than querySelectorAll, which is indeed significant.

I suspect there exist a variety motives for why developers reason things in this way, but from the outside it looks like a house of cards based upon argument from ignorance fallacies outputting really slow software by really defensive people.

You can’t know what’s faster unless you are measuring things in isolation and making incremental improvements to a bunch of different bottlenecks. For example people love to tell me how fast their framework, their application, or whatever is but it’s clear that these are almost always anecdotal observations that are not measured or compared to anything.

When looking at performance it does not matter how fast something is, which makes anecdotal observations worthless. The only thing that matters is the difference in speed between things compared, the performance gap.

I recommend running the site from an aliased subdomain. This will allow ownership of https certificates with a wildcard to your primary domain and that subdomain can point to the environment that contains your site database or services. You can also have a subdomain that uses production https certifications but resolves to a loopback IP like https://localhost.example.com pointing to 127.0.0.1 and/or a AAAA record pointing to ::1.

My learning from playing CDP and the test automation applications mentioned is that this is way harder (and slower) than test automation should be and it’s a huge pain in the ass for authoring tests. The experience is so bad that it only seems to appeal to professional testers whose jobs depend upon it.

To solve for that I wrote my own test automation solution that does not require remote access to the browser. In my personal application where I use this form of testing I am able to execute about 30 user events per second in the browser. That performance speed is completely dependent upon other performance conditions of your application, hardware, and transmission handling. The test cases are simple data structures defined as TypeScript interfaces in a Node application communicating to the browser over WebSockets. The events are executed by creating a new Event object in the browser and executed with the event’s dispatchEvent property.

When your automation gets really fast (less than 30 seconds for a major test suite) everybody will make use of it including the developers, product owners, and even the business leaders. It becomes a faster way to setup and access various features of a browser application than doing it manually.

I am a JavaScript developer. I am much older than you. It is very much a young persons game, but let me qualify this.

Most people actively programming JavaScript for employment cannot program, at least not to the level considered minimally employable in many lesser popular programming fields. Hiring is structured around this, so much so that employers much make a specific dedicated choice between a risk adverse tool user versus an innovative problem solver focused on product superiority. They will almost certainly choose the former because it’s a safer option. Employers willing to take a risk on developers interested in doing original higher quality work tend to be those that work harder to retain their developers.

So there’s that.

On the other hand I didn’t start programming until I was 28. It didn’t take long to become better than average. Now, a bazillion years later, I can do things now that are vastly superior to what the big companies are putting out. It’s not because I am talented or a child prodigy. It’s because I measure things and make original decisions not based on popularity or some community consensus bullshit.

2. Set ambitious product goals. For example you want to drastically increase speed of transmission handling in your product. This means exploring various different transmission options, such as streamed sockets versus HTTP. You have to measure the difference and pick a winner.

3. Be continuously aware of your learnings. Very quickly you will find that the things you learn, from evidence and measures, differs drastically from popular approaches. These differences build on each other. After applying a few of these learnings in your product it will become both vastly superior to the alternatives on the market and completely unrecognizable to popular approaches for most developers.

Those three steps will impose a critical education path based upon evidence that will provide direction, originality, and constructive feedback. It’s not important that one option is superior to another. What is important is just how superior the better option is, which is something learned from experience and will dictate future learnings.

I taught myself XML Schema a year before my employer at the time involuntarily forced me into programming. From XML Schema I learned a deep appreciation for language modeling, data structures, and relationships as trees.

When I was forced to program in JavaScript, my first language, the first thing I learned was to become very familiar with the DOM. The DOM is the backbone of everything frontend web and with that confidence you can do absolutely anything faster, both execution speed and development time, than most professionals with large frameworks. Understanding the document/page is a data structure of objects each with known relational paths to other nodes is a huge performance capability most people will never learn.

Then I really started to learn the actual language. Functions are everything. They are first class citizens which means they can be used and placed anywhere you can use and place a primitive, which is super expressive and portable. I also learned the advantages of the lexical scope model.

I learned early on that good software is explicit, portable, and highly predictable. If you have to guess at what’s happening when reading the code the code is poorly written. Code has flow control and the more immediately you, as a human, can read and trace that flow control the more durable your software is against defects and much faster to patch defects.

In my experience as a developer the biggest failure I see other developers make is that they never learn about automation. They expect some set of tools or memorized conventions to solve that for them. When the developer side of a software product is automated documentation is more available and up to date, performance is accounted for early on, regression analysis is baked in to warn you at the earliest, and so on.

The last major thing I learned as a developer was to measure things. Developers tend to guess at performance and tend to guess wrong by several orders of magnitude more than 80% of the time. Performance is either measured in duration (time to complete an operation) or frequency (operations per second). High performance is a force multiplier. Faster software features mean faster testing and faster analysis both manual and automated. Frequently waiting on software and page loading induces mental fatigue.

Honestly, not everyone can be good at software, but everyone can learn to write bad software. It’s the difference between administration and problem solving. To be good you need to have a passion for solving problems and improving things. It’s more than putting Lego blocks together. Anybody can snap some blocks together. To be good is more like determining what you need to do to take a car and cut the price in half while simultaneously making it faster than the competition.

If you do want to be good you need to innovate outside of work. If you are waiting for the job to tell you what to write you will be just as average as everyone else and lack the criticality to make more informed decisions about why current practices are crappy. That’s why measuring things is important.

* The primary goal of test automation is to prevent regression. A secondary goal can be performance tuning your product.

* Tests are tech debt, so don’t waste time with any kind of testing that doesn’t immediately save you time in the near term.

* Don’t waste your energy testing code unless you have an extremely good reason. Test the product and let me the product prove the quality of your code. Code is better tested with various forms of static analysis.

* The speed with which an entire test campaign executes determines, more than all other factors combined, when and who executes the tests. If the test campaign takes hours nobody will touch it. Too painful. If it takes 10-30 minutes only your QA will touch it. When it takes less than 30 seconds to execute against a major percentage of all your business cases everybody will execute it several times a day.

Here is how to solve for that: when it comes to measurements always put the product first and the people second.

For example:

* Is the product fast? If so how fast and compared to what baseline? All that matters is the performance difference in numbers.

* Is the product correct? Most of the time shops will measure for correctness of a developers contributions. That is putting people before the product. Instead measure the defects (both quantity and severity) coming out of the product.

* Do you have test automation? The only things that matter with test automation are the quantity of business requirements covered and the speed of execution. If your test automation takes hours to fire up or if it covers almost nothing nobody is going to use it. If the test automation covers more than 80% of the business requirements and executes in less than 2 minutes everybody will use it all the time because failing that costs less than involving other people.

* How long does it take to complete a new feature or solve a defect? If it takes a week you can deliver 5x less than if it takes a day. Simplicity and predictability in the code are major factors here.

* Do design decisions prioritize familiar conventions over evidence? Does your team do something just because it’s the framework way or because it’s a popular way of doing things or do your compare viable options and the one that scores highest?

Taste is how you convey these kinds of things. Most of those things listed above scare the shit out of developers. It takes a special kind of person to impose product measures contrary to the status quo and make the developers empowered for it.

Twitter is a form of low quality information broadcast in that roughly 10% of the active users post anything and the remaining 90% consume it, so at this point its basically just an overpriced RSS feed + friend of a friend logic (FOAF).

Social media is in decline, so building new social media is the last desperate resort of people seeking to broadcast their opinions in a venue they control. If you are like Elon Musk and have made enormous wealth by encouraging people to inflate the value of your stock then control of social media is important especially when your primary value channel is at risk of removal after calling people pedophiles or challenging the SEC. Same for Donald Trump.

For everybody else social media is either a party of deplorables or just a venue for mindless streaming entertainment (TikTok).

Unless you own large advertising media channels in need of eyeballs I would recommending investing all your time and money into that next thing that will replace social media out right.

So, those 7 people are government employees, but the remaining thousands that comprise the entirety of the Federal Reserve system are not.

https://www.stlouisfed.org/in-plain-english/who-owns-the-fed...

1. Learn to use Nodes APIs and don’t rely on NPM packages for most things. For external applications, like databases, rely on the vendor integration package supplied by that application’s vendor.

2. Take error handling seriously and apply it universally and uniformly.

3. Everything else will come down to understanding JavaScript (or TypeScript) and solid principles of architecture.