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

you're wrong.

it's actually 100%.

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.

Why would an in person one be shit? There's no reason to make such statement I guess. I'm sure if could be amazing too

@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.

This calls for a Venn diagram:

@donkulator the overlap is due to a css bug 🙃

@Lensflare revised version:

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.

@DEVil666 I think I would do a good job myself doing that. That's why I'm like 'why?'. I didn't have official programming education. I just started on a young age, way before I could speak English / even had internet. I'm jealous on people having proper 'live education' at some university. I'm confident about my skills because I had a lot of comparison material in outsourcing career. Did a lot of different stuff with a lot of different people. But I just know that I must lack certain knowledge. If you educate yourself, you mostly learn what you want to learn. But I also learned how to work, started young, so I got that going. But my target isn't money, I want to be one of the better ones. I am actually at my current level. But the level is the problem; crud (web) applications. But sadly, that pays and is available. Stuff I like to advance my level isn't available commercial. Servers became so heavy, let's write an OS in python! Who cares these days. It makes me fall asleep

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 I had a period that I drove a nice car and loved it. But then, on a certain moment, I went living 4km or so from the office and cycling every day and realized that it was perfect! No traffic jams, not much travel time. No gas, no maintenance. Even as a car fan, I couldn't deny that a bicycle is ten times better if it's an option.

I once had a job three hours driving per day. You should never do that with any transport. Find another job. Also, my driving skills are not that top notch, it costed me a lot of energy. Also, I didn't have a decent car while doing that. It was fine regarding state and stuch, but it was a Fiat Punto. Nothing wrong with, but it's not made for people traveling three hours a day. In that case you need a heavier vehicle that drives relaxter. Nice volkswagen or so. Driving with Fiat on highway was stressed as fuck

@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 I had 99.96% coverage and that last 00.04% was indeed a bug. I love coverage, that's how I at least have some quality check. I get a nice report in browser with clear view of what lines are executed and how many times. In the terminal you can see performance per function and execute sequences. Making it work like that is quite some steps but i compiled it all in a oneliner so i can use it on any C file. All my projects have it decently configured

@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.

@PaperTrail yes, an api is very well testicle by just storing the expected values and compare them later by running the tests unless some timestamp is in it. You could prolly replace that with ****-**-'** or smth. Mocking is nice if you test multiple layers deed, I don't like real unist test per methods, I prefer to test the actual input / output of API and I actually do the a=b tests, but on public api level, so the a=b goes trough many layers. My preferred way of testing could be seen as integration tests. Real unit tests with the theory that if they're tested isolated as expected, it would work as a whole is just not true.

I like tests, that's the only way how I consider my work done - else a project doesn't have an finished state so far. Without tests you're kinda working on the whole project at once instead of components which is unmanageable

@Tounai agree on 100% part. It depend on project, 90+ is nice

@jestdotty yes, that too. Tests are the best docs on how to do something. In the docs you can find the why or how to use the components together. I do not document most test cases tho - I make their names descriptive. Just common sense applied. Comments cost maintenance

@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 So it's not just me who gets tests and testes confused then.

@donkulator wdym?

Nobody upvotes my test related comments. Everyone disagrees or smth?

@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 😅

@retoor There was a testicle typo in one of them.

@donkulator that’s a reason to upvote

@Tounai the goal is to deliver and finish your job and in my opinion tests are the definition of done. Without tests you don't know if you delivered something working. If you test it manuallly - you know - but others don't. You don't have a proof that it's tested. It's the difference between "trust me bro" and professional production ready code. Is your documentation about what is possible (proven, backed by tests) or what should be possible (no tests).

If you don't have tests, it's not a professional project. Your word as a professional that it says it works doesn't make the project professional

@PaperTrail I get customers happy with 1% coverage I guess. Coverage is for me, not for customer. I see it as kinda self review / QA. But some people sell coverage to they customer as quality indication? Nice, why not

@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.

@Tounai agree to amount of testing. As I said, I also only do the public api, nothing internal. But I do check with coverage if almost every line is executed and has right to exist. Unreached code is often a bug. Testing every function isolated is smth I never do again. The maintenance was heavy and it said nothing about how they actually connect together. Everything mocked