Live data from Hacker News

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

news.ycombinator.com

421–430 of 460 posts

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

#421
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…

I really like your last point "whatever the computer is telling is true from the computer point of view". In a surprising number of coding interviews that I've conducted, I've seen a candidate write an incorrect solution that generates an exception and then attempt to figure out the error almost on first principles, rather than actually reading the exception carefully and thinking about what coding errors could have…

People never read error messages. Most of them click straight through 8 milliseconds after the error appears, without taking the slightest opportunity to understand.

It's rage-inducing when troubleshooting over laggy screensharing sessions. If enough frames drop, I may not even see that the error was raised.

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

#423
I've got so many :(

I haven't seen this one so far (but haven't yet read all comments):

Whenever possible, try to avoid bugs. But, even more importantly: When given a bug report, FIX the damn bug. Don't:

- Shrug, mutter incomprehensible things and wish the person with the bug report goes away (yes, I've seen that. It infuriates me.)

- Say "that's not possible" (cf [1]). It is. It happened, no user makes this stuff up for fun.

- Say "that doesn't happen on my machine." Well done! Now make sure it doesn't on all the other ones, too!

- Say, "well, if you had configured it right,...". That's also a bug: Your documentation sucks. Fix it. Also make sure impossible/nonsensical configurations are visible (best done during startup, for example).

- Avoid commenting on the report/contacting the author because there's not enough information. Tell them you need more, what they must gather and how. If you tell everyone the same things, write a HOWTO and link there.

- Ignore bug reports. Valid reasons you're not fixing a bug are 1) you're currently busy fixing another, more important one or 2) you already understand the bug completely and have discussed the tradeoffs involved with others (write a WONTFIX with sound reasoning, please).

To sum it up: Be helpful to your users/admins/etc. Don't be a "Code Monkey".

[1]: http://plasmasturm.org/log/6debug/

Edit: Formatting, reference to 6debug :)

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

#424
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…

An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important information if necessary.

You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved).

Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too).

Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)

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

#425
post #16

Always work with people smarter than you. Ethics are important. Don't stop trying to improve. There is money to be made in every IT area, follow what you like and you wont be poor or unhappy. Respect others' work no matter how crappy, specially open source/free work.

While those are all good points, I feel like

> Don't stop trying to improve.

can't ever be overstated.

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

#426
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.

Yeah I agree. The way this thread is going you would think that all errors are easy and all you have to do is what the computer tells you and you’re done. I wish I’d known it was all that simple!

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

#429

Earlier quoted context omitted.

The 7% is referring to the rate of return on your investments. He is making the assumption that if you invest $100 in the stock market on January 1, then on Dec 31 your account will have $107 in it. This assumption is an average over many years. There is a common rule of thumb in the investing world that you can safely remove 4% a year from your investments and they will continue to grow. (7% return minus 4% withdraw…

Quick question. Is the 80k an example you threw out, or a reasonable amount for a junior dev to make? Specifically for a a mid-sized company in the States, outside of Silicon Valley. Currently working as a junior dev and the senior devs feel I'm making less than I should be. Which is much less than that 80k. The only caveat being that my employer is also paying for part of my tuition (up to a max of $5000 a year). Pr…

This is completely dependent on your location and the size of the company. E.g., when I recently looked into the stats for Germany, the average annual income for a developer in a small to medium-sized company is ~48k€ (~55k$), which is a long way from the 80k figure.

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

#430
post #398

Earlier quoted context omitted.

I'm not suggesting someone spend all of their time writing code outside of work, I certainly don't, so please don't label what I'm saying as such, or as "bullshit". Yes employers pull that crap, and want you to sell your soul, that's not what I'm suggesting. I don't think programming is something you become good at simply by doing your 9-5. I've worked with a lot of 9-5'ers and they're rarely the best or most rewarde…

I still disagree with you. The idea that you should only become a software engineer if you want to continue it outside of working hours is one of the reasons our industry is primarily made up of white (or Asian) middle class men. It's perfectly ok to do this as a job, a really good job, a career, but still a just job that you don't pursue out of work. When we discourage people who don't want to code in their spare ti…

Well, when you put it like that. I can't disagree. I hadn't considered that it puts off people that are not "like me".

I agree that we certainly need more diversity. I've been fortunate enough to work in some reasonably diverse places and I'd hope to see more of it in our industry.

To turn my argument around, I'll say that I'm a Software Engineer _because_ I love it, I would be doing it anyway when I have the time, it's one of my "hobbies" so to speak.

Given that I can't immediately think of a way to re-structure what I've said in my previous comments, to meet this argument of yours, which I agree with, I'll simply concede that I was wrong and leave it at that.

Post reply on HN