_6pvr

We are in the middle of a global pandemic. I'm sorry this reality upsets you.

> It’s hard to do test-first TDD “mindlessly” because writing a test usually forces you to think in terms of the specification of the behavior you’re about to implement.

Tests are code. Code can be sloppy, fallible, useless. Writing a consumer before you write a provider doesn't make either more robust, just the point at which they meet more clear. You can certainly write a test that uses a function, but the test doesn't actually test anything at all, just that the function exists. aka "mindless TDD".

> Is it just me or was this _not_ surprising at all?

It wasn't surprising to anyone that has reflected about the value of tests. Mindless testing/TDD isn't usually reflective, though.

A mandatory meeting in which all developers must be present and regurgitate status updates to the entire team, as an example, assumes this information wouldn't get to relevant parties organically and all team members must consume all status updates.

> We need to be able to see each other in the eye.

This isn't what happens during webcam meetings. If you're looking at the camera (to try and provide eye contact), you're not able to see anyone looking back at you.

> Managers, especially, should set the right example and turn their on cameras - and ask their team to do so too.

Definitely not, and I wouldn't work for a manager that cared if my camera was on or not.

Don't estimate. They don't matter and nobody cares about them anyway. If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.

If you're a company that plans far in advance, the same is true. You'll demand the work you wanted is done at a given date, again regardless of how difficult it was.

At my company, we have a well maintained backlog of work. We pick dates in the future to check in on what got done in between check ins. The product manager can (re)prioritize work as needed. We pull from the top. If there's a surprise deadline it gets brought up to everyone and then put at the top of the queue, sometimes over currently in-progress tasks.

You cannot bend the realities of time and complexity. If something is hard, an estimate doesn't make it easier. A hard delivery date also doesn't bring predictability. Ultimately, with or without estimates, you'll get what you get. If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up. If every team is working optimally (they're not), hire.

I'll also add, the time it takes to prepare an estimate of any value is probably 10x what anybody asking you to estimate something is willing to provide. You're being asked to spit out a number to fit an existing narrative. If you wanted to estimate a unit of work with any amount of legitimacy, you'd need hours/days/weeks (depending on SOW). These companies scheduling weekly estimation meetings that last an hour and are bullshit scrum cards don't matter and aren't interested in being even close to correct.

> Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc.

Is this serious? You think _most devs_, meaning a group that includes FE devs, mobile app devs, IoT, open source, DBAs, security engineers, need to know these things?

> With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs.

Most teams do not have to manage most/all of the things you're describing.

This really feels like more K8s marketing disguised as a HN post.

> Then why do you start running forward instantly when you press “W” in counterstrike or quake? Why not just deploy servers closer to users?

You do both? Game client handles movements and writes game state changes to a server, which should be close to the user to reduce the possibility for invalid state behaviors? You really haven't seen online games that deploy servers all over the world to reduce latency for their users? What?

Both web apps and games do optimistic server writes. Both web apps and games have to accommodate a failed write. Both web apps and games handle local state and remote state differently.

> In many areas of the US, that trigger happy cop will be the difference between you recovering your propert

A cop's not going to get your bike back. They'll write a report and then throw it away when you leave.

(Not attacking you) Do you write a substantial amount of Go very frequently?

> Kubernetes is complex because the reality of what you’re dealing with is complex.

Passing off complexity instead of reducing it isn't a net-positive though. The purpose of frameworks/libraries/etc is to (considerably) reduce complexity. In Kubernetes, you've replaced a group of specialist engineers with just a different group of specialist engineers.

> why are you joining the meeting to begin with?

At companies that misuse meetings, most meetings are not optional to attend. Of course you could say "Well just don't go", but some people don't like getting fired over things like this.

> Just decline like a grown-up and get some actual work done

What a condescending way to communicate.

What a truly excellent strawman. Do you see no middle ground between obviously sexual content and a Burqa? Is there no middle ground between writing someone's name on your breasts for $5 and going to the beach to swim?

The joke is asserting that hot tub streams aren't sexually suggestive. The twitch community seems to love them, so of course Twitch will fight tooth and nail to keep them. But to suggest that they aren't sexually suggestive (and by proxy against Twitch ToS) is an absolute joke. They look like clowns.

Twitch continues to pretend hot tub streams aren't intentionally sexually suggestive. What a joke.

HN doesn't really do memes, but I made this because it seems relevant: https://imgflip.com/i/5ah3b7

> 7. Epic paid so far 1 billion USD to convince devs to not sell in competitor stores.

This is kind of a toxic disingenuous spin on store exclusives, no?

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing?

> Even Nodejs doesn't always let you re-use code between backend and the front.

This is not true. Check out Lodash. It's a dependency of pretty much every FE and BE NPM package that exists. Ignoring rendering libraries like React, client side JS and backend JS are "just" JS.

> I've never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language before.

I think you should definitely keep doing the things that bring you joy!

> Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or spec or malli.

I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into them to prevent slip ups. Why wouldn't you want to take advantage of that tooling?

Also, as a result of this comment section, this is the second time in the past week that I've seen the suggestion to use 3rd party typechecking/static analysis tooling in a dynamic language, which (to me) brings up the question: Do you really want a dynamic language, or do you just want the ability to be careless intermittently? There is no shame in saying "I just want to get happy-path code working quickly". There is joy in getting happy path working quickly. I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic.

It seems like if a tool is so essential to successful development in a language, it should probably not be a 3rd party library but instead baked into the language tooling itself, no? (I have never used Clojure and am not trying to be inflammatory)

> Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.

A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. You could maybe make the argument that the guarantees provided by the language and compiler reduce the maintenance burden of software built in Rust, but I don't even really think that statement has been tested (via Rust being so young).

It is tiresome the frequency that legitimate language discussions for some reason turn into Rust vs. Go trash talking. It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. There will be legacy apps that people hate working with in all programming languages, and there's nothing that can save you.

This matches my experience (but replace UE4 with Unity).

Godot just doesn't fight you the way Unity does.

I've found both AWS Lambda and all Azure serverless tooling to be extremely frustrating. "Just don't do local development" is the feedback I see a lot, which just seems bonkers to me. Like the orgs that don't run tests locally and just use CI to validate builds. If your workflow involves long periods of waiting to test even very basic functionality, it is (to me) totally broken.

We have containers which unify local environment and production environment. In my opinion (and experience), there aren't any more efficient shared mediums to work with.

Am in the midst of shipping a medium sized game in Unity and I can confirm your takes are correct/relevant today. Unity is incredibly frustrating to me, and I would really aggressively challenge the notion that Unity is aimed at any sort of "Developer Productivity". More than anything it's a dumpster of features to allow Developers, Artist and totally nontechnical/non IC contributors to all contribute okay-enough. But the features that go into making Artists productive are at times orthogonal to those that make Devs productive. It's all a big tradeoff.

Godot is smaller and has way way less learning material (and no Asset Store), but purely from an Editor perspective it's miles ahead from a dX perspective.

I really hate the wave of language "competition" and contention. Go is a language that allows lots of developers to get great work done. So is Node.js, so is Haskell, so is Rust, so is Java. The list goes on.

If you find a thing you like, you should use it! If you find a thing you don't like, just don't use it! Find the language that lets you express your intention as easily and correctly as possible and run with it. For some people that is Go, for some people that is Erlang.

I'm certain this thread will devolve into "Go isn't a great programming language because..." type posts, but I really think those posts are kind of ill-intended. The author of this post likes Go, which they're allowed to do, and they should continue using and enjoying it.