This writing is based on my observations in my professional life. The following topics are established considering the common behaviors of appreciated software engineers and the party poopers.
Be courteous when you are mentioning your teammates(i.e., Daily Meetings, Jira Logs, Retrospectives, etc.) in reference to your programming sessions. I taught her this, fixed his code, etc. This is rude. It just makes you look like an arrogant piece of garbage. Always be nice.
Try to understand the business instead of jumping into coding.
Few hours of documentation reading will likely prevent future misunderstandings and reworks. Coding must never be the first thing to do unless you are not a badass crackhead genius engineer from the future.
Asking is always welcomed. But before asking, please struggle. Hesitate over asking for help without sweat on your face and the stress chewing up your soul. Kidding. But seriously, do your research before demanding help.
Mud Slingers ☄️
Backbiters are usually ones who are not capable of setting the bar higher. Talk is cheap, show what could be done better by using your skills instead. Truly skilled engineers tend to act humble.
Know the repository you are working on. Whatever the util, helper you need might be already included in the project. Check the repository before copying it from StackOverflow. Avoid any duplication.
Some requirements might look similar. If the project is at its early stages, going through extravagant changes (i.e., a badass startup), or your project’s stakeholders misinterpreted agile, you will likely face a lot of irregular changes. Focusing on reusability and abstractions at very early stages might end up designing and spreading complex awkward structures. Instead of focusing on reusability and abstractions at the beginning, maybe it is better and more efficient to commonize structures with the same or extremely similar usages afterward with slight refactoring.
Sea Cucumbers 🌊 🥒
Raise a flag when you see or sense something. Do not sit and watch going in the wrong direction. As long as you stay quiet, you are holding the steer.
Read the manual, document, other people’s codes, merge requests, requirements, instructions, patterns, blogs, books, source codes, Jira comments. Do not ignore the fact that most of your questions already have answers. If you make time for reading, you’ll get to comment or express your opinions on tougher topics, and people will actually value your approaches. Otherwise, you will always sit and watch while engineers are brainstorming.
Research how others solved similar problems you have faced. Any problem can have many different solutions and there will be at least a few top solutions. Follow company blogs. It doesn’t matter how creative or experienced you are, reading will always make you multiple steps ahead.
Thank you for reading.