Live data from Hacker News

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

news.ycombinator.com

291–300 of 460 posts

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

#291
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 work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug to validate and it immediately crashes then I would have a bunch of nickels. Which wouldn't be super helpful, but still. Please at least run your code, or ideally you should have CI/CD with unit tests, but we all know that isn't always the case especially in legacy Enterprise software.

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

#292
post #99

Earlier quoted context omitted.

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.

I think that's naive. The parent comment phrases it a bit more cynically than I would have, but it's in everyone's best interests to casually document plans and intentions. People forget, people misremember, people promise things without fully thinking through the implications in the moment. A friendly email restating the key points of a discussion is conscientious, professional, and keeps everyone on the same page.…

My response to that would be that if someone remembers differently, they should treat their coworkers with respect and give them the benefit of the doubt if there is no reason why anyone should be skeptical. That is not a good work dynamic if your coworkers are not doing that, and is cause enough for me to start job searching.

If there is reason to believe that there are disagreements in actions to be taken, then messaging everyone to get on the same page is ok. If someone is actively throwing someone under the bus unceremoniously & quickly, then one should prepare an exit strategy & a strategy for working around the problematic coworker as a cautionary step because the spinner could potentially stop at oneself. If it is more than one problematic coworker, then the exit strategy approach becomes increasingly pertinent.

I think it is self-defeating to do other than this approach in general, and far from naive.

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

#293

Start learning about the following topics: public speaking, leadership, health/fitness, sex/relationships, personal finance, investing, business/entrepreneurship, marketing, and copy writing. Where to live, what apartment to live in, where to work, who to become involved with, what bed to get, etc. Nootropics. Cognition enhancement. A multivitamin + D & K + chelated/TRAACS magnesium supplement. Meditation and/or brai…

Ageism. Software Engineers have an expiration date. If not in management or a founder/consultant by mid 30s, things can easily get difficult.

I find this to be a myth more than a fact - unless you care about working at one of the cool hipster startups. Most companies don’t care how old you are as long as you can code - I say that as a 40+ year old developer who agressively keeps my skills up.

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

#294

Earlier quoted context omitted.

Related: Read the official documentation. I can’t count how many times junior folks have asked me things like, does FooBarFactory constructor take an array of ints or floats? Well, what does their documentation say? Sometimes the official documentation is crap and that’s a reasonable question, but usually the answers can be found in TFM.

I noticed a similar trend in JS dev: asking/looking for (video) tutorials instead of reading the official doc. Even when the doc is good and quick too read (React, Redux, Vue, etc).

Related to that, usually I am a little faster finding answers to syntax questions on SO than in the documentation, even when the documentation is good. So I'm glad that people have been asking those basic questions on SO.

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

#295
post #61

Learn 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…

These are a lot of the things I would want to say if I had near any authority on the topic.

>Participate in discussions instead of just listening. If you are wrong, then you learned something at least.

I feel being a part of the discourse is especially important and is still something I'm learning to do. There are a few times I wanted to contribute but believed what I had to say was already obvious to everyone else or to at least the people with more expertise and it turned out not being the case. Still, consider choosing your fights and

>Leave if the environment will never respect you anyways.

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

#297
post #76

do 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…

Aren't young people allowed to, well, be young though? When you don't go to nightclubs, don't have friends to call at 1am and can't play guitar in your 400sqft apartment with neighbors on all sides of the world's thinnest walls, is it a terrible thing if coding all day and all night on relatively minor problems to make somebody else five figures a week is your primary source of excitement? Does it not beat alcohol an…

> Aren't young people allowed to, well, be young though?

Working all-nighters to the point your health starts to suffer is not being young. It's exploitation the likes of which the chapters on the industrial revolution warn us about.

More importantly, we as a society should actively discourage this sort of abuse. It makes no sense to let our health waste away just because a manager wants to boast about a target or a deadline.

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

#298
post #223
post #202

Earlier quoted context omitted.

I think a lot of the time people are perfectly capable of figuring out the issue on their own, however they ask for help for social reasons. Getting another person involved in the problem is way more fun, and creates a bond between both people.

When you’re messaging me 20 times a day about simple exceptions like “X gem is not installed” (Ruby) and asking me what to do, then it has an opposite offect of creating a bond

For non black and white problems it makes more sense though. Discussing the best approach for something complex, for example.

Timing is important though, you don't want to intrude, interrupt or distract.

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

#299
Kind of a hodgepodge:

Rack up experience. It's much better to be working than not working. It is much better to have 2 years of experience and learning vs. 6-9 months looking for something perfect -- this is especially the case for juniors. Just take the first job you can get. Also, don't underestimate how much the rate of learning differs between various workplaces.

Try to work somewhere that invests in people, especially juniors. Startups will be "more fun", and you'll likely to get to work you're not really "qualified" to do, but you won't learn how to do it well. One of my biggest regrets is not finding effective mentors earlier in my career. Sometimes a more "boring" workplace is better for this.

Most employers will judge your skills by the brands on your resume. This mostly happens because there's no other reliable way of determining how good someone is when hiring them, short of "I have personally worked with this person before and can vouch for them" (the gold standard). A mediocre developer who managed to clear Google's bar may be less of a good hire than someone who worked diligently at a consulting company -- probably not in the average case, but it's possible. Note this contradicts a lot with the last piece of advice. It's a puzzle -- brand vs. skills.

Focus on your social network. Most good jobs, especially in more senior roles, will be obtained through prior coworkers, investors, or other people you know/have worked with. Keep up with people. Try not to piss people off. You'd be surprised how useful it can be to leave a trail of goodwill behind you.

Understand that it is management's job to advance the shareholder's interests. Most of the time this means they'll try to do what's right for employees. But it also means that when the situation demands it, they will lie, withhold information, fire people, report things to HR, and try to pay you as little as possible -- that is their job. Filter every announcement and communication through the lens of "how does this advance shareholder interests"? It's not fair to say "everything management says is bullshit", but it's directionally correct. Truth is not the priority.

Focus on developing skills that won't become obsolete. This means prioritizing domain knowledge, CS fundamentals, etc. over the details of one language, company, or programming environment. Try not to specialize in writing software per se -- the market rate for this is rapidly heading to zero with outsourcing and remote work. My friends who have the best careers (happiest, best-paid) are people with very deep expertise (PhD + 10 years experience) in areas like semiconductors, networking, or a particular business domain (e.g. hospitality/travel, high-frequency trading) . The trick is not to specialize too early -- wait to find something you really love.

Most startups aren't worth it. Some are. Many people have a binary view of this: "startups good"/"startups bad". It depends on the people, the market, and a lot of other factors. There are a relatively small number of investors and founders who can reliably beat the averages. But not many. Informational advantages in this area are worth a lot.

Silicon Valley is basically Hollywood. People move around a lot. Packs of people who work together cross-recruit into new companies all the time. Try to get into one of these "tribes". It will help you immensely for your entire career. The PayPal mafia is a great example of what I'm talking about.

As you get more senior, do your homework and really stress out about which job to take. It's worth it. This might be counter to what a lot of others say but IT MATTERS. It's the difference between working your ass off for four years and getting nothing, vs being able to afford a modest retirement after 4-6 years.

Plan to work 3-6 years in places, if not longer. It demonstrates commitment and people in the upper echelons of business (investors, CEOs, high-level management) respects that a lot.

If you work at a startup, don't always optimize for the biggest stock grant. 0.5% of a company that fails is worse than 0.25% of a huge success. Understand that bad companies fail and good ones sell for tens of billions. Our intuition wasn't built to handle 10 orders of magnitude differences in outcome.

I blog about a lot of this. http://davidralbrecht.com/

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

#300

Earlier quoted context omitted.

I think that's naive. The parent comment phrases it a bit more cynically than I would have, but it's in everyone's best interests to casually document plans and intentions. People forget, people misremember, people promise things without fully thinking through the implications in the moment. A friendly email restating the key points of a discussion is conscientious, professional, and keeps everyone on the same page.…

My response to that would be that if someone remembers differently, they should treat their coworkers with respect and give them the benefit of the doubt if there is no reason why anyone should be skeptical. That is not a good work dynamic if your coworkers are not doing that, and is cause enough for me to start job searching. If there is reason to believe that there are disagreements in actions to be taken, then mes…

I don't want to assume anything about your work history, but I have worked at 2 fortune 500 companies, and I can absolutely say that if its not in writing it didn't happen.

Perhaps these companies were outliers, and I don't think anything I experience was a result of malice. However, when the higher ups are looking for answers, middle management tends to put blame on the developers. I can't tell you how many times I had to dig up old email chains to essentially prove what was communicated. People forget, people misremember, and people will fabricate to avoid repercussions. I have found this to be a universal truth of business, so I can see why someone would say your comment is naive.

Also like the comment above yours states, there is literally no downside to re-affirming the discussed points. I've had instances where once things were put in writing, my manager noticed something that wasn't clear and we were able to circumvent issues.

Post reply on HN