just want to address this bc it makes me look bad but it is not really an accurate view.

yes, I copied the methodology, but it was not necessarily wrong. the tests worked properly and did the necessary testing. in fact, they followed the angular testing documentation. https://angular.io/guide/testing

for various that I was not aware of at the time we are moving away from that methodology. again, thats fine with me. and I was happy to be shown the preferred way to structure the tests and rewrite them.

my problem was that I was tasked with rewriting all of the tests on the page. tests that I did not write or even touch. test that tested features that I did not write or alter.

still, I would not have had a problem with that if I had been given a story card so that I could get some credit for the work of rewriting a 300+ line spec file.

and yes, in the grand scheme it really is not a big deal and I shouldnt whine. but ya know, perspective is not always easy.

I'm just curious, how much effort was involved in re-writing the other tests?

took me over 2 hours and I needed to enlist the help of one of our angular consultants. so ya, no big deal really.

anyway, I learned a ton and I really dont mean to whine this much. it was surely good for everyone in the short and long run. just not optimal. and it was the combination of multiple annoyances and slights that put me a bad mood.

You can whine to us all you want, don't tell us your name or where you work and change some details so it's not easy to backtrace you. But no one likes people who just complain at work, don't be that guy. If the task took longer than expected because of the extra tests to clean up bring it up at standup and let them know if it's going to impact the rest of your sprint, it should show in the burn down if you add a task for it with the extra hours you spent on it, but really two hours should fit into your original estimate.

Is this "story points" / "task credit" a common thing for people?

It seems generally quite bad. Like just a step above measuring productivity by lines of code.

My impression is that he wants credit for doing the work, in Agile that is usually a story or a task on a story. Nothing wrong with letting people know what your work load is, but 2 hours may be pushing things.

Right, but the "# of stories" a person does or "the sum of the size of stories" isn't the right way to track that.

Just as an alternative, the communication about the work to refactor the tasks could happen in lots of ways - in a daily standup/scrum where he mentions the task took longer because he needed to update the tests.

Correct, a person's velocity doesn't mean anything outside of the scrum team and shouldn't be used as a metric for anything but agile planning.

I should probably add that I don't actually believe velocity is that meaningful (Although I don't think its a problem to track it and use it for planning - as long as you don't spend hours debating point values of cards). I don't believe you get enough data points to actually have meaningful numbers. And even if you did, it would still be super noisy - so not all that useful.

There's a lot of variability in team changeover / non-team interruptions / unexpected work / estimating error / etc and you get like one data point per week or per two weeks.

I agree, it works better with long standing teams who have been working in the same space for a while. I believe agile's short iteration cycles and constant feedback loops in stand ups can help mitigate some of the errors in the numbers, but does require buying from all the members of the team.

In my old job we used story points completed as a performance metric. It was dumb but then all attempts to track performance in that job going back over a decade had been equally dumb or dumber. It worked out OK mostly because the actual managers didn't take it too seriously. But there was a requirement from higher up in the org to track performance in some quantitative way.

That's pretty standard. Higher-ups want metrics for tracking, and as long as the managers don't put too much emphasis on it, it may be kind of useful. But as soon as the managers start harping on it, devs start gaming the system and getting stressed over stuff that has nothing to do with finishing the job correctly.

Best metric I've seen is to see who's a workhorse and who's not contributing as much is code checkins in git. But you'd never harp on devs for that.

Also as long as managers aren't completely out of the loop - they know how the best/hardest-working devs are. They only need to hear "well we better ask X about that" a few times to know X is a key dev.

I think it is general knowledge among agile literate people that you shouldn's use points or tasks as credit, but its incredibly tempting for higher ups to use it. And the higher you go, the lower agile literacy becomes in my experience. SP's might be an ok-ish measure of intra-team performance (for continuous improvement), but using them across teams is terrible and only encourages point-inflation.

In the end, all performance metrics can be hacked by savvy employees. So the trick for management is to lie, say they don't measure them, then do it anyway.

Anecdote: a local game company was downsizing. They had 400ish employees and needed to get down to 250. They literally sorted people in order by their ticket completion rate, drew a red line at the 250 mark, and fired everyone below the line.

This.

I think some of you guys should look for better places to work.

Story points shouldn't be used for intra-team performance either. It forces you to either put a point value on everything (which is a massive waste of time) or else to implicitly admit that some work isn't valued - typically code quality and correctness. The motivation becomes to do just enough to call the story complete - and not to make things better / avoid bugs. It also puts pressure on people to not do other important things like: recruiting / self-improvement / people management / code reviews / etc.

And again, even if all of that is covered, its based on a 'metric' that has a crazy amount of variation and a small sample size. It's just a recipe for badness.

The trick for management is to do their job and not rely on quantitative metrics that are terribly flawed and create ****ty incentives. There are lots of ways to know who's doing well and who's doing poorly. The issue is just that caring about that takes a lot of work.

Victor: [I have skimmed a bit]

2 hours seems trivial as hell to re-write tests.

Definitely do not start making a big deal of this stuff yet, less than 1 year right? Nobody likes the "new" employee who sighs loudly at their desk when confronted with "annoying" or suboptimal or mundane tasks, let alone the one who complains about it non-stop.

If you have regular manager one on ones you can bring up some grievances, but slowly.

For the most part as suzzer said just treat it all as a learning experience and take your "lumps" if that's what you have to do. Once you have a more secure, medium-long term position there and/or you're ready to think about jumping somewhere else, you can start to be more assertive. (This would just be general job advice.)

ya I havent complained at all or even sighed. I was never gonna actually make it an issue in the way I have presented it here. more like, after I finish this work, I was gonna ask for a different type of card.

A semi-relevant comment irt to deliveries and uh... testing.

A contract from a few months ago contacted me saying that a list of 5 things worked before I fixed issue A and B.

I can stretch my imagination to the edge of the universe and I'd have no clue how that happened. There is a difference between calling the prior programmer a moron (he is, but I digress) and just saying "I don't see how that could have happened" and answering if I can fix it.

I see it as my responsibility to do good work, and hopefully send something that is tested, or at least glaringly obvious in its function.

And this is the issue, you can either look at your role as an employee or as a responsible entity. An employee sees his role as well-defined, one that includes taking the good work for himself, points fingers at others, and feels like parts of his job shouldn't be his responsibility. This is the single largest divider between managers and employees, IMO. A manager just gets **** done, eats dog food, and makes sure his employees are doing work that make them happy.

Of course, if you want to do things that interest you, start your own business. Oh right, that's 90% boring stuff, lol.

I'm getting a couple crashes per day where for no reason my cpu climbs out of control until it crashes. Normally its at about 35%. Any ideas or where to start? Node lts app.

So devs that just STFU will get the best projects to work on and get the big raises. Management will figure out who the valuable devs are left to their own devices. Hmmm .....

Lol Adios.

have you looked at your node logs?
have you been watching with top to see what's using all the cpu?

we've seen it spike when someone was brute force attacking the box
look at your security logs for hack attempts and block the ip's they are coming from

phew

Talking more about the first year at a first job, especially for a bootcamp graduate, and referring more to complaining rather than tactfully displaying your work. But yea depending on the org structure, frequency of meetings, your personality and your manager's, org culture, etc., it may be helpful to do it in a more obnoxious way.

I am sure you can Google search so I apologize if you have seen or are familiar with the link below.

https://www.dynatrace.com/blog/how-t...es-in-node-js/

Sent from my SM-G900R4 using Tapatalk

When algorithms go bad.

Has anyone used Phoenix/Elixir whether its in a pet project or something powering a real business? Thoughts, concerns, etc. I've been playing around with it lately. Hoping to use it exclusively for sockets. Right now, any page that requires updates post page load (on our app) is just polling the relevant endpoint, I was hoping to replace that with sockets in Phoenix.