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. Do not give up just because StackOverflow does not have the answer.
A really good question to ask for a task is "How do you know you are done?" It might prompt to clarify requirements. It might prompt you to make things more measurable or testable. It makes you think about implicit things like following code guidelines. It makes you better at estimating time.
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.
Do not just fix symptoms but (at least try to) fix the root problem.
Participate in discussions instead of just listening. If you are wrong, then you learned something at least.
Sit together with experienced developers. Watch how they use their tools.
> 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 there _may_ be obvious, ingenious, simple/scalable/efficient/elegant solutions that have been overlooked leaving open possibility of a better way. Never be annoying about it though.
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.
> A really good question to ask for a task is "How do you know you are done?"
One of the more valuable things I learned in product management is defining what success looks like. It's tempting to just put a product out there/work on something, and think it'll pan out, and you'll know when you're done.
>Don't follow your passion. Passion will come if your work is meaningful, you are competent and respected for it.
Ehh, everyone starts at zero and you need passion (or otherwise some form of goal/discipline) to become competent to begin with. Nothing wrong with using passion to follow a goal. Just don't be place all your eggs in one basket; it's not the end of the world if you don't instantly reach your dream goal/salary/life choices.
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.
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. Do not give up just because StackOverflow does not have the answer.
A really good question to ask for a task is "How do you know you are done?" It might prompt to clarify requirements. It might prompt you to make things more measurable or testable. It makes you think about implicit things like following code guidelines. It makes you better at estimating time.
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.
Do not just fix symptoms but (at least try to) fix the root problem.
Participate in discussions instead of just listening. If you are wrong, then you learned something at least.
Sit together with experienced developers. Watch how they use their tools.