nihil75

Thanks! appreciate your input and perspective.

Are Facts used in the the Fleng fizzbuzz example?

You're probably right - I'm sure this has more features coming from Logic programming, And I'm just too hung-up on the Concurrent part of the title.

I don't get it. How is this different than starting new threads?

In the article example, it doesn't look like anything is returned from each parallel function call. the main loop just invokes the func for each I, and they print when done. No shared memory, no scheduling or ordering.. what's the advantage here?

In code examples, seems shared memory & scheduling are not a thing either. More like functional or chain programming - a function calls next func and passes output to it. Each loop runs independently, asynchronously from others. Reminds me of ECS model in gamedev.

That's great and all, but it doesn't solve or simplify intricacies of parallel programming so much as it circumnavigates them, right?

Is the advantage it being low-level and small?

I think the same "concept" can be done in Bash: ```for i in $(seq 1 100); do fizzbuzz $i & ; done```

Outside/above it, but he's present in Refinement meetings of multiple scrum teams (as per SAFe Agile).

Now I want to be devils advocate and give you the "corporate" perspective -

You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?

Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.

From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.

This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.

This is also a way of looking at things...

Oh and standups are not that bad!

We keep it small, team level (6 people), and they last 15 minutes.

No pressure to describe anything - you can say "I'm still working on that thing" and that's that..

Honestly it's more of a social thing, especially while remoting, and a chance to share thoughts and offer assistane.

Yes, it's working for us, but not without cost.

It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).

It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)

However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).

As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.

Actually, this is the aftershock of GTA 1 being released in 1997. They're finally ripe!

A little disappointing actually! I thought the pattern was a clever way to capture the status of the parachute in the event of failure, so if all they got was a garbled low-res image before the lander crashed to the surface they could deduce which section failed. Alas, it was just an easter-egg..

Thanks! I mentioned Synergy as I've used it many years ago and was not aware of license change implications (that's why I linked to the open-source repo). Good to know there's a good fork.

That company is on a downward spiral...

Yea, it's meant to be a waste of your time.

More accurately, if you need to learn new things to complete it - it will be very time consuming.

Someone experienced, or that uses relevant tech/skills on a daily basis should complete it in less than the time allotted.

Therefore "homework" coding challenges are useful for discerning if a candidate has relevant, current experience.

See the article on college professor solving a 30+ of CS problems in one day.

Whiteboard challenges, on the other hand, evaluate a candidates thinking process & presentation skills.

Whiteboard challenges