|
Fellatio del Toro posted:So my boss who seems to not understand that we are capable of doing our jobs from home and are in constant contact with each other on Slack came up with a very dumb scheme where we get a daily, randomized phone chain and everyone has to call each other in the daily sequence until it ends at my boss It sounds like you just need to have a channel for everyone who isn't your boss, to say that boss called, everyone do their updates (like standup??????????), and designate the person that calls boss back later.
|
#
?
Apr 17, 2020 04:17
|
|
|
|
| # ? Jun 1, 2024 12:43 |
|
|
New Yorp New Yorp posted:Keep your codebase fully integrated and configure which features are accessible via flags. It can be as complex as you need (i.e. user groups and only certain groups have the flag on) or as simple as you need (if this configuration variable/environment variable is set, unlock feature x). If you do base this on user groups you have the basics ready for allowing A/B testing. Put two different versions of a functionality in the app, which can be swapped between by a feature toggle, or enable something that changes the look and feel with a feature toggle, and then split the setting 50/50 among the users. Or give a small sample of the users the new functionality and see how they react to that. Based on their reactions you can find out what works and what doesn't and decide which functionality to add to the standard product. Of course you do need some kind of feedback mechanism from the users for that. That can be usage metrics or a literal feedback/question page somewhere in the app.
|
|
#
?
Apr 17, 2020 06:58
|
|
|
just dropping by to say LaunchDarkly is great. just works
|
|
#
?
Apr 17, 2020 13:47
|
|
|
Volmarias posted:It sounds like you just need to have a channel for everyone who isn't your boss, to say that boss called, everyone do their updates (like standup??????????), and designate the person that calls boss back later.
|
|
#
?
Apr 17, 2020 17:08
|
|
|
you sound like my coworker who tries to come up with a dumb tech analogy for every situation
|
|
#
?
Apr 17, 2020 19:02
|
|
|
qsvui posted:you sound like my coworker who tries to come up with a dumb tech analogy for every situation
|
|
#
?
Apr 17, 2020 21:35
|
|
|
Progressive JPEG posted:Like an abstraction that can’t be aligned with the implementation? Like a linker that tries to reference the wrong architecture for a library
|
|
#
?
Apr 18, 2020 18:45
|
|
|
Like a Makefile and then something bad happens!
|
|
#
?
Apr 18, 2020 19:03
|
|
|
Like a car with a transmission and wheels and such
|
|
#
?
Apr 20, 2020 02:05
|
|
|
Does anyone have a link to that article about pointing stories and bugs, and the guy ran simulations and decided that all bugs are the same and shouldn’t have points? I know that’s vague, but I saw it on here once and I can’t find my old bookmarks.
|
|
#
?
Apr 23, 2020 18:50
|
|
|
A bug is just a story that was already accepted but should have been rejected. You already got the points for it.
|
|
#
?
Apr 23, 2020 18:53
|
|
|
https://twitter.com/krisajenkins/status/1253294613663711235
|
|
#
?
Apr 23, 2020 18:58
|
|
|
Bongo Bill posted:A bug is just a story that was already accepted but should have been rejected. You already got the points for it. If your codebase is greenfield and has been wholly developed with stories that were pointed, sure. What's the theory on pointing bugs in code which was produced prior to adopting that process? That was never sufficiently explained to me by the one project manager that implemented this practice.
|
|
#
?
Apr 23, 2020 20:05
|
|
|
lifg posted:Does anyone have a link to that article about pointing stories and bugs, and the guy ran simulations and decided that all bugs are the same and shouldn’t have points? this one? https://apenwarr.ca/log/?m=201712
|
|
#
?
Apr 23, 2020 21:28
|
|
|
Yes! Thank you!
|
|
#
?
Apr 23, 2020 21:33
|
|
|
That was a good read, thanks!
|
|
#
?
Apr 24, 2020 01:30
|
|
|
csammis posted:If your codebase is greenfield and has been wholly developed with stories that were pointed, sure. What's the theory on pointing bugs in code which was produced prior to adopting that process? That was never sufficiently explained to me by the one project manager that implemented this practice. Woah, hold up, are you implying that perhaps we should not slavishly adhere to rules???
|
|
#
?
Apr 24, 2020 13:19
|
|
|
That part was explained to me by the project manager and it turns out that yes, we should! 
|
|
#
?
Apr 24, 2020 14:41
|
|
|
Bongo Bill posted:A bug is just a story that was already accepted but should have been rejected. You already got the points for it. I had a manager tell me this who started as a dev so he really should've known better. It is almost the perfect definition of the perverse incentive. If there are "points" for something, people will do/promote activities that generate the most "points". If you don't give anyone points for bugfixing, your overall code quality plummets.
|
|
#
?
Apr 24, 2020 16:09
|
|
|
The day that agile really clicked for me was the day that we gave-up trying to do it.
|
|
#
?
Apr 24, 2020 16:14
|
|
|
agile is still a mystery to me. i don't bother trying to understand its value anymore, i just nod and pretend to know why i'm doing all that stuff.
|
|
#
?
Apr 24, 2020 16:21
|
|
|
Agile is a whole bunch of voodoo whose highest value is convincing management (and certain over-engineering inclined programmers) to accept "small incremental goals" as the unit of project planning and execution.
|
|
#
?
Apr 24, 2020 16:51
|
|
|
vonnegutt posted:I had a manager tell me this who started as a dev so he really should've known better. It is almost the perfect definition of the perverse incentive. If there are "points" for something, people will do/promote activities that generate the most "points". If you don't give anyone points for bugfixing, your overall code quality plummets. If points are tied to any incentives, then it doesn't matter whether you estimate bugs or not because you've hosed up something much more basic.
|
|
#
?
Apr 24, 2020 16:57
|
|
|
Engineering management is absolutely god-awful at managing incentives. That's a hard problem in general, but they're not even trying and I don't think many of them actually understand that that's part of their job.
|
|
#
?
Apr 24, 2020 17:22
|
|
|
FYI incentive systems are just another means of undermining and exploiting workers.
|
|
#
?
Apr 24, 2020 18:29
|
|
|
Points are a measurement. Any measurement that becomes a target ceases to be useful as a measurement.
|
|
#
?
Apr 24, 2020 21:04
|
|
|
ultrafilter posted:Engineering management is absolutely god-awful at managing incentives. That's a hard problem in general, but they're not even trying and I don't think many of them actually understand that that's part of their job. At my previous job where we did SAFe we did a single 2 week long innovation sprint at the end of each PI. They were always disappointed when nobody had anything valuable to show. And oh yeah, there was no incentive, and any projects that showed a modicum of promise never surfaced again. Of course most people used those 2 weeks to tidy up their PI deliverables, but that’s just a small detail. Inacio posted:agile is still a mystery to me. i don't bother trying to understand its value anymore, i just nod and pretend to know why i'm doing all that stuff. Agile is probably fine if you do it correctly? I haven’t seen an example of it being done correctly yet though.
|
|
#
?
Apr 25, 2020 15:13
|
|
|
Bongo Bill posted:Points are a measurement. Any measurement that becomes a target ceases to be useful as a measurement. I completely agree, but I've never worked at any company that had a numeric points scale where they didn't become a target. In the situation I mentioned, each dev was responsible for a certain amount of "points" per sprint, and at the end of the sprint, the number each dev accomplished was publically announced in the end-of-sprint meeting. There was even a leaderboard. You can imagine what effect this had. At my current company we only have "small", "medium", and "large", and mostly it seems to map to "amount of uncertainty around size" rather than size, which makes arguing with management about breaking down "large" tasks fairly effective.
|
|
#
?
Apr 25, 2020 15:24
|
|
|
I basically like Agile and pointing, but management needs to buy into the underlying philosophy. If a company wants to do Agile, then every employee at every level needs to go through a day of training, to set a base level of understanding and vocab. (I saw this done at AthenaHealth, and it really helped.)
|
|
#
?
Apr 25, 2020 18:38
|
|
|
Points are fine as an estimate of roughly (like maybe 80% accurate if you're very good at estimating) what amount of planned work could reasonably get done in the next time step. The bigger your time step is the worse this works. At whatever point you use it as a team or individual performance metric it breaks horribly. Engineering leadership try to use it as a 'look I'm doing good job' metric so they want it to continuously increase. Which sure, make it a metric, it's an arbitrary scale and it will increase if you yell at your subordinates about it enough. It's not measuring anything in particular but hey number go up.
|
|
#
?
Apr 25, 2020 18:48
|
|
|
vonnegutt posted:I had a manager tell me this who started as a dev so he really should've known better. It is almost the perfect definition of the perverse incentive. If there are "points" for something, people will do/promote activities that generate the most "points". If you don't give anyone points for bugfixing, your overall code quality plummets. the problem here isn't about pointing bugs or not, it's about using points as a proxy for individual performance. if anyone is using points as anything other than a measure of velocity to estimate feature delivery timelines or dev capacity you're hosed anyways
|
|
#
?
Apr 25, 2020 20:43
|
|
|
If you ever feel like the dev tool you're using is a hammer in want of a nail, just remember that the maps for Pokemon Gold, Silver, and Crystal were made in Excel.
|
|
#
?
Apr 25, 2020 20:46
|
|
|
Yeah, in the places I've worked where agile has been useful, it's always as a good tool to budget the team's man hours (whether the units are hours or days or t-shirt sizes, developer resources are what's being budgeted). The more stable your team is (the lower the churn), the better. Unfortunately, the temptation from PM to use/abuse the numbers seems to be irresistible.
|
|
#
?
Apr 26, 2020 05:52
|
|
|
Pollyanna posted:the maps for Pokemon Gold, Silver, and Crystal were made in Excel. I want to know more about this. Where did you find this out?
|
|
#
?
Apr 27, 2020 06:40
|
|
|
the talent deficit posted:the problem here isn't about pointing bugs or not, it's about using points as a proxy for individual performance. if anyone is using points as anything other than a measure of velocity to estimate feature delivery timelines or dev capacity you're hosed anyways if you’re in a dysfunctional team it starts to feel real unfair when one or two people are clearly contributing the majority of points/velocity/whatever while others are if anything just generating more work, but managers refuse to look at individual point performance because that’s not what they’re for. However, this falls into the realm of “being hosed anyways”
|
|
#
?
Apr 29, 2020 11:26
|
|
|
Prism Mirror Lens posted:if you’re in a dysfunctional team it starts to feel real unfair when one or two people are clearly contributing the majority of points/velocity/whatever while others are if anything just generating more work, but managers refuse to look at individual point performance because that’s not what they’re for. However, this falls into the realm of “being hosed anyways” It is unfair, but using points to measure performance can be gamed incredibly hard and will inevitably gently caress you when your underperformers take as much low hanging fruit as possible or block you on 8 pointers while you're stuck fixing bugs (which may not have points at all), not to mention the other bad situations it can lead to (compensation dictated by points closed in a year, e.g)
|
|
#
?
Apr 29, 2020 20:53
|
|
|
If there's a severe imbalance in how much everybody on the team is contributing, and it's causing a problem, and management can't tell there's a problem just by paying attention, individual productivity metrics aren't going to reveal the problem (though they will create an additional, worse problem).
|
|
#
?
Apr 29, 2020 21:56
|
|
|
I have to rant for a second. I’m half way through a six month project that has a chance of delivering on time, but one of my key employees, Ed, is part time on another project that’s been in a death spiral for three years. My boss is devoted to getting this other project finished. (Note: He partially caused the problems.) Two sprints ago my boss took Ed away from my project completely, “just for one sprint” to finish this death spiral project. Now when I ask about timelines and getting Ed back, I’m met with “I don’t understand why you can’t build your web app in a month with who you have. Let’s refactor the code to get a magical 10x speed up in dev time.” (Paraphrasing.) I don’t have an ending to this rant. My boss is a brilliant programmer and architect, but really shouldn’t be anywhere near management or project management or any of it.
|
|
#
?
Apr 29, 2020 22:17
|
|
|
Ask him why they can't do that for his project
|
|
#
?
Apr 29, 2020 22:39
|
|
|
|
| # ? Jun 1, 2024 12:43 |
|
|
taqueso posted:Ask him why they can't do that for his project "We're doing that right now  "
|
|
#
?
Apr 29, 2020 22:46
|
|