HN user

torqueTorrent

35 karma
Posts0
Comments32
View on HN
No posts found.

On one hand, there are some things that are simply too complex to attempt implementation with bash a script.

otoh, there are many things that could or even ideally should be kept simple such that a bash script is the best practice, most simple, proven, reliable solution.

It can be useful to keep it simple and try to stay exclusively with HTML-latest + ES-latest + CSS and avoiding external JS libraries as much as possible. Using the latest versions of just the basics (HTML, ES, CSS) can help minimize what only recently required the addition of external JS libraries.

In my experience, this is a new development in the software industry. In the past, the software industry was far more constrained when it comes to talent acquisition. I vividly recall an old-guard software CEO in the mid 1990s lamenting the beginning of the dot-com era: its overwhelming demand for engineers and seemingly skyrocketing staffing costs. I've been in the industry for decades and to me this feels like an effect whereby there is now a massive, seemingly endless stream of candidates for recruiters or companies to choose from. I can only imagine there are many problems that can arise from an environment whereby there are effectively an infinite number of candidates. Analysis paralysis for instance?

In school, we used to learn about the RF service technicians returning with stories of dead birds and other such phantasmagoria in and around the sweet spots of the feedhorn, antenna, transmission line, transmitter or other such sensitive areas of high power microwave operations.

Professor also admonished us that such technicians must always be infinitely certain that the transmitter is not operational at the time of service.

Alas, the 21st century provides the opportunity to address the growing scourge of using sounds or combinations of letters that communicate meaning without being divisible into smaller units capable of independent use.

"When you're holding a hammer, everything looks like a nail."

There is a tendency for mgmt to sign up engineers to a vision quest with pre-established non-negotiable requirements whereby the customer expects what would be tantamount to solving all the world's problems in one easy to use, intuitive SPA that 'just works, always'. This is a big factor in the endless new framework releases, mutually-exclusive complexities and vulnerabilities.

TFA said they wanted to account for parking spaces where people had vacated their parking space before their paid time was up.

That would be like McDonalds digging through the trash to account for the uneaten food.

I wonder where this kind of accounting goes on the balance sheet? Maybe part of the Richard Pryor fund?

Even after Tim Cook said none of his best people have the obsolete degrees everyone covets, the focus and priorities of software interviews is perpetually: "please tell me your LinkedIn profile?" or "what was your college degree in, again?" as opposed to "oh you have precisely all the mad skilz to remake the world in Linus's image".

The discoveries through big-data analysis and visualizations can be endlessly counter-intuitive, mindblowingly unpredictable but also dynamic and powerful, even visceral when you have massively voluminous data that can be fed into systems like Tableau where you can actively tweak data queries, aggregations, transformations and visualization types.

The result can often be something akin to: "wow, who could have ever predicted that this data would extrapolate out to show such a unique visualization or trend"

In my career I've experienced alot of engineers that had a desire to shy away from command line or command prompt tools, shell, CMD.exe, batch, scripting, cron and related 'traditional' automation, in favor of GUI, IDE, html, browser etc.

I've even had some young sexy angular-wizard type engineers that had the ear of mgmt sarcastically respond with statements like "I don't do command line".

This article and my experience with AWS development and Amazon leads me to believe this entire company is led and staffed by such engineers.

I agree wholeheartedly and routinely run concurrent intensive smoke tests on real-world HW as well as smoke tests on finely-modeled virtualized environments.

Even with the best modeling and virtualization, a true and thorough, 100% 1:1 approximation with the real world at runtime can likely never be attained for a myriad of reasons.

However, when lives are on the line, this gap must be closed in some manner so as to provide a greater degree of confidence.

Even the most thirsty organizations with lesser consequences for their failures are usually conservative enough and risk-averse enough to know better than to release without thorough (and relatively inexpensive) testing.

My old boss used to tell stories about back in the mainframe days whereby he would send customers fancy, branded and shrink-wrapped finished-product but containing blank tapes for the latest release in order to buy a couple of weeks of extra dev time if he thought the software wasn't ready to escape.

It used to be that part of the unwritten contract of the 'Golden Rule' in our culture was a recognition that adults have access to things that are dangerous or that could deprive each other of life, liberty, property etc, and that therefore these implements must be handled with care such that bad outcomes do not occur for anyone.

The free market has seemingly granted a reprieve from such unwritten contracts and any form of conscience and now allow all implements to be systematically leveraged in the favor of investors seeking returns.