@Donald.McLean If I could ask for some of your time - what do you think the benefits of pair programming are? I do a lot of front-end web stuff and I don't like the whole idea of someone looking over my shoulder while coding. It's not a pride thing, but more of a "someone is breathing down my neck" thing.
@ARedHerring we have been able to do that for new projects. The devs who started working here after we decided to to automated tests and unit testing don't know any different.
but yes, trying to go back and retrofit good testing methodology into a legacy project with legacy devs is mostly a lost cause.
@CaptainObvious This is my submission to the community challenge. It's pretty OOP based, so I'd welcome people giving answers about the way I handled that even if Python looks like a hot mess to you.
@ARedHerring If you're feeling that, then you're doing it wrong. Pair programming is more about the constant dialog between you and your partner than anything else. And the keyboard should pass back and forth frequently.
@skiwi Here's one. Let's say you're making a web app. And suddenly someone comes along and says: oops, fooing the bar doesn't work on X model Y version
Perhaps we should take the discussion about running an organisation to a different chat room? There's a lot of discussion going on here about two different topics and its getting hard to follow
@Donald.McLean I don't think it's about my ego, I don't consinder myself to be better/worse/above anyone. I just find from the sound of pair programming, it might be counter to "my style". That said I've never done pair programming, so I wouldn't know.
@Skiwi I'm not debating the on-topicness, but I worry if it's becoming a Big Conversation (tm) :P
@ARedHerring mostly though it's the stuff you already said. Everyone knows the basics of good dev practice: source control, automated builds, automated tests, documentation. You just have to make them a built-in part of your process. Schedule time for them in every sprint for every feature.
for us it took a few false starts to get unit testing and automated testing "right" but you just keep learning
@ARedHerring that is one thing that it took us a long time to get used to. You probably aren't writing enough tests, and you're probably doing too much in each one. Tests aren't production code so they're not supposed to follow "good coding practices". Don't hesitate to cut and paste your butt off.
@ARedHerring but it's also a trade-off... you write as many unit tests as you have time to write without missing a deadline and losing the business. so you kinda get a feel for what parts of the code are "highly unlikely" to break. and you often get it wrong and just deal :)
@MikeEdenfield If you have time, here's a repo I put up a few days ago where I feel I haven't written enough tests. The idea of the repo is simply to run off to an API, and check if the results have one field equal to a certain value.
@Donald.McLean party or dinner? I am not a social animal. :P In all seriousness, I haven't brainstormed since I was in school, so that's at least 3-4 years ago.
@ARedHerring My point is that for any project with more than one person, it is all about teamwork. And being a "social animal" or not is irrelevant. You have to buckle down and learn to work together, and pair programming is one of the best ways to do that.
@MikeEdenfield I've done almost pure TDD just once.
What I did was create my core classes and interfaces so I could use Intellisense and use the right names and stuff.
Then, I wrote a bunch of tests, but I didn't run them.
After I implemented the feature, I went back and adjusted the tests to account for any write-time issues I found, then I ran the tests and fixed more bugs in the tests and code.
my major stumbling block with TDD is that I develop stuff very iteratively in the IDE. I just do a prototype/POC and let it evolve into the final product without really stopping to document how it should look when it's done.
I need to take a break in the middee there, once I have the prototype or POC done, and think how it's going to look and write tests against it right then
And #2 is that I'm not 100% convinced in my own head that TDD is going to be a dramatic improvement over what we're doing now, and it's too radical a change for me to make on my own and "find out".
I have no confidence that I could get my time estimates right.
I'm waiting for a project that I have some leeway with the scheduling to try and do it right.
Just recently I "got on a roll" and implemented a new feature without any unit tests. Of course it was badly broken and wasn't sure why until I implemented the unit tests and could test that part in isolation from the rest of the app.