281–290 of 308 posts
Earlier quoted context omitted.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
Oh yeah. I've been there multiple times. I meant the only realistically productive way.
Earlier quoted context omitted.
Just a word about the Marine analogy in case some manager sees this and gets all excited: Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature. It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enorm…
I agree with this perspective - the closest thing I've seen to this sort of "external enemy" approach in tech is engineers/SREs responding to an outage/critical issue. Good teams will get into a state of flow where people are subdividing work, prioritizing, working as a cohesive unit. In that case, there is a clear objective (get things back up and running) with a clear enemy (that DDoS/database/down payment gateway/…
As long as everyone is "on the same wavelength" (I am sorry, I cannot quantify that better), it is basically effortless. You need someone to chop onions, and a few minutes later, they're just there. You sense that someone needs a filleting knife (they're just about to place a fish on a cutting board, or something similar that signals "this is the next tool needed") and you're close to it, so you make sure it is there for them (handle first, of course).
It is a very similar feeling to a well-integrated infantry unit making an entry into a presumed-hostile building, minus all the adrenaline.
Earlier quoted context omitted.
I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
Code reviews sometimes seem like a micro-management tool: they often boil down to quibbling over things that are quite superficial, while simultaneously ignoring or missing big problems that lurk under the surface. Without some sort of automated linting and code style enforcement, this is what happens in code reviews. They serve as a reminder to the developer that his work is not trusted, and someone else must keep a…
The way to propose a change, in a "good way" (I am assuming here that no one has unilateral capability of merging to master, and things thus have to pass through review), to my mind, involve doing a few things.
keep the change small ("small" here is a very fungible quality, but "probably less than n * 1000 lines") does NOT mix "fix bug" / "add feature" / "refactor" (arguably, there are cases where feature-adding and bug fixing are instrinsically linked, let those through) has a change description detailing the why of the change (the "what" is the change itself)
As a reviewer, your task is not to critique the design (that is why everyone agreed on a design doc up front, no?). It is OK to review the structure of the code, though.
Hopefully, you have a "run this through a linter / style-checker" integrated into your pipeline, so that should be pretty much already done. But, if there are a few things left over, it is OK to point those out.
It is OK to point out that things that should be (but aren't) tested should have tests. If you can spot an edge case that isn't (or doesn't seem to be) tested, ask for that to be tested, also.
People need to be permitted to take the time to do a review.
With these things in place, a review should be pretty quick (at the pace of up to a few lines per second), and most of the time frictionless. But, it does require some discipline, both from the writer and the reviewer.
Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…
I have ADHD and pairing is liberating. I don’t need medicine, I can stay focused and motivated for years . I’m seriously worried that I’ll have to get back on medicine because the pairing opportunities in the industry are becoming so far and few between. If anyone has recommendations I’m all ears (and eyes)!
At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
Earlier quoted context omitted.
> The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. And yet, my experience has been the exact opposite. > It's much, much more effective for me (and most of the people I've ev…
> But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it? I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert aga…
And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work.
For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that.
Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."
At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
Earlier quoted context omitted.
>people who refused to use deodorant What is it with people in our field that this is so commonplace? There are few things worse than a room full of IT people with the windows closed. "It's the smell" as Agent Smith said.
There is no deodorant that can suppress my BO, I just end up smelling like BO with a hint of deodorant. Luckily for my coworkers I am usually remote.
I then learnt several tricks on how to wash my clothes properly, and the problem has gone away completely. Butyric acid stays in your clothes for a long, long time unless you use the right chemicals. I went from horribly smelly guy to no odour overnight.
I now soak all my T-shirts in a bucket with baking soda, rinse them and then put them in another bucket with diluted vinegar, then finally, normal wash. If you have white "pit stains" from deodorant, you want to clean that stuff off. There are special cleaners for that. I do this once every 6 months, and it's enough to keep it all fresh.
Being smelly all the time is a major knock to your self confidence and self image, it's worth the 30 minute hassle twice a year!
Earlier quoted context omitted.
Yeah. I almost want to say it's the only realistic way to onboard. Depending on the codebase, I feel it's literally 10-50x more productive.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I never tried it, so I don't know.
Earlier quoted context omitted.
>people who refused to use deodorant What is it with people in our field that this is so commonplace? There are few things worse than a room full of IT people with the windows closed. "It's the smell" as Agent Smith said.
I stopped using deodorant years ago because I just didn't see the point. If it did what it said on the bottle I'd be fine with it, but it doesn't actually deodorise anything. If you or your clothes are dirty the only way that takes away the smell is to wash, adding another smell on top of it is not a solution. If they want to make a deodorant they should sell bottles of chlorine gas instead, but then they'd have to a…
Earlier quoted context omitted.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would discuss with him like 4-5 times a day sometimes. It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I ne…
I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.