> It would be a mistake to insist that all of those spreadsheets should have started life as something else, just in case maintenance should someday become necessary.
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.
Not the OP, but when I was doing CGI scripts Perl 5 wasn't released yet. And even when it was it took a long while for people and systems to migrate. Quite a bit of the early web apps were written in Perl 4 style.
> CGI scripts went out of fashion for several reasons that fall into the categories "too complex to maintain" or "there's this new thing called PHP...".
This is how I remember it also. Doing CGI "well" was significantly harder. And new ways of making dynamic web content was rapidly coming out.
There were no HTTP server libraries in any languages. All web servers were large codebases. Most of the web sites ran on Apache in multiuser environments. Configuring (and compiling) Apache correctly and securely took a bit of voodoo in those environments.
The security issues with CGI wasn't just injection attacks. How should admins setup safeguards when every user could write a binary/script that remote people could execute? By the time best practices evolved PHP was taking off. And PHP offered a little bit more of a sandbox.
And then... ColdFusion. Java Servlets. JSP. ASP. And many more ways of creating dynamic websites that were often easier, had better libraries tailored to webdev, and included better sandboxing.
Web servers started to become proxies to long running processes and stateful web apps became a thing. For better or worse. (for worse IMHO. :D)
CGI with Go or Rust could be pretty interesting and significantly easier than my first C-based CGI binaries. Mostly because of their extensive web-dev library options and dependency management tools.
The article describes disagreeable people as "selfish, combative, and manipulative." And "Does being disagreeable-that is, behaving in aggressive, selfish, and manipulative ways-help people attain power?"
Which, to me, sounds very different from voicing concerns or identifying problems.
Wow! Lots of memories flooding back. I (Xamot) remember your nickname. E2 was definitely an interesting place, bringing together people from many walks of life. I meet many people, who influenced who I am today. And it is unlikely that I would have met such a range of people otherwise.
It really depends on what those experiences were at the same employer. I'm not the OP and not in the same boat. But I've been at the same employer for more than 30 years.
TL;DL: Feeding pets the animal byproducts of our own food production is not only a good symbiotic relationship, but also contains more of the nutrients the pets need (as opposed to grain-free or other specialty diets). But, the specifics for your pet will vary based on their own needs and allergies.
Wonderful comment. Mirrors a lot of what I've experienced directly or indirectly in the industry.
I'd add that mid-sized and up companies are usually not homogeneous. There are usually good and bad leaders, managers, and developers to be found within them. You can have a great experience in one part of a company and a horrible one in another part.
Another thing that I've found is that there is no "one true way" for a team to operate. I have found that what works best is to lean into a methodology that meets your business partners wants/needs and hire people that work well in that environment in that mode. Be it highly formalized and layer ITIL, super agile kanban+devops, or somewhere in between.
I am a US citizen with a bunch of civil engineer friends who are Professional Engineers (the capital letter, licensed kind). For a good number of years I had a roommate whose job was literally designing bridges. We've talked about this very comparison. Bridge building is not as boring as this author thinks. It can be pretty stressful.
There are a few factors that make bridges very reliable (but not perfect) in the US. A real engineer can probably describe this far better than I can.
1) Physics and material science are pretty well known quantities.
There is innovation and new materials come to market, but by the time they are approved to be used in real bridges their qualities are fairly well known and tested. They have solid evidence of the capabilities of a material or part. (Tensile strength of an item under various environmental conditions, for example).
2) Standards & Very Firm Requirements (Where waterfall works!)
They have a set of strict approved industry standards to rely upon. Not the "industry standard by convention" kind that you see around IT a lot, but the "tested, reviewed, approved, published by a standards body" kind. When a civil engineer is assigned to build a specific bridge they reference these standards that tell them "given this type of ground do this", "given this length of span do that". They know the lengths and widths, they check the traffic patterns, they know the desired weight limits. Challenges do come up, yet they have fewer unknown unknowns. Something changed from their expectations, maybe the ground is different than expected, but they still have standards that guide them in what to do in those cases.
3) Reviews, reviews, reviews.
Other Professional Engineers have to sign off on the work of the initial designer(s). Deep reviews. Not what typically passes for software architecture and code reviews I've seen.
4) Legal responsibility. Professional Engineers have an amount of personal accountability at stake because real lives are at stake if something fails.
5) "User" common sense and intuition
Nobody builds a 100,000 ton vehicle and then tries to drive it over a bridge. Most any human that thought about doing this can probably reason that doing so would break the bridge. In my experience software users have no idea that trying to push a 1TB file into a system that was designed to only handle 1MB files will cause it to fail. They often have no idea when their data volume increases. "I'm doing the same thing I did last month!"
All that and more, yet bridges still go over budget and over time and fail and people die.
When I first started using jq, all of the examples I was following used the short-form. It took me a while to figure out how to use the functions and do some advanced transforms because of this. Since this article is Part 1 of a series I suspect the author will cover this in a later article.
From a teaching perspective it is probably best to start with the long-form.
Similar story for me. Pretty much the only time I am disappointed with Docker Swarm is during monthly host OS patching and the networking gets messed up and we have to restart daemons and undeploy/redeploy stacks.
I would argue that many people try to commoditize developers through scrum (edit: and call it Agile). Agile is just a set of principles. Which pretty much state the opposite, "Individuals and interactions over processes and tools." As the article states, scrum can work in some cases, but doesn't in others. If you keep trying to force it where it doesn't work, you aren't following the agile principles anymore. (edit: I'm probably making a "no true scotsman" augment and should've said something like "If someone keeps trying to force scrum where it isn't working they should reflect on the principles and ask themselves if they are putting processes first".)
I really like this idea and I really like Clojure. Though I'm curious about performance. And do you know if anyone is doing something similar with Racket? (Looks like there is a Common Lisp shell http://www.cliki.net/CLISP-Shell)
I'm another person in their 40s that (tries to) primarily listens to Indie. What are you tips for discovering music?
I primarily am using Pandora and it really depends how much time I spend thumbing music up or down. Once I zero in a station it doesn't seem like I hear new artists or songs very often.
I'll also add that in my personal case, pandora led me to finding and buying more music. Spotify and smartphones over iPods (and buying a house) are why I don't by albums very often anymore.
> ...but then forget that they've now created a copy of their entire system
With persistent data structures you don't have a whole copy of the entire system. The two views of your system share memory where information didn't change. Sort of like how Git works.
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.