1. It took too much of my time. Since I was doing this in addition to my dev duties, it was not something I could afford to spend time on. 2. When I first started, I would resolve the issues myself. But I soon realized the builds were usually broken by the same suspects. Sending it back to the devs (and also requiring them to buy a box of donuts on breaking the build) put a quick stop to this. 3. Builds were usually broken by people checking in their code in a hurry right before they were done for the day. Calling them and having them fix it after work (as opposed to me having to sit additional hours after work fixing something they broke) very quickly put an end to the practice of checking in your code in a hurry and leaving for the day because you had a dinner to make it to. I don’t want you to miss your dinner, but if it’s important enough that you can’t be bothered to make sure your code is working then you can also wait till the next morning to checkin your code.

Except I do. And as with anything, feedback takes you back to reality.

Plus you learn where you tend to make mistakes and thus have a chance to study a bit more about area to learn how to not make mistakes.

- read a stack trace

- find things in the doc

- use the debugger

Most people, professional devs, signing up for my __advanced__, yes, specifically requested to be advanced, Python trainings, don't know how to do this.

Again, I try to be extremely nice about this, because nobody likes to feel inadequate and I'd rather have people learning happily this and improve their life and work.

It takes a lot of courage, if you are 40 and being in the field for 2 decades to admit you need to go back to this.

But it's not what I was expecting from the industry.

Hey, it makes me feel useful :)

So when you get to something that is complicated and has the potential for deep strategies and shortcuts for efficiency (e.g debugging), it's no surprise that experienced coders might want a refresher.

Impostor Syndrome may be a thing there, too.

E.g only "java.lang.NullPointerException", only the top of the stack, missing "cause" etc. :D

You have it easy, the devs here in Cardiff push code that doesn’t even compile locally, then start howling that “Jenkins is down!” when the build fails. Or even just “the server is down” with no other details. Like I just telepathically know which of our 5000 VMs is “the”.

My experience in learning computing in school was going through large months long projects where later stages built on early stages but the entire project was throughly documented and paint by Numbers so long as you followed the directions exactly. If you came up with a valid but undocumented solution you would break the assumptions of the documentation and forever be hacking the program to get it to work which was still possible just time consuming and nobody knew how to help you. The end result is students who can follow docs without fucking up but who also don't know how to fix things other than by rolling back to a known good version.

I've found these sorts of problems to be very difficult to solve in academics due to the need to standardize assignments and grading yet a few months doing an original project will infuse you with troubleshooting mojo.

Agreed. I was told, and later had to tell others something to the effect of "okay, so what did the error message say? did you search that?"

Moreover, having person who made bug is just good practice. Feedback, basically. When people know about own errors and have to fix them, they learn more about errors they make.

It perplexes me that you could get through a 4 year degree without learning how to read a compiler error message though. I'd be less perplexed at this happening in a super condensed and streamlined boot camp though.

Then again, neither was version control...

Only time I felt students got shafted was a Web Dev elective. People who weren't already pretty experienced with JS had a really hard time (we were on the quarter system, an HTML/CSS/JS+React/Redux+Node is pretty ridiculous to cover in one quarter).

If the expected cost of decoding the error messages includes a lot of reverse engineering of crap code, people won't bother.

It was a major, major issue in early C++ template metaprogramming. You couldn't give good names to some of your constraints so the errors were nightmares.

I resisted joining a startup that exited for 8-figures because one of the devs was emotional/blame-oriented and another one of the devs, a female, was too into me.