Ask HN: What is your best advice for a junior software developer?
241–250 of 460 posts
Re: Ask HN: What is your best advice for a junior software developer?
#242Earlier quoted context omitted.
This quote is so silly, and misused. It’s like one of those facts about Einstein that you’ll see on Facebook. For one, in this context, a junior developer will rarely be the smartest person in the room. So it’s really terrible advice for the context. I think it’s really terrible advice in general though, the places I’ve learned the most is exactly when I’m the smartest person in the room, doing stuff like mentoring o…
In a non-technical environment, it is very easy for a junior developer to end up the smartest person in the room as far as tech is concerned. Think meetings with SMEs, PMs, or Sales.
Re: Ask HN: What is your best advice for a junior software developer?
#243Robots are coming and so is automation. Programming opportunity will only exist in custom projects but most companies want to use COTS solutions to not beholden to contractors in the long run. This change is starting to emerge and the programming opportunities for the future will start to erode.
This was true 20 years ago too, and yet the demand for developers is as great as ever despite more and more COTS type solutions available each day. I'm not being critical of your viewpoint, rather I'd like to understand what you believe has changed or is changing. Especially, I'm curious what role you believe robotics plays in that.
Re: Ask HN: What is your best advice for a junior software developer?
#2441) 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 searching through unfamiliar codebases to figure out how they work.
2) A senior developer (or any productive person) is good at saying no. People will ask for more of your time than you can spare. You can gently but firmly say no, direct people elsewhere (delegate), or ask people to discuss with your manager whether more of your time can be allocated to help them.
Re: Ask HN: What is your best advice for a junior software developer?
#245I often have felt that Jr. Devs I have mentored only live up to the "Jr. Dev" role. They only do as much as they think a Jr. Dev should do and often leave work for a more Sr. Dev instead of at least trying to take a stab at something.
Example: a JR. Dev has trouble implementing some candlestick graphs. Instead of trying to work through the issues and document his thoughts in the code and ask for advice. He just leaves it untouched, for many days, then a week, before someone asks him his progress then says "while I can't quite make it happen" when really nothing has happened.
Re: Ask HN: What is your best advice for a junior software developer?
#246do not burnout I know you are young and you feel like you're invincible. I know you can pull an all-nighter and work the next day just fine. We have all been in that situation and believe me, it is gonna take a toll at your performance ... and it could even trigger or help you develop some health issues in your life that can sabotage you down the line. Realize there's only so much progress one can do in the day. Stop…
Couldn't disagree more. Burnout sucks... and the crash was terrible, but the things I accomplished leading up to my burnouts were the best work I've done in my life. Here's what I would say: DO IT FOR YOU, not for someone else, not for a company... do it for yourself and what you want to accomplish in your life
Re: Ask HN: What is your best advice for a junior software developer?
#247Earlier quoted context omitted.
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…
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?
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.
Re: Ask HN: What is your best advice for a junior software developer?
#248I 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…
In my experience it actually leads to Juniors being abused a lot of times being given dumb projects someone should have said no to. Then code review rolls around and the seniors are like “what is this” and there’s a dumb fight. Lol. Maybe that’s just the places I’ve worked.
Re: Ask HN: What is your best advice for a junior software developer?
#249Writing some React code and it doesn't work for Chrome on Linux?
You should in principle be prepared to debug not just your own code, but React's internals, the Chrome JS engine, and the Linux kernel itself until the problem is identified.
Obviously that sort of thing is a last result, but you should in principle be prepared to do it.
Re: Ask HN: What is your best advice for a junior software developer?
#250Read 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…
My answer was that I looked at the error message and then, if it was available, scanned the backtrace to figure out which files/method calls were involved. Otherwise (particularly with JS), I set up some breakpoints in the browser to help visualise things better.
I've come across plenty of senior developers who ignore what the machine says. The thing is, most bugs aren't solved through intuition, so approaching the problem as if your gut feeling is completely accurate is going to turn a 10 minute debugging session into something that could last a full day. As, in my experience, it once did.