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…
Ask HN: What is your best advice for a junior software developer?
181–190 of 460 posts
Re: Ask HN: What is your best advice for a junior software developer?
#182Read 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…
Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important.
Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error?
Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.
Re: Ask HN: What is your best advice for a junior software developer?
#183Start off by going deep, not wide. You'll pick up other languages and technologies over time. Pick a stack that appeals to you and focus on it for a while, learning its idioms and best practices and improving your development fundamentals.
In summary try to develop good judgement based on real world experience.
Re: Ask HN: What is your best advice for a junior software developer?
#184Learn about the business side of the company. It helps tremendously if you understand how management/sales/marketing/etc think. Don't follow your passion. Passion will come if your work is meaningful, you are competent and respected for it. So instead work on your competency in whatever field. Leave if the environment will never respect you anyways. All software problems can be solved if you work on it long enough. D…
> Never assume anybody is stupid. Instead, figure out how these intelligent, well-intentioned and experienced people have come to a decision which is stupid now. On that note, don't assume that any particular existing piece of code you find is somehow "blessed". Do assume that everyone, yourself included is a total idiot and capable of writing fallible code, and in every avenue and every respect of life, assume that…
Re: Ask HN: What is your best advice for a junior software developer?
#185On the slightly more negative side: everything management tells you that's not in an email will have "never happened" when it's convenient. When you have a conversation with anyone where you think a plan was verbally agreed on, before doing anything your first action is to go back to your desk, write it in an email, send it to them as confirmation and find at least 1 other person, ideally in your reporting line, whic…
I have never had to do this nor seen anything like this behavior in my 6 years of work in the industry. This sounds incredibly in bad faith, and I would probably take it as a signal to go job search for a better work environment if I witnessed this in my day to day.
Re: Ask HN: What is your best advice for a junior software developer?
#186Learn to tear down abstractions instead of building them up. As a junior developer, it may be hard to get acceptance for removing layers, but add as few as possible. Somebody is going to come through later and need to understand what you've done, when the stack is deep, that's much harder.
Don't trust other people's code to do what the readme says. If anything claims it's lightweight, count the lines of code and see. If you use other people's code and it's broken, it's going to hurt your users and you're responsible.
On a people skills level, learn how to disagree without being disagreeable. Invite people to share their reasons for things with real questions, and listen to their answers -- while they're sharing you can discuss why to do it their way vs the way you want to do it. This is a good practice for when you are the senior person instructing the junior person as well. Often the senior person is going to make the decision, but having a discussion about it can make it easier to accept.
Don't do this for everything though. Choose your battles, don't be the person who fights everything; unless you're getting good results and people are happy changing everything.
Re: Ask HN: What is your best advice for a junior software developer?
#1871- Find solace in the fact that "senior" engineers often spend a significant amount of time searching the web/stack overflow just like you do.
2- Have respect for the code that came before you. Be generous when passing judgment on architecture or design decisions made in a codebase you've adopted. Approach inheriting legacy code with an "opportunity mindset".
Re: Ask HN: What is your best advice for a junior software developer?
#188Re: Ask HN: What is your best advice for a junior software developer?
#1891. Don't blindly follow advice of "experts" you read. 2. Don't write clever code, write readable code. Participate in code golf or obfuscation contests to scratch the itch if you have one, but keep it out of production code, even if its a private project that you will never share with anyone; it will save you from yourself.
On point 2, I think it's very possible to write clever, readable code. I think Rob Pike's 5 Rules of Programming[1] are better advice here -- in particular rules 3 through 5. [1]: https://users.ece.utexas.edu/~adnan/pike.html