FWIW - my career evolution on this issue is something like:

First 13 years: what's testing?

Next 3: exactly your take above

Next 3: dammit I want to do testing but I'm on a huge team and I seem to be the only one who takes it seriously, also I have no idea what I'm doing

Last 1: what I described in my previous posts

Front end testing is weird. I mean there is easy and obvious stuff, like testing your service methods calling APIs and the store. But then there is the legit components, and people get so anal about testing everything there too. Oh you added a spinner to the button and disabled it while its loading?


Cool story bro

Yeah maybe some kind of "is this absolutely critical to the function of the app?" vs. "is this syntactic sugar for the user?" threshold is needed for front-end unit tests.

Also "will this be immediately obvious to anyone using the system?" vs. "does this only show up under rare conditions?". I'm never too worried about the former.

Although - couldn't you just add your expect statement to the general unit test for the component the button is part of?

I've had to make some decisions like that in my e2e tests. Like ideally you should have each test be independent. But that means deleting all test users, then registering the one you want (which involves waiting 5 seconds for a verification email to be sent, then scraping gmail with a pop3 client for the latest email received), then running your little sign in test or w/e. Oh yeah - with AWS Cognito I can't fully auto-register users programmatically - I have to register them with selenium.

Sometimes you just have to cut corners and run tests together - even though it breaks test independence.

You are fortunate and kudos to your boss. What I have found is that this is not encouraged by management often and basically can get into hot water. Absence of defects does not seem to be a metric that is tracked very often for individual developers. I mean you can’t write totally bogus code but at the same time devs aren’t rewarded for code that has very few defects very often. I am sure there will be disagreement with thst take but FWIW that has been basically my experience.

I think there is plenty of evidence that the least expensive way to remove code defects is to find them as early as possible. Seemingly many organizations go against that idea. Of course I am referring to C/C++ code so I am only referring to that. There is a schedule to be met and we need to get to the system integration milestone. Stuff like that discourages early defect removal. My experience is that an acceptable number/level of defects in initial product versions is acceptable.

You may not have been asking for solutions but it's just likely that the paper type in the printer is set to some different stock than Plain. If you change that it should fix it.

Recruiter sends an email with asking for a phone call to update me on my onsite last Friday. There was no tone associated with the email so it seemed like I was getting rejected. For the next 2 hours I was on edge and nervous about what the results were. Why do they do this?!

Anyways the call happens and she said “The feedback collected so far has been excellent so we will move forward with team matching”. I’m not in the clear yet since I have to pass a hiring committee but things so far are looking good and fingers are crossed.

Haha yeah, like, give me a clue, as in "good news, I will call you in 2 hours"

so we are on the next iteration of scrum. its called SAFE. this super lean agile SCRUM methodology has started with 2 entire days of meetings to "refine cards."

the goals for these 2 days of meetings is "Sprints 14-17 are written, pointed, prioritized and approved."

seriously, 2 days to sit around and write cards. just amazing how much of a scam this whole thing is. I gotta give the creators credit tho. they created and marketed an entire cottage industry to get paid.

one thing I noticed is that a lot of business ppl and esp esp esp the "scrum master" absolutely love meetings. I am pretty SM loves it bc it looks like she is doing something and is doing important work. instead it is wasting my time. yesterday she scheduled 2 meetings:

1. Problem Solving > How to Increase Cross-functionality
2. Review Program DoD, Team DoD & User Story DoD

DoD means definition of done which it seems we go over about once a month anyway.

Heres some other extra meetings (outside of standard scrum which is way too many damn meetings anyway) from the last few weeks:

-Blocker Busting - After the Retro’s, I like to review the retro data. I’m learning that I like to pick up AI’s too with the intent on continuously improving our team on noticeable patterns.
In receiving feedback, it was highlighted that a separate Retro on Blockers would be beneficial to us to help identify the root cause & provide solutions.

(as an aside, seriously look at that language.)

- Test Specify Retro (test specify is a piece of process that is dumb imo)
- I cant find the specific name now but we even had a retro to discuss retros. You would think that is a bad joke from some satirical tv show but nope. we did it sincerely.

but anyway, I noticed that obv the scrum oriented ppl love meetings. so do some business. but I noticed there are devs and QAs that absolutely love meetings. they tend to be the weaker devs. I think they enjoy meetings bc then they can avoid dev work and it gives them an excuse. oh sorry couldnt code yesterday, had meetings

anyway, I hate meetings

I dont do scrum but more meetings, especially cross-department meetings, have helped a lot.

I have a 1x a week engineering meeting, a product/eng meeting with managers only, a sales/marketing meeting, and then a bunch of small 1 on 1’s or impromptu standups for issues that come up day to day. We’re a really small shop tho. I could see meetings being a necessary evil for a large company.

That said your system sounds absurd tho and im really curious where you work

I cant write a lot about my job here but funny update while we’re on the topic - the problem child chick literally *quit* (with no job lined up) over my 1x a week eng meeting. Lol. It’s a 20 minute standup. She tried to pull a “him or me” thing and they just said fine quit and she did.

Worked out great for everyone because they wanted to let her go for like, 2 years. Of course there was more to it - I think her major objection to the meeting was it was an attempt by me to finally implement tasks tracking across our eng team and it became extremely obvious after 3-4 weeks that she wasn't getting any work done. Even really, really trivial stuff. When asked if she was blocked/stuck she just wouldn't participate or talk to anyone but my engineering manager and he was at a loss too. I fed like 3 months of data into my PM tool the other day, finally using those now that I have more freedom to do what I want, and saw she didnt do a piece of meaningful work for that entire period. Like holy crap man. Of course I knew it was going on, but I didn't directly manage her, my boss did, so it was just really glaring seeing it jump out at me like that. So I think that's why she fought it so hard.

I don't remember the details, but I think I heard on a podcast that it literally started out as a joke.

cross department meetings for an entire scrum team is bad imo. I dont need to go to that meeting. the tech lead and/or the business person can go and figure that stuff out and report it back to the team.

meetings are just bad in general. they take away from doing the work of actually delivering so called "business value" which is features and functionality for the app. that should be the focus - making the app better with more features or better usability. thats it. scrum makes you focus on doing scrum and not on actually building something. its simply impossible for me to believe that a framework that puts the entire team in meetings for so many hours every week is good for creating good software effeciently.

This is the best case for agile imo - it keeps people from slipping through the cracks.

Not just malcontents like your BFF here. When I worked at a waterfall place in the early 2000s after a while the project went into maintenance/smallish new features mode and I got bored. I'd dick around for weeks doing nothing - then rush to get it all done at the last minute. And of course I'd feel guilty about that and it would stress me out. Not to mention quality suffered.

My next job was my first agile shop. I really enjoyed the daily standups. They kept me motivated and prevented me from getting too far behind. YMMV - not all devs are as immature and procrastination-prone as me. But I know there are plenty like me who are otherwise very productive if you keep some guardrails around them.

I've also come to realize I'm motivated by talking things out. When I can't get the motivation to get started on something - I try to go have a deep dive with one of the other devs on some concept - then I come back a lot more motivated. Standups help give some verbal motivation and spur more in-depth side conversations. On my first job the other key dev who I worked with on most things and sat next to me - never wanted to talk - made obvious by his body language that I was disturbing him. That sucked. I get that we all need to concentrate sometimes. But he was always like that.

You can debate about all the scrum-nazi stuff. Retrospectives have always seemed kind of dubious to me. Sprint-planning is painful but I think overall worth it. But standups and testable tasks to me makes all the difference in the world vs. waterfall/go off in a cave for weeks at a time.

talking things out is helpful to me to an extent. we just beat it all to absolute death. multiple refinement meetings every week and then a sprint planning meeting. now we are gonna have these quarterly or maybe bimonthly planning meetings.

like, we go in circles about how things work and what requirements should be with the entire team there but it would be way faster and more efficient if a single dev just sat down with business and figured it out.

Yeah those don't motivate me. It's the architectural conversations that motivate me.

Yea i mean i have an engineer that is exactly like suzzer. He wants daily standups because without them he gets lazy. His main complaint is that i dont do enough meetings.

1x weekly team standup isnt very demanding though in my opinion. My cross department meetings are just managers and before we had them regularly it was such chaos.

standups are fine. they should take 10 minutes and every once in awhile go to 15.

what I cant stand are constant refinement and requirement meetings with the entire team. they take a ton of time and you end up going in circles and beating every little thing to death bc of all the ppl. or, if you dont care, then it wastes your time bc you could be working.

and then the constant "retro" meetings that talk about all the process crap and usually end up with and "action item" to create more process. or they end up as some sort of passive aggressive finger pointing as to why something took too long or became a bug and the dev involved needs to prostrate themselves and ask forgiveness.

just tell me wtf you want and let me code it.

Victor -- my previous employer hired a bunch of SAFe consultants and went all in. Run, and quickly.

Have fun at your quarterly PI (program increment) meetings where you waste literally the entire programs time doing planning for several days.

Have fun being told you didn't get anything done because everything got done except one thing.

Have fun pair programming on things that barely take one person let alone two.

Yep we are doing the planning meetings now. Pure torture.

And those other 2 have already been occurring. Can't pick up more work. Gotta pair.

Still best job I've ever had.

@victor
Caveat: I am truly empathetic to your posting on scrum and agile.

Think of it from a management perspective. Managers are aware for the most part that software projects can get really screwed up. So of course management wants to avoid disasterous outcomes. This is especially true when they’ve been involved in software development disasters. If management can get constant and accurate feedback about the state of software development effort they have a chance to correct problems early and can get an accurate assessment of progress. Agile is intended to provide that.

Yea. And Ive seen the complete polar opposite of what victor is describing and it is completely terrifying

I guess we do. I work on 2 projects as a FE dev and we have:

Product A:
unit tests: 5090 (8 sec)
func tests: 184 (5 min)

Product B:
unit tests: 849 (takes 15 sec)
func tests: 298 (5 min)
E2E (QA maintains those) tests: 402 (30min - 40min)

What are func tests to you? Is that like integration tests?