CipherThrowaway

I think EDSLs are the happy medium here.

>spend your time and effort trying to understand what people before you have already figured out

What makes you think she hasn't done this? The point of the article is that "tools for thought" as presented by Ken Iverson and others are a narrow focus in a much broader subject. Since her aim is to zoom out it makes sense to defer mention of Iverson. It's not indicative that she hasn't engaged with or understood his work.

>it never occurred to me that it could be used for configs.

It can't be. Using "markdown" for config really means building a shitty ad hoc configuration language and embedding it in markdown. I've seen this a few times and it's always a disaster.

The only way I've found to make configuration tolerable is to go in the opposite direction and turn it into code with a declarative eDSL. For example Pulumi's typescript API is an absolute godsend after years of toiling away on HCL and YAML.

Yes, most people can get into something workable and most people do. 9-5 probably wouldn't be the norm if this weren't the case. But if someone is years out of college and still can't sleep or function on the 9-5 schedule then chances are they are one of the few rather than the many.

>but that doesn't mean anyone can say "the workplace is rigged" against them.

You absolutely can. "X is rigged against them" is the social model of disability in a nutshell. Workplaces with rigid early schedules are rigged against people with sleep disorders and late chronotypes the same way buildings with no ramps or elevators are rigged against people in wheelchairs and on crutches.

Assuming your username means you're in college: I would wait for a few more years before appointing yourself the expert on other peoples sleep physiology. It's easy to think this way in college because people around you will be sleeping poorly or erratically, won't respect sleep or bother with sleep hygiene.

Once everyone is out of college the biological differences become a bit more noticeable. Most people will "fix" their sleeping relatively easily. Others will struggle at first but eventually make it work by adopting strict sleep hygiene and routine. Then a few will find that no amount of sleep hygiene gets them into a good cycle for the standard working day. For some of them the issue will be severe enough to qualify as a clinical disorder like DSPD. DSPD is known to be extremely difficult to treat.

I agree with the sentiment but there are problems besides accessibility here:

1. Crosses and squares being used instead of check marks.

2. Circles being used as containers instead of boxes.

3. Toggle switches being presented as checkboxes.

Maybe 5-10 of these are good inspiration for checkboxes.

Have you worked in many environments that have implemented SAFe well? These theoretical benefits seem to be hard to translate into practice.

>I'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities.

FWIW this idea has been losing some ground to the double empathy problem. People who aren't on the spectrum have corresponding poor theory of mind and empathy towards those who are. The problem is at least partially symmetric.

I've noticed a form of cultural cringe in developer communities where we assume that developers tend to be on the spectrum, have uniquely poor communication and social skills and cause social problems more than other working professionals. It's contrary to what I have seen in real life which is that dev teams socialize effectively and form cohesive and healthy cultures as much as any other field. That developers are usually the ones promoting better written norms and more thoughtful and thorough written communication.

The "assumed context" problem is common everywhere. Poor communication, anti-social and toxic behavior are common everywhere in most organizations. Developers are self-conscious of our poor social skills to an extent that is not matched elsewhere.

Product management is clearly a legitimate function. A good PM embedded in a cross-functional team can make a night and day difference.

Problems seem to begin when product management is externalized from the product teams, put into dedicated teams or departments. The role is seen as something like "telling the devs what to build and making sure they build it."

The client-server relationship is distributed but the intra-browser stuff is just async IPC. Writing robust clients against remote APIs requires considerations around retries, failover, idempotency and read/write consistency. It seems to me that distributed patterns in pure client code are thin on the ground and limited to things like CQRS and Sagas.

Agree re the article, disagree re labor vs management. This mentality in an org is almost always a result of mismanagement. The reason is obvious: it's a people issue and dealing with people issues is a managerial responsibility.

Thinking that managers are bad in general is only a sign of inexperience because it implies someone has never worked in a place with good management before. I've seen plenty of "fuck management" types completely chill out after moving to a better workplace.

I strongly agree that managers do not need to be technical or understand dev work. However, I don't have much sympathy for managers who are "misunderstood" by engineers. Companies that have issues with disgruntled engineers grumbling about management and process are mismanaged almost by definition.

I'll add that the specs are so bad that it's not commercially viable to try to fully understand them before building and launching BT products and middleware.

The problem with flattening the two absence cases into an enum is composability and generality because it forces the "outer null" case to intrude into concrete types. Say you have a key value mapping Map<String, T> and you represent changes to this map as Map<String, Option<T>>. One day T itself is Option<Int> so you end up Map<String, Option<Option<Int>>. If you want to use e.g. Option2 for that latter case you lose generality.

Where the "double absence" issue comes up in practice, it's usually in a context where it does make sense to represent and handle the first type of absence separately from the second type.

That's also how I've seen it done. But that's not so different from the nullable optional approach. It's still effectively two flavors of null.

What I'm wondering is how people who have an issue with different representations of absence would approach (or avoid?) situations requiring them.

In cases where the field is required I would agree. But in the context of an update request, {"foo":null} and {} might both be valid with different semantics. "Update this field to null" vs "don't update this field"

What is your solution for representing the difference between

{"foo": null} and {}

Because they are different, right?

Ad hominem doesn't necessarily mean fallacious or invalid. Bob's whole brand is being a self-styled authority on what constitutes clean, high quality code. So yes, his achievements and personal credibility are important here.

I lean conservative in my tech choices but I just don't see the big issue with Kubernetes. If you use a managed service like GKE it is really a breeze. I have seen teams with no prior experience set up simple deployments in a day or two and operate them without issues. Sure, it is often better to avoid the "inner platform" of K8s and run your application using a container service + managed SQL offering. But the difference isn't huge and the IaC ends up being about as complex as the K8s YAML. For setting up things like background jobs, cron jobs, managed certificates and so on I haven't found K8s less convenient than using whatever infrastructure alternatives are provided by cloud vendors.

The main issue I have seen in startups is premature architecture complexity. Lambda soup, multiple databases, self-managed message brokers, unnecessary caching, microservices etc. Whether you use K8s or not, architectural complexity will bite your head off at small scales. K8s is an enabler for overly complicated architectures but it is not problematic with simple ones.

>Did users ask for this?

Not an argument. Users don't ask for implementation details. They don't ask us to use Git or build automation or React. But if you always opt for less sophisticated workflows and technologies in the name of "just getting stuff done right now" you will end up bogged down really quickly. As in, weeks or months. I've worked with teams who wanted to email source archives around because Git was "too complicated." At some point you have to make the call of what is and isn't worth it. And that depends on the product, the team, projected future decisions and so on.

>If we break our bones we visit a doctor. If our teeth hurt we visit a dentist.

Depends on your health insurance, financial standing and free time. If you're an affluent tech worker you probably would go to a dentist for a toothache. Most people I know would not.

I wouldn't compare mental health to broken bones. We've been successfully treating broken bones for thousands of years. Seeking treatment for depression or generalized anxiety is more similar to seeing a doctor for some poorly understood malady like ME/CFS or IBS. No one really understands what's going on or why. You might try some medication or treatment and it might work, do nothing or make things worse.

It's worth a try but it's not a silver bullet. If your life sucks and your future prospects are bad then therapy is really just helping you cope.

This is confusing to me. Did VisiCalc start as a reference card or not? Because the article doesn't say this and neither does the transcript of the TED talk.

>In addition to prototyping, Dan put together a reference card for users. If we couldn't figure out how to explain a feature on the reference card we would change the program. The original method for copying formulas was too complicated so we just changed the design rather than try to explain it.

Sounds like the reference card came after prototyping and was used as feedback in an iterative prototyping process. Pretty standard. This isn't "write before you code."

Is this even true? Applying engineering project management and methodology to software was the default approach historically. This is essentially the waterfall/BDUF that "agile" was reacting to.

The OP is just content marketing for some proofreading software. No one actually thinks this stuff is an epiphany unless they are completely unfamiliar with the history of the field.

"Zero" here means no previous handstand practice. >5 seconds of freestanding handstand in 30 days seems pretty realistic for someone in reasonably okay shape.

Boxes and arrows are a bad representation for complex systems with detailed relationships. Legible diagrams are limited to high level representations of a system where many details are left out. Constructing useful high level views of complex systems requires human judgement.

Generation of legible diagrams could be accomplished on a domain or framework basis where code is subject to local patterns and can be structured "for" generation. We see this with things like OpenAPI schema generation.

Ultimately I think diagramming isn't prioritized because diagrams themselves aren't that valuable. They're just a medium for the actually valuable thing: high level representations.

The mechanical engineers at my work can barely use a computer. I think I'm good.

This feels tangential to the article. The article doesn't situate YAML against XML, JSON, TOML etc but against general purpose languages. The differences between the configuration approach and the GPL approach are pretty substantial compared to the differences between individual config formats.

GP is probably referring to HEX which is one of the more shameless Ponzi coins. HEX is an Ethereum token so its "proof of wait" mechanism is not actually a consensus protocol. The name is a marketing gimmick that merely apes (pun intended) the PoX terminology.

Problem with this PoV is that these things don't directly impart knowledge of a subject. You might be smarter than your doctor or lawyer, but they are decades ahead of you in terms of training and practice. This includes not just their personal experience in the field but also access to the social stock of knowledge of their profession. Sure, there are problems like institutional bias and groupthink. But these are minor issues compared to the issue of having no grounding or education in the field as is usually the case when engineers opine their unconventional views in different subjects.

So the fallacy behind the fake polymath is not the idea that being smart makes you better at analyzing information. It's the idea that being smart is a substitute for information and expertise. This mistaken assumption can lead smart engineers to beliefs that subject matter experts consider religious or delusional. Mars colonization is a great example in Elon Musk's case.

Btw most of the general training you mentioned isn't part of STEM and is historically associated with humanities subjects like law and philosophy instead. In STEM you typically work with set epistemic frameworks with unambiguous correct and incorrect answers. In this sense, engineers actually learn the opposite of critical thinking and discourse.

This is exactly it.

There seems to be a "pseudo-polymath" personality type among some engineers. Based on an unexamined but deeply held philosophical belief that engineering concepts and ways of thinking neatly generalize to all fields. The pseudo-polymath engineer is an instant expert in anything he bothers to turn his mind to and subsequently systematize.

Engineers who think they have unique outsider insight into an unrelated field like medicine or cognitive science should tread very carefully. If you can, try to validate your ideas and assumptions with a subject matter expert. Don't underestimate the large stock of knowledge and discourse that already exists in these fields.

Your problem isn't that you're old. It's that you don't understand how little you know in this space and this renders you too arrogant to learn anything new. New to you, that is, because the concept of pattern matching is actually many decades old. You encounter it in undergraduate PLT coursework, famous comp sci textbooks like SICP, and virtually any language outside the imperative/OO lineage.

Thinking you have an I-told-you-so moment with static typing and dynamic languages only shows you don't understand the details and tradeoffs in the design space. For example TypeScript's approach to static typing is very different to Java's and these differences reflect consideration of the problems being solved, JavaScript's specific use cases, its history and the path dependence of its design. Because these details are invisible to you the whole thing is simplified in your mind to "everyone is switching to static typing just like I said they should!" In fact this type of prognostication was never useful or meaningful. The hard part wasn't deciding to build static typing onto JavaScript. The hard part was determining specifically what that should look like, how it would fit nicely with the language and then doing the work of building it and driving adoption.

TypeScript is successful not because it is static typing but because it is a form of static typing that's exceptionally well suited to JavaScript and its use cases. If people like you had their way it would have been a failed attempt to bolt a Java style type system onto JavaScript, worsening the design debt in a language and ecosystem that is already loaded with it. This already happened on a smaller scale with classes in ES6 which were driven by Java devs writing JavaScript and wanting something familiar instead of trying to understand the language.

You might be right that adding pattern matching to Java isn't a great idea but at the moment your disagreement is based in ignorance. You've been given ample explanations of pattern matching in this thread. Put down the ego and take some time to learn on your own.