RaftPeople

It's almost something you would see on Silicon Valley:

The new upstart CEO taking on Hooli and making those comments ("bullshit and loser thinking")

Gavin Belson get's wind of it and out of fear implements their new AI policy: "Straight to Ship". Anything the engineers can think of just gets generated and immediately deployed with auto-marketing (with obvious humorous results).

Here's one example:

https://www.google.com/goto?url=CAESbAHrOzAVyZ7APar4z2OEdFu0...

"Taken together, these two complementary lines of evidence provide a clear answer to the classic question: many aspects of thought engage distinct brain regions from, and do not depend on, language."

> do you have any proofs for these words? I'm working in IT

I definitely see effective use of the tools.

The most common examples are non-tech or semi-tech people solving problems with Claude's help (e.g. create a query that provides X data for the auditors) and only requiring a quick review by the tech team as opposed to the tech team having to do all of the work. The pace has increased and the tech team is less of a bottleneck for some things.

> Care to share what "right architecture" could look like?

I can speak about ANSI X12 because I've used it (North America), haven't used EDIFACT (non-North America):

Each document type, like a PO or Invoice has a defined structure (by the standards group) which is conceptually nested/hierarchical but physically stored as a combination of tags at the line level combined with delimited elements within a line.

Traditionally the raw data would be pass through a translator tool that converted it into it's hierarchal structure and a person could define a mapping from that structure to their internal systems data structure.

With the internet and XML and JSON, many people/companies weren't aware of the standards and didn't have an EDI translator, so they just winged it and extracted what they needed from the raw data.

There is still a large volume of EDI based data movement and it will probably live for a long time due to cost to change plus having standard document definitions across companies reduces the level of effort to connect many partners to many other partners (it basically reduces the transformations down to a conversation about which things each company does uniquely in the document as opposed to starting from scratch with a completely custom document for every company).

That's awesome, I know that initial feeling of being able to create and seeming like the sky is the limit.

I used to watch the workers at Radio Shack play Attack Force on the Model III and once I could afford a CoCo I learned how to make games by making that one.

Ditka

I don't think we should even be talking about the software factory anymore.

For home stuff I've shifted to a software day spa

But for work, I've gone a step further and now run a software CPG distribution center combined with a software recycling plant.

The code flows out of the DC, gets consumed by the business and then tossed back to the recycling plant, fully green from a 1's and 0's perspective.

Once in a while I had a little fun with this type of thing, back when it was just starting to become a thing:

"Can I have your phone number?"

"I'll trade you, you give me the CEO's phone number and I will give you my number. I may want to call him/her to check on deals or if I have problems with the product."

But generally I just politely say "No thanks"

> we came from lotus notes

in a DeLorean?

In addition to your example, there has been a pretty continuous supply of "predictions" that Einstein made that later proved correct when experiments were run.

> I don't actually believe that you can stack the dishwasher wrong as such

I read our dishwashers manual and was surprised at the significant amount of detail about how to position silverware for optimal cleaning (e.g. where to place small spoons, where to place forks, where to place large spoons, etc.)

Some thoughts:

1-We do have machinery that performs a resolution of next action/thought/belief (based on external input, current state, etc.) and we possibly just sense that action as "choice"

2-It seems pretty unlikely that the resolution process could be cleanly deterministic and repeatable given quantum stuff, meaning some step in the resolution process hovering on the edge of two options could go either way depending on the brain's electromagnetic soup's current state.

3-Our emotions are critical for our survival, driving choices that help us short and long term, and it seems that one of those core drivers is a sense of agency. Even if we don't have free will in the magic sense of causing electrons (or whatever) to suddenly turn left to support or choice, it would still be critical for us to have a sense that our actions and efforts all matter, so those feelings are probably built into the system.

Note: This assumes there is no special magic somewhere that defies our current understanding of the universe and it just hasn't been figured out yet.

Your analysis is exactly correct.

1D barcode is like CSV, it's not going away, it's too simple/useful/cheap.

> You were the exception.

I was really surprised by the article, I assumed it was going to be the same as my experience which was amazement at having the ability to write instructions that caused the system to do stuff, like make dumb games initially in basic and then better games in assembly.

I've listened to the noise on local TV news where they went to the location (here's a youtube link: https://www.youtube.com/watch?v=9wDr2dec474)

I would put the noise in the "fact" column.

> Some of the least comprehensible functions I’ve deciphered had quite low cyclomatic complexities.

In agreement with your post, this research that measures cognitive load via EEG and time spent shows that the metrics we use for complexity and readability are only partial matches to what is going on: https://pmc.ncbi.nlm.nih.gov/articles/PMC9942489/

I was thinking in terms of a broad usage of "design" which tends to match what you wrote about architecture.

> I've never experienced a situation where a software design document meaningfully improved the overall process.

If you don't have a document, then how do you make sure that internal team A and internal team B and internal team C and external vendor D and external vendor E all create the correct things so the entire system actually works?

Reminds me of SNL Happy Fun Ball:

"Announcer: Yes, it’s Happy Fun Ball! The toy sensation that’ssweeping the

nation! Only $14.95 at participating stores! Get one today!

Warning: Pregnant women, the elderly, and children under 10 should

avoid prolonged exposure to Happy Fun Ball.

Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds.

Happy Fun Ball contains a liquid core, which, if exposed due to rupture,should

not be touched, inhaled, or looked at.

Do not use Happy Fun Ball on concrete.

Discontinue use of Happy Fun Ball if any of the following occurs:

itching

vertigo

dizziness

tingling in extremities

loss of balance or coordination

slurred speech

temporary blindness

profuse sweating

or heart palpitations.

If Happy Fun Ball begins to smoke, get away immediately. Seek shelterand cover head.

Happy Fun Ball may stick to certain types of skin.

When not in use, Happy Fun Ball should be returned to its special containerand kept under

refrigeration. Failure to do so relieves the makers of HappyFun Ball, Wacky Products

Incorporated, and its parent company, GlobalChemical Unlimited, of any and all liability.

Ingredients of Happy Fun Ball include an unknown glowing green substancewhich fell to

Earth, presumably from outer space.

Happy Fun Ball has been shipped to our troops in Saudi Arabia and is beingdropped by our

warplanes on Iraq.

Do not taunt Happy Fun Ball.

Happy Fun Ball comes with a lifetime warranty."

I've reverted to an actual paper notepad.

> nothing was fixed

The issue was determined to be a documentation issue and was assigned to that group to add a knowledge base article with additional information.

> like literally too, 20k films at let's say 30m average is 400+ continuous, unbroken days worth of content

You could run them in parallel, like a Zoom or Teams mtg, but with each square a different movie.

Would be more entertaining than the next status mtg.

I don't think you can learn without doing the actual work where normal constraints apply so you can test and see the pros and cons of different approaches to different aspects of the problem(s).

You need a limited budget, limited timeline, limited capabilities in team and software tools+systems, and you need to be on the hook for support, maintenance and long term extensibility.

Software engineering is an optimization problem balancing all of the above and much more. There is no one answer to any problem, but more of a general sweet-ish spot (or more like region than spot) of balancing the competing priorities.

I built a little front end that allows me to group stuff easily so I can visit the site for short durations during the day without having to repeat sorting through items.

I have some checkboxes on articles and a couple manual buttons to trigger movement between groups when I'm ready.

Groups:

New - Not seen by my utility yet

Like Group A - Definitely want to come back to it later (maybe didn't complete, or has interesting comments still active)

Like Group B - Maybe want to come back to it later (maybe it's done, or maybe I'm only partially interested)

Old Group A - Most recent group of links pushed from New - separate from Old Group B to reduce volume of stuff to wade through if I change my mind about something

Old Group B - Older/definitely no longer interested stuff

> In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?

I think a better question is: what is the criteria those countries use to determine if someone can use the engineer title?

In general the software industry is still in an early confused state about standards, approaches, skills, etc.

Should we be using functional techniques? Object? Both? Relational? Column store? Push? Pull? etc.

The number of ways to build a working system is enormous and we have a fad-of-the-month every 5 years which starts as a silver bullet and always settles down to be just another option for another set of use cases.

> It’s well known that the moat of system of record is how difficult it is to extract your data into another system.

I think that is one aspect but not the biggest issue.

The specific shape of data and shape of functionality gets built around for decades due to incompleteness of any system, expanding dependencies and changing business needs.

Decades of building around the system results in a mountain of work when trying to replace the system, typically a larger body of work than implementing the base system itself.

> forecasting-type activities

AI/ML yes, LLM's no (unless someone is naively using LLM's for forecasting)

> The paradigm shift from ETL to ELT is what went wrong with Data Lakes.

It wasn't exactly the shift from ETL to ELT, it was the stated goal of putting "T" on read with no intermediate schema.

In my experience, it's always (since way before data lakes) been a multi-step process and I don't know how it's even possible to do the data lake strategy without re-creating a ton of transforms over and over:

1-Extract

2-Possibly do some transforms early due to specific operational/technical reasons

3-Load - even before "ELT" became a term, load without transform was happening due to constraints, like the transforms requiring data from separate operational systems to even be possible

4-Transform 1 - Foundational stuff like converting unique operational schemas (due to technical or functional reasons) into more natural schemas, easier processing in later steps

5-Transform 2 - Unifying core data that spans multiple operational systems (e.g. order fulfillment txn appears naturally in different systems but for different/overlapping business reasons and with some differences in identifiers and attributes)

6-Transform 3 - First pass at foundational target state

7-Transform 4 - Possibly more, or possibly not

8-Consume valuable data

> See also: DB table normalization.

Pragmatic approach: generally end up with an average of around 2.72 normalization across all tables.

> I would charitably say that it’s a function of a different time and place in programming.

I really think it was just one persons opinion that got published. I started in the 80's and at each software company I worked at they had standard styles that I think we're very clean and organized without being overly dogmatic in any one direction.