Ask HN: Tips for students before starting their first job

You’ll know it when you see it because you will literally get uncomfortable when thinking about completing it.

High output involves completely finishing things. It will be impossible at first, but as you get more experience, in both total and your current company you will be better at it.

For a decent company, the differences are:

* The skill set of group members probably suits the tasks (e.g. some good at leading, some good at coordinating, some good at coding)

* The reward is real and can be life-changing. (e.g. becoming millionaires)

* The punishment is real (e.g. being fired)

Anecdote: Back when I was first starting, we were experimenting with different agile styles, and were pulling cases off a backlog whenever we needed something new to do. It wasn't strictly ordered, so you could pull off the top several if there was something you wanted to do more.

The top two items were getting skipped for a long time, so I took one and stumbled around trying to figure it out. Ended up asking a few newbie questions (non-technical, about how the feature was intended to work) that our manager had no answer for, resulting in the case getting officially bumped way down. Then tried the second, and the same thing happened.

Even though I technically didn't get anything done (which did feel kinda bad at the time), I learned a decent amount about how those systems functioned, got rid of some eyesores, and brought it to everyone's attention that the cases hadn't been sufficiently fleshed out. Net positive, I think.

As a person currently struggling with always-say-yes related burnout symptoms I cannot stress enough how important it is to manage your workload to keep yourself sane. Balance is key

Maybe, but not if you already know what is being asked of you is boring because you have tried it before and it did not work. Also, don't be afraid of sharing experiences that you may have had - if a particular library/algorithm is sub-optimal and you know it, speak out.

Also: The amount of effort needed for a task does not always correlate with the importance of the outcome. Sometimes big wins come easy and sometimes small wins are expensive.

There are lot's of production codebases with very little or no documentation, though.

"Don't over-engineer stuff. Keep it plain and simple."

This in an excellent advice.

"Pay close attention to the most experienced people and try to understand their thought process and mentally train yourself to be able to think like them"

Yes, this is similar apprenticeship. Just being able to work with talented people is an outstanding thing to have. On the other hand, if you are a junior contributor, but can't find the obvious master programmer around, that is a huge red flag that the organization is filled with mediocrity through and through and it probably would be best to work somewhere else.

If you actually feel you are the most talented programmer, and are confident of your skills, that is an important datapoint. If your organization does not value your skills in couple of years you should definetly move on.

> * Don't overdevelop things. Keep it simple. Remember - most of your employees will have a lot of experience and you won't be able to impress them with anything revolutionary. Chances are that they saw it and ate it millions of times for breakfast. But also important to not use a package for every little thing. I personally experienced many that e.g. in the NodeJS ecosystem, use huge packages to use a minimal set of functions or someone can easily copy from Stackoverflow which just makes the project more overcomplicated. Just a single package not updating can fck everything up.

> * Don't be afraid to ask, even if it seems like a silly question. Especially if you are involved in a large and complex project. Most people are aware that new developers are often a net loss for the company in the first 5 to 6 months regardless of their skills and knowledge - there is always an adjustment phase. Use that to your advantage. Above all is asking questions in the first weeks starting a new job. Else it is just stumbling around through the project.

> * Be __brutally__ strict about work processes and don't try to reinvent the wheel. Application structure, naming conventions, pull requirements, code review - stick with it unless (there is a specific situation and you are instructed to do something else). That is, if everyone on the team creates short commit messages that explain the change and link it to the appropriate Jira, Github, Gitlab ticket (or the tracking system they use), they do the same. There is no need to write a 50-line commit message that describes the change in all files. And vice versa: if you write 50 line commit messages and explain each line of code you changed, do the same. It is important to expect at least some knwoledge from the developers not to explain everything, because good naming already makes the code so easy to read, like a book. But, Magic lines need to be explained often with more than one line.

> * Pay close attention to the most experienced people and try to understand their thinking process and train yourself mentally to be able to think like this. Your thought process may not be the most efficient in general, and it could be something completely different for your next job someday, but if it turns out to work for this team / company, stick with it. Tips on not be annoying but still have a good amount of messages and discussion with them?

> * When you receive a task, check or ask if there is anything similar. If it does, go through it, check for anything you can reuse, or at least understand the mechanics, and keep it close. And always automate if something takes longer or is a recurring thing. Whats your opinions on prototypes? In terms of how functional they should be. Personally I build prototypes just to work and show the general concept, but could not be used by clients for "production".

> * You won't be able to say no, but everyone will be able to ask for more details if needed. That doesn't mean you should switch to an experienced developer every 3 minutes. Rather spend several hours understanding clearly what needs to be achieved and organize your questions in relevant clusters. This can help you answer many of them yourself. Whatever is left over, ask someone if they have 10 minutes and have a coffee with them if necessary. If your questions / concerns are valid and relevant and what is expected of you makes no sense, they can stand up for you or tell you who to talk to.

So better collect for a bulk of questions and try to solve them in the meantime.

The question you should ask is not "how to make this more beautiful" but "how to bring in more value to the customer". Don't go on a refactoring crusade alone.

If you want to become a valued individual contributor try to understand the added value created by the product as much as you try to understand the codebase.

I've never contributed to an open source project and my career has evolved just fine, though.

I think this audience over stresses the need of open source contributions. It's fine if you don't want to work in the open and don't want to share your code.

Natural curiosity of open codebases is a good thing to have, though :)

I've known several excellent 9-17 coders who work, and then go home to do other things.

I would say, rather, there are no stupid questions.

After awhile it will become increasingly clear who fields questions well, and who doesn’t.

Cultivate the former, avoid the latter.

> demonstrating a strong work ethic will get you noticed and earn you a good reputation that will pay back many times in the future.

No, this is an exception rather than the rule. Depending on your employer/manager, a strong work ethic may or may not be noticed. If it's noticed, it might even impact you negatively since you'll be the guy who can be abused and overworked in the future especially if you can't speak up for yourself. The other options are that nothing changes with your work ethic or that you're rewarded in some way. In the cases that you are rewarded, it's more likely that your employer is giving you meaningless tokens, praise and/or more responsibility rather than actual perks or increased compensation.

Unfortunately, this can easily backfire. Make sure it is clean, sure, but at some point you are going to take time cleaning and it won't be appreciated at best. At worse, you are going to be told it took you to long to do the work. This is coming from someone who, at a foodservice job, had someone teach me how to mop. Their standards - for mopping anyway - were quite a bit lower than the standards I grew up with at home. It hasn't just been that establishment, either: Everywhere has some of this.

I'd much rather see someone be told, "Do well, but there is no need to be perfect. Be efficient where you can". This goes so much further and besides, most folks expect the new person to do a few things that are a bit off.

Not being fussy about the work you do, though: Solid advice. I've generally tried to do something other people dislike, if possible.

But you should have a workplace you like, because that is key, from my point of view.

On the other hand if the work is done on Windows it's much better to learn that platform than pining for something else.

Go with whatever is platform specific, and available out of the box. Avoid complex configuration packages just to get the specific interface flavour to the computational substrate you would prefer to use privately.

The reason is, if there is specific computational platform that the employer is using, you are much more helpfull to all around you if you operate with the vanilla settings rather than try to find something more special.

Privately try to find the best methods that work for you, in public, collaborating, try to find the most simple and straighforward method of contributing. Simple in this case does not mean a kludge, but it may mean a few extra lines of code or configuration here and there.

Yes! This! This does not mean false promotion. It means being able to express succintly and understandably that what you are good at. The world is drowning in noise. You do a disservice to everyone, including yourself, if you don't create a "personal brand".

It does not mean being obnoxious or pushing yourself. It just means you can explain clearly - when the need is - what you are good at in as few words that are as effective as possible.

I'll be blunt: this sounds like work that pays poorly (it's academia), is likely to be quite demanding (it's academia), doesn't give great industry experience (it's academia), and doesn't get you a PhD (at the end of it you still aren't an academic). What's the upside?