Live data from Hacker News

Ask HN: What is your best advice for a junior software developer?

news.ycombinator.com

341–350 of 460 posts

Re: Ask HN: What is your best advice for a junior software developer?

#341
Learn how to understand who the "customer" of your software is and how to deliver what they need. Learn what you're inherently good at and not so good at (and develop strategies to work around your weak points.) Learn that code reviews are discussion of how you did something, not an attack on your ego. (or at least they shouldn't be.) Find mentors you can trust.

Re: Ask HN: What is your best advice for a junior software developer?

#342

Earlier quoted context omitted.

That’s only true if the developer of the class module let the entire stack trace get through to the consumer. In C# it’s the difference between... try { .... }catch(Exception e) { //Do stuff throw new MyCustomException(“Something Bad happened”); } And try { .... }catch(Exception e) { //do stuff throw; }

In what case would you ever want the second example?

Always. If you can't resolve the exception and continue processing normally, you should never discard the exception you caught and create a new one of your own. If you must create one of your own, include the one you caught for the additional context.

It's pretty frustrating when you're debugging someone else's code and their error handling just throws away all of the useful information and replaces it with a generic "Something broke" kind of message.

Re: Ask HN: What is your best advice for a junior software developer?

#343
post #244

I advise junior developers that there are primarily two difference between a junior and senior developer: 1) A senior developer is unafraid of not knowing things. When we join a new team or company, we're as lost as any junior developer joining them team. We ask as many questions as necessary to get our work done effectively, without shame or fear of looking foolish for not knowing things already. We are good at sear…

Your first point is something I've seen a lot of and experienced myself too when I was new. I think it can be a big psychological barrier to learning more and generally being happier/more confident.

I wrote up something about it a while back: http://zalberico.com/essay/2017/02/21/asking-questions.html

Re: Ask HN: What is your best advice for a junior software developer?

#346

Earlier quoted context omitted.

I've gotten a lot of value from reading HN. I've also wasted a lot of time. It helps to develop a personal filter. Mine is * Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother. * WSJ, Bloomberg, and WaPo won't let me read articles with w3m, so I skip the article. If the topic is tremendously interesting, I'll check the comments. * TED and nau…

"object orientation is a failed paradigm" uh... wtf?

I know my prejudices. I recognize that a lot of people think OO is just dandy, and I'm on the lookout for a good argument in its favor. I'm open to the possibility that the reason I think OO doesn't work is that I don't understand it well enough. Maybe somebody out there will explain encapsulation in a way that doesn't make hidden mutable state seem like a nightmare. Maybe somebody's got a blog post that explains why inheritance only looks like it makes spaghetti code, but actually I can safely ignore the dragons lurking three levels up the hierarchy. Maybe there's some piece of OO code out there that embodies a beautiful solution to a problem I've been struggling with. If those things are out there, they're going to get posted to HN eventually.

Re: Ask HN: What is your best advice for a junior software developer?

#347
post #215

Earlier quoted context omitted.

It isn't just a huge hint, most of the time it tells you exactly what the damn issue is. This discussion is blowing my mind. I am honestly speechless. IT GIVES YOU THE LINE NUMBER AND THE FUNCTION CALL AND THE REASON! Why would you ever even attempt to debug without parsing it?

Wait wait wait. Not so fast. i'm one of those programmers who read manuals and stack traces but I have to admit that I've seen my share of both manuals as well as stack traces that didn't make much sense.

Especially when you end up in C++ template hell.

Re: Ask HN: What is your best advice for a junior software developer?

#348

Earlier quoted context omitted.

That’s only true if the developer of the class module let the entire stack trace get through to the consumer. In C# it’s the difference between... try { .... }catch(Exception e) { //Do stuff throw new MyCustomException(“Something Bad happened”); } And try { .... }catch(Exception e) { //do stuff throw; }

In what case would you ever want the second example?

[deleted]

Re: Ask HN: What is your best advice for a junior software developer?

#349

Earlier quoted context omitted.

Wait wait wait. Not so fast. i'm one of those programmers who read manuals and stack traces but I have to admit that I've seen my share of both manuals as well as stack traces that didn't make much sense.

This is my experience with Clojure stack traces ~60-75% of the time. Perhaps it is a symptom of functional programming? A lot of function passing and anonymous functions make it difficult to generate a meaningful stack trace.

Functional programming not so much- languages like Elixir or JS used functionally don't have this problem generally.

Re: Ask HN: What is your best advice for a junior software developer?

#350
post #269
post #160

Read the error messages. Reread them. Extract every piece of information from them. Never close an error popup without having read and understood what it means. Always read stack traces when you're blessed enough to have them. 100% of the juniors (and an awful lot of seniors) I've ever trained simply ignore those and then come ask for help debugging. 99% of the time, the explanation for their problem is literally the…

Ok, I'm strictly a hobby developer so I don't really have co-workers to go ask for help. Do people really not read error messages? That boggles my mind. How would you ever figure out what went wrong? I mean, how could anyone ever learn to program well enough to get a job as a professional programmer without knowing to do that?

The obvious answer is they don't figure out what went wrong, they tweak the program until the problem goes away for a while.
Post reply on HN