jarl-ragnar

Uses a subscription pricing model though. I wonder why he choose that model. Personally I love the Sublime model, buy a license, use it anywhere.

There’s been a few. For example, the Barons’ revolt that resulted in Magna Carta in 1215 https://en.m.wikipedia.org/wiki/Magna_Carta

Or the Peasants’ Revolt of 1381 https://en.m.wikipedia.org/wiki/Peasants%27_Revolt in part arising out of the aftermath of the Black Death.

This reminds me of my first job developing radar data processing algorithms. Our processing pipeline was similarly a set of c programs linked using unix pipes, each element easy to test and, more importantly, understand. Thanks for sharing and triggering the memories.

This recent Strangeloop talk on 8-bit game development covers some of the tricks used to squeeze performance out of a limited platform https://youtu.be/TPbroUDHG0s

Ableton was one of my Lockdown amusements last year. A few weeks playing around with it resulted in this https://youtu.be/I3XrZOw8ZJA

I found The Art of PostgreSQL a good resource

https://postgresql.thinkific.com/

I know. I was referring to the comment about not feeling represented.

There’s an irony in there somewhere given the original motivation for the “Boston Tea Party”.

No taxation without representation.

This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key.

The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.

As an engineering manager I’ve found that the most innovative and impactful work is usually done when the pressure of being on the critical path for delivery is absent. One way to achieve this is to do the work under the radar and only expose it more widely once it’s at a point where the benefit is easier for general management to see.

Work on the critical path is visible and that, with the fear of the personal impact of failure can drive risk aversion behaviours in those engineers involved.

That's fairly standard. The laptop once purchased becomes an asset on the company accounts and then get's depreciated each year in line with local tax regulations. 3 years is the typical depreciation timeline.

Looks like it’s Ardour DAW https://ardour.org/

I'd suggest ClojureScript, Reagent and re-frame. A solid stack built on functional programming and immutable data structures.

You need never get seduced by a new javascript framework ever again.

Resistance training. And it doesn't need to be endless hours in the gym. Try following @Mangan150 lots of useful stuff.

I'd suggest you explore the world of Stoicism. You could start with https://twitter.com/dailystoic

No point getting angry about things you cannot and never will be able to control. Focus on what you can control and take pride in that.

The Mission Command concept actually stems from the German concept of auftragstaktik which was a contributing factor in their early successes during the Blitzkrieg campaigns early in WW2. See for example https://smallwarsjournal.com/jrnl/art/how-germans-defined-au...

I use uptime robot http://uptimerobot.com for monitoring, they have a free plan or paid if you want faster checks.

If it's truly critical to have no down time then you probably need to build that resilience in to your architecture.

Try this "Mechanisms of lightning formation in deep maritime clouds and hurricanes" [1] It suggests "that the formation of lightning in maritime clouds requires two conditions to be satisfied: a) significant vertical velocities and a large cloud-depth, and b) the existence of small aerosols with the radii lower than about 0.05 μ m in diameter in the cloud condensational nuclei (CCN) size spectra." The pollution from the ships in the form of sulphate will likely provide such small aerosols so then you just need to significant vertical velocities.

[1] - https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

Anyone with a knowledge of atmospheric physics would say this is obvious. You can even detect shipping lanes because of the impact of the aerosols generated by the shipping traffic on the cloud cover compared to the surrounding area.

To me it seemed obviously overhyped. Having worked in the machine learning/AI field back in the 90s all the claimed capabilities of Watson didn't seem credible.

It really happened, bank in the early 90's. Though I imagine it was a common occurrence.

Reminds me of my first job processing radar data on a Masscomp mini-computer. The full processing was a bunch of simple c programs all unix piped together into a processing chain. Simple and elegant.

We appeared to have a persistent bug though, processing left running overnight always seemed to crash. So after a couple of nights I stayed in the lab to try and see what the cause was. At 7:30pm the lab door opened and in walked the cleaner who reached down and unplugged the computer so that he could plug in the vacuum cleaner. Problem solved.

I was astounded to watch in one organisation while the Software Eng. Manager talked in terms of sprint failure and turned it into a performance issue. That resulted in all sort of unintended consequences.

I've used a Lumie Bodyclock Starter 30 as my alarm clock for over 10 years. It's completely transformed my morning. Stick it on a bedside table and its alarm function simulates a sunrise over 30 minutes.

I have a much simpler way of dealing with meetings. If I'm sent a meeting request and there's no agenda or clear reason for my attendance I decline it.

A couple of months doing that in a new job, explaining the rational where necessary, usually sorts the problem out.

All of this reminds me of Channels and Pools in MASCOT

http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Manual-June-1987...

Having been involved in the delivery of a complex distributed software system designed using MASCOT, I can attest to it being instrumental in the creation of one of the most robust pieces of software I've ever seen. Consistently topping the System Prime's quarterly metrics for up-time.

Not a book, but I'd recommend Bill Garcia's Negotiating for Success course. I did it a few years ago and would highly recommend it.

His company website is http://www.tableforce.com/ you can grab some free material from there.

Scrum is just a simplified process for applying some of the principles behind lean manufacturing to software engineering. One of the core principles of lean is - minimize work in progress (WIP). Sprint's are just a way of minimizing WIP.

Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.

A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.

I'm now head of product development at a different company and one of the key activities I instantiated was using internal R&D funding to conduct technical discovery and remove, where possible, software development of new functionality from the critical path of project delivery.

I'm convinced IT project management could learn a lot from civil engineering project management.

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability.

This worked well and was driven by his understanding that most of his effort needed to be focused on identifying and mitigating delivery risk. Most often the key risks lay in trying to estimate the level of effort required to develop key new functionality when all involved had limited prior experience in developing similar functionality. In those cases funding a short time bounded study to explore the technologies involved and figure out the art of the possible reaped huge rewards downstream.

If only all customers were that enlightened!