|
A consultant gives an org with no leadership (like mine) or terrible infighting an external thing to point to and say let's all just turn off our brains and do what the "expert" says.
|
# ? Apr 14, 2016 14:48 |
|
|
# ? May 10, 2024 07:11 |
|
Infinotize posted:A consultant gives an org with no leadership (like mine) or terrible infighting an external thing to point to and say let's all just turn off our brains and do what the "expert" says.
|
# ? Apr 14, 2016 15:32 |
|
Vulture Culture posted:Why don't you hire another consultant to address the infighting? Those consultants usually end up electing themselves king.
|
# ? Apr 14, 2016 16:55 |
|
pigdog posted:There are tons of companies doing Scrum wrong or half-assedly. Why pay anyone money when you can read Wikipedia yourself?
|
# ? Apr 15, 2016 21:48 |
|
386-SX 25Mhz VGA posted:I've been on three different teams now "making the transition to Agile," and every one was a poo poo show. I'm curious to know whether anybody has witnessed "a transition to Agile" being accomplished successfully. I have, but it was because of the following factors: - Small team - Small company, privately owned - One person led the charge who had authority to discipline and/or fire people - That person acted as a shield against upper management The team successfully made the transition and followed Scrum for about two years, then the person who drove the change got tired of upper management and quit. Agile was almost immediately dropped by upper management, the competent devs all quit within 3 months, and all of the in progress projects failed so badly that they just outsourced the whole thing to the cheapest body shop they could find. Oh, and one of the owners spent $15,000 sweeping the entire office for bugs after we left. Not software defects, not arthropods, but covert listening devices. But that's probably because I had a friend send an email to my account 10 minutes before I left on my last day that just said "INITIATE PROJECT ARCTURUS. END COMMUNICATION."
|
# ? Apr 15, 2016 22:00 |
|
386-SX 25Mhz VGA posted:I've been on three different teams now "making the transition to Agile," and every one was a poo poo show. I'm curious to know whether anybody has witnessed "a transition to Agile" being accomplished successfully. My first development job we went from full waterfall to full scrum within like 6 months, and it worked out awesome. However, it was being driven by the CEO, and shoved down the throats of the business people whether they liked it or not. They also paid for formal training for everyone, including the business people. The company also wasn't too huge, and was a non-profit education company. Apparently the leads of our development teams at my current employer had a meeting the other day and they decided to have a vote on whether any source control other than vanilla TFS was going to be allowed to be used by the teams. The vote was "TFS FOREVER!" I hate TFS. I've used multiple source controls at previous employers, and TFS is inferior to them in so many ways.
|
# ? Apr 15, 2016 22:33 |
|
What in the gently caress? Why aren't they using git like the rest of the same world?
|
# ? Apr 15, 2016 22:41 |
|
Khisanth Magus posted:Apparently the leads of our development teams at my current employer had a meeting the other day and they decided to have a vote on whether any source control other than vanilla TFS was going to be allowed to be used by the teams. The vote was "TFS FOREVER!" I hate TFS. I've used multiple source controls at previous employers, and TFS is inferior to them in so many ways. If you don't like TFVC, just use git-tf or git-tfs to create a local Git repo that you can sync back to TFVC later.
|
# ? Apr 15, 2016 23:07 |
|
ratbert90 posted:What in the gently caress? Why aren't they using git like the rest of the same world? TFS is a 'scary' thing to move away from when you have a pile of developers who have spent most of their careers on TFS(which tends to be combined in a .NET shop, so tight IDE integration + GUI) and try to put them on not just a jump to DVCS(which itself already requires a bit of re-education) and ALSO lose a lot of that integration. I'm hoping Visual Studio trying to tighting up Git integration will end up making this an easier sell to Management. Right now it's "We are going to have to send the entire development team to a multi-day class to learn this new tool, and we have to migrate projects with years of commit history over to a new repo, and....that's around the point where risk outweighs reward in management's eyes.
|
# ? Apr 15, 2016 23:10 |
|
Remote pair programming: always terrible or can it be tolerable?
|
# ? Apr 15, 2016 23:30 |
|
smackfu posted:Remote pair programming: always terrible or can it be tolerable? "Oh, did the connection drop again or have you stroked out and are no longer typing?" It depends on your connection and the technology used, but it doesn't have to be super terrible as long as you are both land-lined on good connections.
|
# ? Apr 16, 2016 00:09 |
|
smackfu posted:Remote pair programming: always terrible or can it be tolerable?
|
# ? Apr 16, 2016 00:12 |
|
Pair programming with a screenshare is p great imo. I made a tampermonkey script to make jira a lil better today - it colorizes the whole card based on priority. Helps us flag urgent stuff better.
|
# ? Apr 16, 2016 00:16 |
|
386-SX 25Mhz VGA posted:I've been on three different teams now "making the transition to Agile," and every one was a poo poo show. I'm curious to know whether anybody has witnessed "a transition to Agile" being accomplished successfully. A proper transition to Agile takes like a week (followed by a few months of ironing out the quirks), so pretty much by definition any team in the middle of a drawn-out transition is going to be a shitshow.
|
# ? Apr 16, 2016 00:20 |
|
smackfu posted:Remote pair programming: always terrible or can it be tolerable? My current workplace's approach is that everyone works inside fungible remote VMs. So some kind of voice call, plus tmux, plus sometimes vnc (we use vim 95% of the time). I greatly prefer this to the screenshare approach I experienced at a previous job. Although I'd like either better than no pairing.
|
# ? Apr 16, 2016 01:19 |
|
There are days I wonder if I'm the only developer out there who really doesn't like paired programming.
|
# ? Apr 16, 2016 03:08 |
|
Khisanth Magus posted:There are days I wonder if I'm the only developer out there who really doesn't like paired programming. I pretty much hate it... I do a lot of mentoring, so I don't have a problem sitting next to people showing them things, or going over something particularly tricky with someone else... but doing that for any length of time? No, no no no. I need my space and I really don't like anyone enough to spend a whole day like that.
|
# ? Apr 16, 2016 04:44 |
|
I honestly can't imagine doing it. It seems like an amazing way to make sure that you never get into your flow.
|
# ? Apr 16, 2016 05:05 |
|
smackfu posted:Remote pair programming: always terrible or can it be tolerable? i like pairing and all my coworkers are jerks who never leave their bedrooms so i think it is ok. i rarely get to do it though
|
# ? Apr 16, 2016 05:20 |
|
Khisanth Magus posted:There are days I wonder if I'm the only developer out there who really doesn't like paired programming. I like pairing as an occasionally used tool for when two people need to work in the same area of code for some reason or if you want to give someone structured exposure to something. The key word there is occasionally. I have a friend whose job involves pairing every day and that would make me crazy.
|
# ? Apr 16, 2016 05:48 |
|
Cuntpunch posted:TFS is a 'scary' thing to move away from when you have a pile of developers who have spent most of their careers on TFS(which tends to be combined in a .NET shop, so tight IDE integration + GUI) and try to put them on not just a jump to DVCS(which itself already requires a bit of re-education) and ALSO lose a lot of that integration. I'm hoping Visual Studio trying to tighting up Git integration will end up making this an easier sell to Management. Right now it's "We are going to have to send the entire development team to a multi-day class to learn this new tool, and we have to migrate projects with years of commit history over to a new repo, and....that's around the point where risk outweighs reward in management's eyes. Git is hard to learn for people that don't have DVCS experience, period. No GUI is going to make it better, although some GUIs are better than others, and the Visual Studio GUI is admittedly not great. I do Git training for .NET developers occasionally and my approach is to start out with everyone on the CLI to learn the basic concepts and plumbing. At that point, they can navigate the IDE just fine, even if it's clunky. That said, Microsoft is aware that the Git GUI in Visual Studio isn't great. Too much clicking around to do common stuff. That's one of the reasons why VS 2015.2 has a branch management interface that's part of the toolbar on the bottom right of the window when you're working out of a Git repo -- less clicking around to create or checkout branches. Also, I hate to be pedantic (that's a lie, I love being pedantic), but the centralized VCS in TFS is called "TFVC". The distinction has to be made because TFS is a lot more than a SCM tool, and it can host Git repos as well as TFVC repos.
|
# ? Apr 16, 2016 05:59 |
|
I'm glad to hear that people have success with remote pairing. Gives me some hope. For tech, we are using ScreenHero, which has worked really well so far. Yeah, if the connection is bad, the mouse/keyboard control gets too laggy to use, but most of the time it's okay. Ironically it's better if we both work from home rather than one of us use an office connection. Annoying that ScreenHero has had closed signups since they got acquired by Slack a while ago. (You can still be invited by a current user though.) My main complaint with pairing remote so far is that it's way easier to "cheat" on the pair. Like the person not sharing their screen can check their emails, or respond to an IM, or research something while they aren't running the show. I don't even really blame them that much, it's hard to have good discipline. Especially when there is some icon bouncing in the menubar.
|
# ? Apr 16, 2016 14:42 |
|
Hang on, I don't get what pair programming is if you can't simultaneously give advice and also check your email.
|
# ? Apr 16, 2016 17:28 |
|
For our in office setups, the pairing setup is one computer with two displays hooked up in mirroring mode, and two keyboards and two mice. So you don't have another machine to check your email or anything.
|
# ? Apr 16, 2016 21:58 |
|
smackfu posted:For our in office setups, the pairing setup is one computer with two displays hooked up in mirroring mode, and two keyboards and two mice. So you don't have another machine to check your email or anything. This sounds awful. I much prefer the "screen share" and just trade off occasionally.
|
# ? Apr 16, 2016 22:21 |
|
Why is it like that? What language/platform is it? That sounds really unpleasant.
|
# ? Apr 16, 2016 22:22 |
|
Plorkyeran posted:A proper transition to Agile takes like a week (followed by a few months of ironing out the quirks), so pretty much by definition any team in the middle of a drawn-out transition is going to be a shitshow. What do you consider that transition then? I'm just trying to go from zero to PO writing good user stories with proper acceptance criteria plus teams going through several refinement cycles to get a properly sorted backlog in a single week and I can't do it.
|
# ? Apr 16, 2016 23:16 |
|
smackfu posted:For our in office setups, the pairing setup is one computer with two displays hooked up in mirroring mode, and two keyboards and two mice. So you don't have another machine to check your email or anything. Some of our stations are set up like that, others are just one big screen hooked up to two keyboards and two mice/trackpads. But a lot of people also bring in personal laptops or have work-provided ones that they use for e-mail/slack on the side.
|
# ? Apr 16, 2016 23:47 |
|
I'm convinced that most of the productivity benefits of pairing come about because you don't want to leave your partner hanging by taking a micro-break to check your email or sports scores or browse SA or whatever. So you end up actually working straight through, which is why it's both more productive and also feels more draining.
|
# ? Apr 17, 2016 09:09 |
|
Jabor posted:I'm convinced that most of the productivity benefits of pairing come about because you don't want to leave your partner hanging by taking a micro-break to check your email or sports scores or browse SA or whatever. So you end up actually working straight through, which is why it's both more productive and also feels more draining. I think there's some immediate code review and rubber ducking benefits as well, but the social pressure is definitely also a big factor.
|
# ? Apr 17, 2016 12:12 |
|
It's also really great for learning about things from the other person. I feel like I learn a lot more sitting there being able to ask "why do you want to do it that way?" as we're writing it than tracking someone down to ask questions when they're no longer thinking about it.
|
# ? Apr 17, 2016 16:40 |
|
Axiem posted:It's also really great for learning about things from the other person. I feel like I learn a lot more sitting there being able to ask "why do you want to do it that way?" as we're writing it than tracking someone down to ask questions when they're no longer thinking about it. For me, that happens in code review
|
# ? Apr 17, 2016 16:41 |
|
Steve French posted:For me, that happens in code review Yes, but there's nothing quite like "Hey, can I try writing this [thing to interface with framework they're familiar with and you're not]?" when it comes to getting some hands-on experience and learning a framework. Though also at my last job, the code reviews were a joke. At my current job, we generally treat pairing as its own code review, so YMMV. Pairing is incredibly socially draining, though, especially for introverts like me. While there are things I like about it in terms of learning, and the rhythm you can get into with people you're at similar skill levels with, I could in the end take it or leave it. But I'll never do remote pairing. That just sounds like pulling teeth.
|
# ? Apr 17, 2016 16:51 |
|
Axiem posted:Yes, but there's nothing quite like "Hey, can I try writing this [thing to interface with framework they're familiar with and you're not]?" when it comes to getting some hands-on experience and learning a framework. I've never worked anywhere that pairing was done regularly as a matter of course, so I won't pass judgment on the practice entirely without too much direct experience. But I certainly don't see it as an acceptable substitute for code review: in particular because very often code is reviewed by more than one person. I might be making a change that affects two different areas, so I'll have it reviewed by domain experts in those two areas, and also share it with a more junior engineer so that they can learn from it.
|
# ? Apr 18, 2016 03:58 |
|
Correct pair programming can be understood as "inline review," but it's clear that this comparison only extends as far as informal code reviews, not the formal kind.
|
# ? Apr 18, 2016 04:01 |
|
Bongo Bill posted:Correct pair programming can be understood as "inline review," but it's clear that this comparison only extends as far as informal code reviews, not the formal kind. Yeah, my point was mainly that there is often benefit in having more than just two people look at the code
|
# ? Apr 18, 2016 04:21 |
|
To me, paired programming is hanging out and programming together. Being exposed to stuff that you may not know and getting to talk about it Some of the descriptions here sound super rigid.
|
# ? Apr 18, 2016 04:27 |
|
Whenever I hear about strict Pair Programming, I think about Bitbucket's Spooning
|
# ? Apr 18, 2016 04:34 |
|
Also, whats the point of being that strict? The more strict things get the less creative/innovative I get. My best ideas come from letting me let my mind wander for a bit: a walk, driving, playing guitar, etc
|
# ? Apr 18, 2016 04:39 |
|
|
# ? May 10, 2024 07:11 |
|
Really they only pair programming I've ever done is to figure out a problem where both of us wrote parts of the code that's responsible for that. To be fair though I've never worked in any environment that had a methodology that was consciously brought to life, so asking anyone to co-develop a piece of software never went beyond a "how would you do this?" questionnaire.
|
# ? Apr 18, 2016 08:40 |