h335ian

By the miraculous grace of God, a crack allowed pressure to bleed & enabled our engine company to prevent thermal runaway. A BLEVE was the projected outcome, a firefighters worst nightmare - see the Kingman BLEVE - https://www.cityofkingman.gov/government/departments-a-h/fir...

So disappointed by the irrational and hyperbolic comments from my fellow nerds. Why are folks reading into this so much!? Clearly folks aren’t actually reading the content and just reacting based on a headline. Read, contemplate, compose. This really shouldn’t be an inflammatory exec order - from what I can tell this is precisely within the purview of a POTUS and precisely in line with historical exec orders. Why the cray cray reactions? Just cause Trump I guess. For shame. Be nerds. Look stuff up. Stop with the hyperbolic “fascist” “coup” business. If you disagree with strategy, fine!! But at least recognize that these ideas aren’t new - nor fascistic - they’re inherently American and we’re in the midst of an adjustment cycle where these old ideals will be expressed in new modalities that we don’t all agree with. Doesn’t make it “fascist”. Ugh. So juvenile.

:point_up: this…

The article is purely a marketing piece. As we know with all tech, it’s how you hold it. Yes, you can certainly graph all the entities, activities & relationships - but there is the human tendency towards laziness, least path of resistance and the desire to show “look what I can do” that inevitably leads towards using using weak/garbage data without verification - often in the form of purchases/collected metadata.

Concrete example with a less scary outcome; I was involved in a project for real-estate marketing that used “quality” metadata to infer potential buyers/sellers/properties to target for a given marketing campaign and/or what marketing techniques/campaigns might influence a targeted entity. It was cool. For sure. But, due to the lack of integrity in the data, even with well known & trusted data (direct from the MLS) the result was a graph that made many very weak/inaccurate connections and resulted in a great deal of wasted marketing efforts/cost, targeting the wrong message to the wrong entity at the wrong time. Because it was still a major improvement over other tools in the space, it became the preferred path even with inaccuracies galore.

Now, imagine if the cost of inaccuracies is human freedom - vs wasted cents. Scary stuff.

It’s fair that there are proponents & value props beyond those early folks that came from the Java type world.

I guess I’m tainted/jaded by the early proponents and initial rationale that was absolutely tied to - “ewwww dynamic types!?! Gross, where are my strong/static types!?”. I’ve just fought that too many times - and that was a very strong argument at the inception of TS. There certainly are value props that go beyond and more to be discovered I’m sure.

I feel like MANY if not most of the devs I work with today simply use TS cause “that’s what you do these days” - but they have no clue what the “why” is and are baffled by native JS typing - and still consider JS “garbage” as a result. Bummer. In the Scala community I hear so much hate for NodeJS because it enables JS for server-side, “where it doesn’t belong” for many of these same old reasonings about typing (even with TS!?).

So yah, there’s value there, but you don’t NEED it to write large, good software. I’m clearly just jaded by the religious debates that have gone on and on - so despite their utility, I can come across very anti to the “solutions” to IMHO shitty arguments.

There it is… that’s the classic argument. Large teams/codebase. I totally get the appeal, but the idea this can’t be done effectively without it is nonsense. Long before TS, we had JS apps with teams of 50-100+ working across hundreds of not up to a couple thousand files - in CVS/SVN repos (ugh). I will concede that TS does help in the larger teams/codebases but - I will contend it is not necessary if your team is composed of folks that have depth of experience working without.

Classic example of comments I've heard since the 90s.

I’d strongly encourage doing a deeper dive here. Functions in JS are objects and can have their own methods/props + scope. They’re a first class citizen.

+1 - that was a really cool idea that I really was hopeful would take off.

Despite being down on all the extras, I wanna reiterate - I do think this is a cool project and I dig that HTAs are still around.

I think, based on many battles, a lot of folks in the early days that came from Java/C++ absolutely struggled with the key concepts of JavaScript, couldn’t find “features” (like strong typing) they claimed were critical for writing good software and invented ways to make the language fit their paradigm, rather than really deep dive into the language and embrace it. There were constant battles back then - and I’m sure the battles continue.

JS was certainly never a “garbage” language but the elegance is unappealing/unappreciated by entire classes of developers. I totally get the perspective, but it’s all based on a worldview that just doesn’t get functional programming

Firstly, it’s functional with closures… From there prototypal - so you can express whatever you want… the key is being functional. This was a key to the advent of JSON, but is also one of the most elegant and powerful bits of JS

Static/strong typing is not necessary in JS.

Yes, ES6 brings the OOPiness

This stuff pre-dates .NET and quite honestly I think that’s what m$ was going for in those early days. VBScript was pretty annoying and dealing with COM objects sucked badly. Back in the day we’d build in a local VB interop with JavaScript so we could make system calls and interact with native Windows stuffs. This predates JSON so at the time we’d use XmlHttpRpc to talk to remote/hosted services.

I’ll double down on the urge to drop TypeScript. That pile of nonsense came from the classic OOP folks - “But where are my TYPEs!? How do I know what type that variable is!?” (first the Java/C++ folks then the .NET folks “solved” the brain fuzz around functional programming and dynamic types by giving you TypeScript)

Having been out of the m$ ecosystem for some time, I’m kinda surprised HTAs are still around, I’m guessing to avoid breaking things. Once .NET started taking off - I always assumed that would replace the VBScript side of things and let you build proper, elegant system interfaces for your JavaScript app. I really imagined the goal was to drop Windows forms/object controls - but I always imagined BATTLES at m$ over being able to create Windows “apps” that didn’t conform to native UI controls, couldn’t be controlled through Windows theming engines, etc. kinduva brand control battle. I always imagined some team going “NOOO, just build a web app, you’re breaking all the UI rules!!!”

Been doing this since 1999. The only thing novel I see here is the transpilers - but you know… you don’t need that. You can build HTAs with native JavaScript, CSS and HTML - and with a little VBScript mixin, directly work with Windows libs. Back in ‘99 and early 00’s I was delivering “thin-client” control panels & management tools for server farms, sensitive accounting data, among a variety of other things. It was (and likely still is) a great way to provide a web interface as a desktop app for scenarios where exposing the management interface to the open web is undesirable.

Nifty project, but IMHO the world is better off using native JavaScript without all the BS that comes with TypeScript, etc. JavaScript is so powerful and amazing, it’s a bummer to hamstring your app by using TypeScript and classic OO inheritance models that preclude the beauty and dynamics of JavaScript as a functional, prototypal language.

When hyperbolic reactions rule the day, particularly when they are contradictory to one’s stated goals (provide clean, low prices energy and potable water) - dismissive labels are readily handed out. Both sides of the aisle are guilty so these labels go along with the hand waving dismissal of basic common sense & standing local rulings. The analysis, civic discourse and problem solving was performed, but disregarded for performative ideals - that continue to be a direct contradiction to the research & solutions presented. It just sucks. Especially when the state can leverage authority from Sacramento, overruling local resolutions and ordinances that were based on the research, analysis and civic discourse.

Yup! If memory serves, some of the design was borrowed from the San Onofre plans. Certainly only limiting in terms of volume of desalinated water for Orange County. I believe that was the original intent as San Onofre is nicely situated to serve both counties

;P

Turns out it’s actually harder to decommission… :shrug:

This was originally planned in conjunction with the San Onofre nuclear power plant, which gave all of SoCal amazing power and offered the infrastructure for performing desalination in conjunction with ocean water used for cooling parts of the reactor. Sadly, some hippie in Sacramento decided to kill our power plant so now energy prices have soared and we’ve lost the potential for desalinated water in San Diego, Orange and LA counties. My buddy has been working the decommission for a decade now. Given a few beers, the rants are quite illuminating and disappointing

Having recently participated in a of review GitHub Copilot to determine if we might allow it at work, I can say it appears that most of the utility is in tab-completion of what you were roughly intending to express, in very short form: variable completion, expression completion and function/method/class/object/value signature completion.

I personally didn’t see suggestions that would have significant impact on code quality - simply helping one more quickly express initial concepts including all the language necessities. Intellisense++ish.

I have only seen it assist developers who were going down a bad path get there more quickly. I have not observed anything that would encourage/discourage any design pattern or developer choice.

My gut tells me that the fact that devs can more quickly deliver a “solution” (bad/good) means that they deliver their fat PR and … well … it’s fat - so it’s not scrutinized as well as it might have been had the dev taken some time and another set of eyes hit their branch before they got too far along. It’s often much harder to get the proper attention and review on a large-ish PR than it is to peek in along the way.

I personally couldn’t find anything that I feel would inherently lead to lower quality code. I do see how devs could more quickly deliver their low quality code and it can be a challenge to deny that code.

I’m left on the fence. I’ve found it valuable for autocompletion of what I’m about to express, but I also have no illusion that it’s going to tell me that what I’m about to express is stupid and/or of low quality.

Those things about quality are also quite language specific. Not so much about guessing what you might be about to type for tab-completion.

Also note - it’s about efficiency - as GitHub has stated. Duh. Notice copy/paste declined? Tab-completion. How many jr devs have you seen that won’t just write out a function declaration, they copy paste an entire function, gut it, and write their code. Odd to me, super slow and lame, but even I have seen the utility of tab-completing empty function blocks that are 90% of what I wanted.

Sooo. I’m inclined to say it’s interesting - but in no way at all diagnostic, deterministic or a very good study when it comes to writing conclusions. These are hyperbolic statements. Nearly link-bait.

As a volunteer Greyshirt with Team Rubicon, I cannot relate.

One of our cultural principles is, literally, “Get shit done”.

Another is, “Your mom’s a donor”.

In your position, I might recommend associating with other volunteer based non-profits and gather some good, concrete concepts around how they plan, their guiding values, how they organize and conduct activities, how they source supplies and execute logistics to support their volunteers, etc.

These relationships and ideas may give you some concrete feedback and examples to share; and offer a conduit for your leadership to engage other leaders and learn from them the lessons & challenges ahead.

Good luck

Doubling down on my comments about ShapeUp (et al) as I reflect.

Engineering management, in my experience, has an allergy to agility. They can and do take any methodology, turn it into a process with a rigor (they love that) and strip agility from the mix. They are addicted to well defined requirements, some degree of estimation and being able to predict/project things like delivery, velocity, contributor performance, etc.

We engineers love the principles of agility, so engineering management tries over and over to find that happy medium where they have a well defined process that gives them what they want but imposes the least friction against the agility your engineers crave.

Custom solutions win the day. I have lived through all of the above. I remember when Agile was introduced, do you? Do you recall how violently reactive engineering managers were to this concept? It goes against everything they are supposed to do - manage. Agility inherently means they lose some degree of management ability. It means they lose their precious waterfall where things are meticulously (ridiculously, inaccurately, elegantly, uselessly) pre-planned on paper.

IMHO this is why we see every methodology that supports being Agile - bastardized to the point of confusion, academic arguments based on (not having actually learned, practiced, or gotten good at anything) gut feelings of “how we should do it here”.

Leading, managing work, organizing resources and getting shit done is a skillset that encompassing multiple disciplines. All are documented and practicable - we apparently don’t have the discipline to actually read and practice. We’re like a bunch of yokels on YouTube commenting on who’s a better MMA fighter, telling Joe Rogan he’s wrong - but only a select handful of us actually speak from authority. Only a small handful will actually take on the RISK of trying to understand the literature and practice a methodology like a beginner - without questioning the teacher or the teachings.

All that said. I have seen both Kanban and Scrum be wildly successful. The key ingredient in each of these was a shared humility and curiosity between engineers and managers and an environment that celebrated learnings and put no penalty on getting it wrong. The lack of hubris was absolutely the ticket to an agile environment where shit just got done, engineers had a GOOD TIME, we built meaningful product and we weren’t worried about blasting time in meetings because it never impeded our ability to get shit done. Once the engineering org can demonstrate its key metric (getting shit done) the battles with product cease!!! Product can trust that engineering will get shit done - without handwringing on “when” - and they can properly focus on “what” shit to get done.

When engineering is flailing around on their methodology, process or agility - they lose trust. That’s when product starts thrashing. That’s when you start to see initiatives/projects start and never finish, along with shifting priorities.

ShapeUp does an excellent job of giving product a tool to direct what work we’re doing - hopefully making sure we’re working on the right thing. However, if you’re trying to bastardize ShapeUp to fit your engineering org structure - it’s VERY difficult to demonstrate and project “well get this done”. Further, if you think you’re gonna keep your teams intact and do pitches per team - you’re already broken, committing to more than the org can deliver, creating conflict between teams on how to do the work, leading you right back to waterfall. Rather than building the right team of resources for the pitch/cycle - you now force all your teams to produce design docs, plans, backlogs - which have to go through review, get picked apart by other engineers, only to find your assumptions were wrong and the deliverable looks quite different than the design (shocker!!)

I’ll conclude to say we’re likely all doing some degree of waterfall++, branded as some form of “agile” methodology.

If you wish to see that change, encourage your peers and your managers to start with your team, pick a methodology, go exactly by the book, get “good” at it with practice over an extended period, collectively enjoy and DOCUMENT the many “aha!” moments along the way, the proliferate that out to the rest of the org. High performing teams are hard to ignore and at some point the org will ask why - simply be prepared with HOW you adopted and your learnings.

Good luck out there

Been using ShapeUp for nearly a year now in an org of ~50 engineers.

Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process.

In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course.

As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”.

Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking.

In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong.

Yaaaas, my dad had one of these and through some magazine I had learned it could produce music… I had limited success but I was able to master enough annoying compositions to be forbidden from messing with it. I forgot entirely about this until your photo. Wow.

And I had no clue who Kraftwerk were until the 90s when I could comprehend and appreciate anything. I had no clue about the connection.

Yah I’ll pile on. Record yourself like you’re on a call and look at different things. Do some typing, do some on-a-call context switching and listen how awful it is. Then imagine network/VOIP - it’s only worse and most services even resample and do things like audio detection to avoid typing or other background noises. Your fancy mics all suck for this. In my experience anyway.

Having been WFH for the last 15y…

Chair: yes but doesn’t need to be expensive. I’m still dragging around an office chair from 2002. It just fits me.

Separate your space. Make sure your work and home environments don’t collide. Once I learned this lesson, I bought a used RV and converted it. Power, A/C, fridge - just plug into the house and you’re good. Once the rats infested it and got me sick over and over, I switched to a Lowe’s Garden Shed. Now, replete with a basic folding table and all my stuff.

Synergy. One mouse & keyboard + clipboard, shared across all machines. From left to right, I have a personal intel NUC, work MBP intel, work MBP m1, personal MBP m1. Each with an extra monitor positioned above the machine. So effectively it’s like a single giant machine but workloads can be isolated. So nice. Game changing.

All y’all with your special mics - stop it. They suck for us on the other side of the call. Just get a set of headphones with a mic built-in. Beats, AirPods, etc. y’all with your fancy mics have no idea how inconsistent and awful they are for us on the other end. I lose at least 10-20m of my week with people futzing around with their fancy mic. Stop it.

Again, separation of work space vs living space is paramount. You can poison your living space with all the positive and negative of work - it’s just hard to really let that stuff go without physically changing your environment. Polluting your living space with work will only work for so long.

Other than that, I wish I could express how rudimentary you can go and get yourself a really good and productive space.

FWIW, my keyboard is an old Dell, circa 2005 - still rockin - mouse, old Logitech (2007?). Desk is srsly just a jank folding table.

It’s definitely less about the toys you buy than the protection of your work space vs living space - and making sure your just plain comfy sitting for hours on end as you forget to take a break.