Work on things that are interesting to you, if you are bored for too long your skills will atrophy. If you are interested in your work, being indispensable to your company will be a natural result.
Ask HN: What is your best advice for a junior software developer?
211–220 of 460 posts
Re: Ask HN: What is your best advice for a junior software developer?
#212Don't stress about not being good enough when you see other people's work. People show off their end result and not the hundreds of broken iterations it took to get there. You can build exactly the same stuff with a bit of effort, learning and time.
Corollary: if someone posts "my first X" to a big public site like reddit or HN, it is almost certainly not literally their first X; it's just the first one they felt comfortable enough to exhibit publicly.
(At least, that's what I tell myself...)
Re: Ask HN: What is your best advice for a junior software developer?
#213Best advice I ever got was from a creative writing class:
Writers write. To become a better writer, write more.
But then I've always treated programming as a form of communication. Maybe not literature, there's still beauty, awe, and whimsy to create and behold.
Re: Ask HN: What is your best advice for a junior software developer?
#214Earlier quoted context omitted.
> 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…
I had the opposite problem when I was junior: I believed most existing code was crap because “it’s not how I would have done it” and had trouble resisting the urge to rewrite everything. Learning to live with and thrive with legacy code is a great skill.
I was that way as well, but all the juniors I encounter now are the other way around.
Re: Ask HN: What is your best advice for a junior software developer?
#215Read 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…
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?
Re: Ask HN: What is your best advice for a junior software developer?
#216On 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.
It's hard for people to have recall over events and (again not always malicious) what one person may consider a "big deal" to have done (or not done) will influence whether they remember and how they remember it. I've been pulled through changes I was opposed to (in my opinion, it made less sense to make the change) and eventually conceded to the change. 1.5 years later everybody (both those who agreed with me at the time and those who disagreed) was all about changing it again (back to the way it was). I had the email conversations and remembered what previously happened and was able to (re-)inform people about why the decision had been made (no, I did not want to revert all the work I did even if I still thought we shouldn't have made the change).
Re: Ask HN: What is your best advice for a junior software developer?
#217On 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've screwed myself multiple times by not being sufficiently anal with the followup emails.
I've also screwed myself multiple times when I did.
It's hard to know when to do it.
Instead of continuously second guessing myself, I've settled on preferring trust-based relationships.
Alas, I've only experienced that twice. It was heaven.
Anything short of that is torture. I hate the "Guess what I'm thinking?!" game.
TL;DR: Miscommunication is the norm. Learn to persevere.
Re: Ask HN: What is your best advice for a junior software developer?
#218Learn why things work, not just how to make something work.
You'll probably have plenty of times where you know that "if I write this line of code, this thing happens, and that solves the problem". Dig into exactly what that is doing and understand why it works as it does. A lot of the time this just means reading all the documentation (not just the 1-liner you can copy/paste and move along) and source code of libraries.
A good exercise you can do is to open up some code (ask a coworker for a good place to start), look at it line-by-line, and ask yourself if you know exactly what is happening on each line. You probably won't know and that's your trigger to go read up on something. From there you'll have great questions that a coworker should be happy to talk about with you.
In my experience, new developers that take this approach of truly learning (rather than just making things work) grow fast and impress the team.
Re: Ask HN: What is your best advice for a junior software developer?
#2191. 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.
Strongly agree!
If you write something cool and you're thinking "oh yeah! I am such a Ninja!" then step back and decide whether it needs commenting to explain what it does.
If it does need commenting, consider whether you could rewrite it in such a way that comments are unnecessary. Assume your colleagues and future code maintainers are trainee ninjas at best.
Re: Ask HN: What is your best advice for a junior software developer?
#220Tech doesn't exist in a vacuum, so do not ignore the board room politics! Source: senior sysadmin who learned this the hard way