Hacker News Reader

Comment by Kalium | Hacker News Reader

> - read an error message to trouble shot. A stack trace is utter mystery.

The number of developers I've worked with who handle broken builds with "The build is broken! Why did you break it?" instead of "I shall now proceed to read the error message which will helpfully tell me precisely why the build is broken and how to fix it" has always astounded me.

I've yet to find a way to handle error messages that will actually convince devs to read them. All I've found to date is apologizing for an unclear error message and offering to help with anything they had trouble understanding.

View on HN

As someone who was part of the small team that used to do our company’s builds before I automated them, I deliberately would not bother reading stack traces and try to fix it but would send it back immediately to the dev.

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.

As a developer, 2 and 3 are basicly feedback. If you check in hurry and no one ever tells you it caused a problem, you will slowly unconsciously start believing yourself a god. I never cause a problem with this!

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.

Doesn't the development happen on a different branch? Of course I push before I go home: if my machine breaks i want to lose a few hours, not a day of work as well.

It took me by surprise too, but now when I give a training, I make sure I include how to:

- 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 :)

Given that Python belches stack traces anytime you look at it funny, I can't understand how that could be...

Hey man, I * scrolls back 6 pages * love a good stack trace.

Good that there is a stack recursion limit in Python.

I see you too forgot a comma once in a Java program.

Template compilation errors in C++ were at least 300kb last time I've tried to use that language.

I've gotten my fair share of those from use of Boost.

My guess would be that a lot of coding is autodidactic, aka there is a lot of self-learning, trial and error, etc. This means you learn a lot of bad habits, or develop gaps that a formal training course would avoid.

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.

Just today a junior on my team (who is also new to my team) complained to me that a set of docker containers he was trying to spin up were "not coming up." I probed him a bit, he sent me a screenshot. I shit you not, "ERROR: Write /some/path/on/disk: no space left on device." It's pretty incredible. You can lead a horse to water, and all of that.

That seems like the kind of oversight one expects from a junior dev just joining a team, that's where ones job as a senior dev to push them through the process comes in.

Yup. First question - "what do the logs say?"

My favorite is support people that send you a nicely truncated stack trace with all the useful information missing.

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

The number of developers I've worked with who handle broken builds with "The build is broken! Why did you break it?"

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

As someone outside the software development industry, but with experience programming for various reasons... I'm dumbfounded by this. Is this the result of hiring code bootcamp graduates instead of those with bonafied CS degrees or what?

That's a curious insinuation. If anything I would expect boot camp grads to be overly dependent on Google.

I don't know, I'm self-taught and I know how to read stack traces and use a debugger.

I would guess autodidactic learners are more likely to pick this up than those who mainly learn through formal education. I don't think stack traces or debuggers were ever really covered in my CS program.

Then again, neither was version control...

Then again neither were the languages you were expected to do your homework in. I think there was one "Pascal language" class no one in the Major took. The faculty cared about the Computer Science (Math) underpinnings; the language dejour was just a speed bump to help separate the wheat from the chaff.

My program had a pretty good layout as far as languages. I think the standard was 1.5 classes of C, 1.5 classes of Java, then pretty much everything after was in one of those languages.

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

Probably because no one was spoon feeding you or holding your hand. Plus the fact that people who can teach themselves are probably a little more driven or competent to start with.

That's a bad bias you have. I could handle coredumps before I started CS. Also CS does not teach you efficient programming - that's a different course.

I'm actually generally in favor of boot camps since I myself have a self taught CS background with a civil engineering degree, and I actually know quite a lot of computer science. However, there's something to be said for the additional time in and critical thinking that you might get from a CS degree. However, some people on here seem to be indicating that their degree didn't made allowances for struggling through things or was "too academic" in nature.

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.

My experience: through the whole masters degree I had to write ~6 working programs. Only 2 were of non-trivial size. (a compiler and pseudo-physics stimulation) Some were group effort where someone else could easily pick up the debugging if needed. My 5 year degree definitely didn't care about debugging and I think people could do it with next to no programming skills.

Another reality check is that fixing build I broke is typically quick while fixing build broken by somebody else takes a lot of time. Those errors are rarely as exact ad to allow you to fix issue in 5 minutes. Occasionally, stack trace leads to quick null pointer fix, but it is tricky as real cause can be deeper (null should not even happen) and quick fix is just hiding larger problem.

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.

Don't see how an academic background would help you avoid this it's a skill you're far more likely to learn through practical experience. I don't see bootcampers as being particularly vulnerable to these gaps in knowledge.

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.

Completely not my experience at Georgia Tech. You were left to your own devices, had to learn sensible debugging and logging in order to complete most tasks in a time efficient manner, and your time was crunched. It probably depends, but I don't see how you can get that experience in a web dev bootcamp

> Don't see how an academic background would help you avoid this it's a skill you're far more likely to learn through practical experience. I don't see bootcampers as being particularly vulnerable to these gaps in knowledge.

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?"

Those skills are not taught in CS degree programs (nor should they be).

It's not so much that they'd be directly taught in a CS program, but more that I'm surprised you'd never have bothered to pick up that skill set, even accidentally during a four year degree.

No it's human nature. Do people write code that will make error messages meaningful or not? That's something you see in type and variable names, filenames, warning hygenics, etc.

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.

The oil and gas developers I worked with who were some of the most incompetent people I've ever known had fancy masters degrees (at a minimum) in computer science.

Apart from comedic value, blame doesn't fix anything.

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.

Reply on news.ycombinator.com