95% of "in person" training courses for software developers are shit, change my mind if you can.

I haven't been to one, so I can't tell from experience, but I feel like a tutor being available to answer questions in person can be very helpful, especially for beginners.

All of them are shit regardless if in person or not.

@retoor "In person" was the wrong term, what I meant was "live training" regardless if its in person or remote because usually who makes these is some wannabe teacher who retells you the content of a book (design patterns, wohooo!) as its the 2nd coming of Christ, some soy-dev over enthusiast for the flavor of the day framework, or some overworked guy which has to cover an excessive amount of ground with his courses so he fails to get in depth with his material.

I do admit that once I had a cool "live, in person" training experience and it was a PostgreSQL course made by a core contributor.

@donkulator the overlap is due to a css bug 🙃

I read programming by reading books. Like the C programming language.

But then I got taught programming by the nicest old ex phd researcher (in biology). At high-school level. He probably sucked at coding but he was like a santa claus.

No I won't change your mind. It's a correct and factual statement.

Fuck anything in person when you can do the same at home in silence.

+ public transports suck.

@Tounai driving by car sucks too because of traffic jams at the time when you drive to work and then also when you drive back home.

Driving by bike sucks too because it takes too long.

@Lensflare driving a car is just a worst version of public transport tbh.

@retoor if it’s not a vintage car it’s not worth it.

@retoor i’d never work somewhere where I’d need to drive more than 40 minutes by car.
My previous job was about 25 minutes when traffic was good. And that’s too far away for bike.

We've been fortunate that all our in-house trainers have been working developers that 'teach on the side'. They had the "this is the theory, but this is what works ..." mindset. YMMV

Boring history lesson part 1:

Ex. many years ago we had a trainer come in to teach the 'proper way' to unit test (the dept mgr was pushing for 100% code coverage, TL;DR, and he believed a 'professional' could come in and shame us into shape)

Day 1, the dept mgr was trying to nudge the trainer into preaching the glory of 100% code coverage.

T: "Yes, 100% is the ultimate goal of TDD, but I've rarely seen it in practice. You have to set the goal to what works best for your team. If your coverage is 20% and you're stakeholders are happy, then that's fine. If it's 100% and developers are afraid to make changes because of broken tests, then that's bad."

@PaperTrail > Part 2:

Mgr: "but..but...if we have 100% code coverage, making changes is easy!"

T: "Two words. Technical debt. Test code is debt. Nobody, I mean nobody wants to change someone else's 5 year old test code. 100% code coverage is a lot of debt few are willing to pay. I've worked with Cerner and 100% code coverage is non-negotiable. People's lives are at stake, so they are willing to pay the price. Here? You guys write CRUD apps. I'm sorry, trying to get 100% is a feel-good number."

<Mgr, pissed off, walks out>

I almost wanted to give him a hug. I've been saying that ever since the dev mgr came back from some big shot Gartner Group training. My guess is he ate lunch with someone who asked him about code coverage and the mgr couldn't answer him.

I don't like pair programming either.

@PaperTrail 100% test coverage and normalised databases are mental sicknesses tbh

@retoor > "I love coverage"

I do as well. I believe if the code can be tested, it should be tested.

If the code can't or doesn't need testing (why would anyone test a method that sets a=b?), then don't.

We've had our share of TDD zealots that created quagmires of complexity just to say "My code testable!"

Creating an IDatamanager with 100+ methods and mocking this&that, or worse unit testing POCOs/models,

ex. customer.firstname = "foo", Assert.IsTrue(customer.firstname == "foo"),

does not serve the customer.

One of the worst examples is our web team created their own testing framework. It enabled them to have before/after scenarios (TL;DR) and "easily" have hundreds of tests. All was good until a .Net upgrade broke "something" and none of the original developers were here that knew how to fix it. For a long time (they had to re-write all the tests), our site had zero testing before deployment. "If it builds, ship it!" was the process.

@retoor you and @kiki seem to be the polar opposites on that topic :)

My take is: test only what makes sense. And that is at most 30% for frontend code.
90% is guaranteed to be too much and useless. My opinion :)

@retoor because overtesting is killing productivity. Tests are a tool, not a goal.

@Tounai very well said.
I‘ll steal this to explain it to those who don‘t get it 😅

@donkulator that’s a reason to upvote

@retoor
- I trust my pairs and they trust me. I don’t need proof and I believe in their responsibility.
- Testing is important, but testing every single line of code makes changes awfully long to do. Done to me means released and working, and this must come with a certain degree of speed.