Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.Ħ) Slow down in order to speed up. Often times, persons other than engineers will take what you said as gospel. Refer to someone who knows, or offer to get back to them. Peer reviews are win-win-win.ĥ) When in doubt, do NOT BS your way out. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. If someone is suggesting it, it's because they didn't know what it did without further investigation.Ĥ) Ask for peer reviews and LISTEN to the critique. Accept criticism that may seem trivial such as renaming a variable or method.
Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc.)ģ) Working code != good code. It's okay to ask questions, but ask sparingly. Nobody expects you to be the best early in your career, so don't act like you are.Ģ) Working independently is a must.
#Code completion assistant in anylogic software#
After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:ġ) Your ego will hurt you FAR more than your junior coding skills.
0 kommentar(er)
