I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.
I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter!
These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful experiences.
Apparently whatever it is they're doing involves a lot of meetings and little actual flexibility? The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Every team and every business is different and you have to iterate to arrive at whatever will work best for you. That's possibly the one most important point, IMO. Dropping the things that don't work is a key part of that!
Eric Brechner of Microsoft (of all possible places...) gives a great talk on his team's approach, and I've had good experiences using it as a starting point: https://www.youtube.com/watch?v=CD0y-aU1sXo
But again, every team is different. Even the greatest possible theoretical approach is only a starting point.
And like with Switzerland vs North Korea, I guess the key thing is how much ownership of the process those subjected to it have?
> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?
Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.
> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP
Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.
In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions.
(Your question is not dumb, BTW. The pithy answer is: UX matters, but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing to get a desired outcome, and that's tricky to express in text. Also there will always be some people for whom a new mental model just doesn't work. That doesn't make them dumb either, at least provided they have the wisdom not to petulantly piss in the cornflakes of those who get a kick out of how much better the new thing works for them.)
I’ve done it multiple times without much effort. Or skill. Really it was a skill issue and I tried things that I thought would work but apparently don’t.
I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!
I'm glad to hear you never encountered the kind of quagmire that can occur around e.g. non-trivial conflicts while rebasing a chain of git commits. On large enough codebases, those can be common.
> long tradition of naming theorems after the second person after Euler to discover them.
Some of my favourite examples of this are:
- The "Lambert W" function, discovered by Euler to solve a problem Lambert couldn't solve
- "Feynman's trick" of differentiating under the integral[1]. Invented by Euler. Done by Feynman because he says in his autobiography he learned it from "Advanced Calculus" by Cook. So now it's called "Feynman's trick". Like dude it had been around for 250 years before Feynman did it.
- "Lagrange's notation" for derivatives. Yup. Euler.
- The "Riemann Zeta function". Of course discovered and first studied by Euler. Riemann extended it to complex numbers though.
Sorry, hard disagree. Bad faith entirely precludes debate because debate is about updating and improving a position through exchanges of views, and that starts with the ability and willingness to budge from said position in the first place.
Which incidentally means that there is by definition no debating tenants of a position that can't survive one minute of good faith review. They're not there to debate. They're there to drown out and silence a truth about material reality that they're upset about.
Greece defaulted after the previous, right wing government falsified the country's accounting, but by all means, don't let reality get in the way of your ideology.
Going ahead without asking is a sure recipe for having the client tell you "Sorry, that's not at all what I want" and then having to start over again. Your creatives ask questions for a reason. What is it that made you pick this specific draft out of the slop pile as a good match for your brand? The color scheme? The composition? The atmosphere? The line art style? If you expect your creatives to just magically guess, and then get frustrated when the output is not what you had in mind, then it's hardly your creatives' fault.
Yup, people aren't mind-readers. And it can be very hard to predict what bits the client cares about and what they don't, so it's worth biasing towards asking (though I think it's worth emphasizing that 'I don't care, you choose' is a valid response). The worst clients are the ones who can't express what they want in the first place and then reject output without explaining what it is they did or didn't like about the result.
That said, it can be very hard to be a good client. Writing requirements (whether for art or engineering) is something that on average, people are very bad at. And often you will only find out you cared about something after you see it (oh god I am so bad at this, especially because it's often delayed, so I will go 'looks good, no notes', then like a day later go 'oh wait, actually...'), which is why having a healthy dialogue and rapid feedback loop is so valuable to any project.
reply