If it's anything like where I'm at, a retrospective is to give "appreciations" and other bs.

I think retrospectives are mostly to vent frustration so it doesn't keep building up.

Did you let it all out? Good. Management hears and empathizes with your concerns.

Ok now back to the exact same grind.

ya we do retros. and while we can change some things, much of this SCRUM type stuff is not really up for debate. I mean, we are asked to "discuss" it but its pretty damn clear what the answer our scrum master wants and what the direction we are gonna go is.

and thats another just absolutely infuriating part about it. the whole passive aggressive part where questions are posed but they arent really questions. nor is it even a recommendations. rather its a directive, but the scrum master doesnt want to explicitly tell us what to do and wants us to justify it for her.

like when she says, "An advanced scrum team has a WIP limit of 1 card. that means they only work on one card at a time. How do you guys feel about working towards such a WIP limit?"

Obv she doesnt want us to outright reject such an idiotic idea. Many team members do and give good reasons. But I am smarter so I say, "Oh yes, lets try it". (I say this to stay on her good side and bc I dont want to fight about it and we can always just ignore it later).

But ofc thats not good enough. she will then say "oh well why do you want to have a WIP limit of 1?" and ofc this is where she gets you bc if you give some justification, the same justification that she had spoonfed earlier or have came in your emails from the higher ups who do no real work then later on when this whole thing falls apart she will throw it in your face like "well if you remember we agreed to do this thing for these reasons and blah blah blah".

anyway my problem with SCRUM has always been these artificial proscriptions. and this is just another one.

@suzzer, and ya while retros are good for venting, I much prefer to post it on semi anonymous message boards. also, at least our team is smart enough to keep management out of retros (altho I think our scrum master would rat in a second)

They are requesting input for the new version of Twoplustwo on the Vanilla software again, if you want to give your input the thread is here:
https://forumserver.twoplustwo.com/5...forum-1766061/

Please help save 2+2 from turning into a completely dead forum.

I mean, old forums, new forums, neither is going to save this place.

I've seen retros done well at various times (including current team I'm working with).

The biggest thing for me is to focus on things the team can actually control. There's almost always stuff that can be improved noticeably just by having a time for everyone to talk about it explicitly.

If your team can't actually control anything (which sounds like the case here) then a retro isn't going to help you.

Yeah, if your told your team HAS to have a WIP of 1 and that's the parameters of your workplace, then the retrospective should be how do we work within those set of rules. I agree its dumb and frustrating but bad bosses are gonna bad boss.

I only started browsing these forums again because
a) working from home because of covid-19
b) compile-build-test cycle is so freaking long at current company

I've got e2e tests I run now that take forever. It's like the old browse the internet while Weblogic boots up.

Was it grue that had a popular game? Whatever happened with that

It's still going. We recently had a long phone conversation because he's been running the whole thing on one instance of node and not surprisingly adding more memory or CPUS wasn't helping with slow response times at peak load (the node event loop runs in one CPU).

But it's a major change because he basically keeps the games (which each contain tons of constant chat events) in node resident memory as plain old JS objects. So he has to come up with a new design that saves the games in some kind of hot cache that any node instance can access. I think he's looking into cassandra.

He's on the other site btw (unstuck politics) and we've got a programming thread there.

yeah I still lurk on occasion I just have a hard time giving this site page views and "content". Game is going great in that during pandemic I have almost 1000 users playing playing at peak, 4-5x more than a few months ago. I had to spin up 2 new servers due to the single core issue, but am almost done with a total refactor of the back end by moving state from memory into redis which has been interesting. The whole concept of scaling has been a big challenge to wrap my head around. When I made the game originally I just basically wanted something out there that I was hoping 30ish people would play but instead yeah. I'm not sure I would have done a lot different TBH.

Ah - why did you end up picking redis?

Also once you go through this once - I predict you'll always write your node apps to be stateless going forward (except global bootup state).

That’s awesome it’s picked up that much. Sounds like a fun set of problems to work on too.

I feel like with 2p2 moving to a new forum software and lots of people going to a secondary site, my involvement with the 2p2 community overall will go the way of Dave. (Both of them)

I am sad to see 2+2 migrate away from their current setup (to a site that currently gives a "Permission Denied" error when I try to log in).

To be fair, this site is terrible from a tech and usability point of view. We're use to it and all... but still terrible.

Does the new site have any of a) likes, b) auto new post load w/o refresh and c) inline image pasting?

Sounds like they may not be moving now. Guess the negative feedback was too much

Time until shitty javascript code results in me losing my bankroll?

Help them debug their login and maybe they'll let you borrow the boomswitch for a day.

So I'm likely going to be moving to a new team/product within the year and I want to take the opportunity to try to do things better. Specifically, I'm wanting to incorporate TDD/units tests into my daily programming life and so I've been trying to read up on it. I get all the theory / benefit behind it I think. Unfortunately, a common thing I see in various threads/blogs is that its really easy to fall back into not doing it if its not already an ingrained habit. So looking for any advice or feedback from others on

-how you learned? So many examples are overly simple.
- Did you have a mentor? Was the rest of the team you were on already do it?
- Did you have management support/involvement? Not that it should matter as long as you're producing code, but my previous team didn't care about QA much and was almost literally 'as soon as it compiles push it out'.

The only way to learn is just to write tons of unit tests. TDD is a nice goal but hard to reach until you've got a mature testing framework in place with tons of test. But "almost TDD" - IE write code, then immediately write test, is almost as good imo.

I did not have a mentor, and it's definitely tough going at first. Writing good tests takes a lot more skill and creativity than just writing code. But eventually you work through enough weird things and find a solution - like say a mocking package to let you mock external npm dependencies - and you start to build up a library of tools.

One thing different with coding - don't worry about abstracting your tests into common functions until the same thing comes up a bunch. No problem copying large blocks of code as 80-90% of your unit tests may never fail so you never have to deal with it again. The ones that do fail you can start trying to make your life easier (like say - deleting some value like dates which are always changing from your stubs and your target).

Apparently there are mythical places where management really cares about tests and doesn't just give them lip service. I personally have never worked at one of these unicorns.

IMO if you're going to be a one person testing/QA show - you're also going to need some good integration and e2e tests. With those, you're never looking to test every nook and cranny - just the most essential and most easily over-looked stuff. Try to keep keep track of which tests save your ass and which test might not have been as valuable (IE - integration or e2e tests for some problem that would make the app instantly crash on bootup anyway aren't really that necessary).

The most valuable tests I've found are the ones that catch edge cases which you don't always smoke test for - like how does the front end handle a back end system error, or some weird edge case login flow. Those will save your ass if you don't have a thorough QA team.

I primarily write PLC code, and there isn't much out there on writing tests for that kind of code.

I have written some tests for my product in the past, and have felt pretty good about it. But when you're using pre-made functions that take 5 or more arguments, it can be difficult to think up ways to get lots of coverage with out absolutely brute forcing it.

The part I'm struggling with mentally is the time to do it. I've read plenty where people say once you're used to it it doesn't add that much more time to your DEV process and saves time in the long run. But for example, management/product owner says how long will it take to do feature x. I say a week as I am including some time to write tests, etc. Management says is there anyway to make that faster as customer really needs that feature right now and a week seems too long. Since I'm new to unit testing stuff, I could do it faster if I ignored it but I'm not sure how to answer that question then to management.

As an aside, that particular manager is no longer here and the way we do estimation is different now, but I'm reflecting back on how I could've/should've done things differently.

I know this is blasphemy but I dont think unit testing is worthwhile. better time spent elsewhere.

now, I love unit testing. I like to write code and I learn a lot writing tests bc I like to challenge myself and the frameworks and the code in general. but spending an entire day or more on just a couple tests surely isnt worth it. esp when most unit tests boil down to true=true. and the ones that take time are bc I am trying to prove something to myself about how the code works.

and depending on the work you do, damn near all devs are gonna test their actual code on locally or on a dev server regardless of the tests they write so whats the point?