Read git log and see how people write their commits. Are they all in imperative mood? Then write your commits in imperative mood. Do they start with a capital letter? Do the same. Include a cat emoji after every word? Now you're stuck with that too. But what if every commit message follows a completely different style? Then you're lucky, you have a chance to advocate for a standard, to be recognised as someone who's trying to bring some order to chaos.
The next thing you could avoid if you were a master of Zen, but you are not, so you're going to panic for at least two months. There is going to be horrible crazy code and horrible design and you're going to question what crazy incompetent programmers could commit such crimes against code. But recognise that there are probably good reasons for most of these horrible things you see, and realise that panic for at least the first few months in a new job is a completely normal and understandable reaction. Instead of criticising, ask questions. When you get the answers you'll often find that the crazy design idea was actually a reasonable and pragmatic work-around. Or that the other developers around you have recognised the same code debt and also have a plan to fix it. If you get defensive and criticise the code you stand the chance of making enemies but if you ask good questions there's a good chance people will recognise and appreciate your ideas and feedback.
You're going to get code reviews, the second time you get a change request for the same type of issue you've already received a change request for in the past, it's probably going to stick in your head. Write it down somewhere so you don't do the same thing a third time. Being caught repetitively making the same "mistake" might be seen as a lack of attention to detail.
Make sure you respond to all change requests in your PR reviews. If you're using GitHub, then see the next tip, if not then maybe you'll have to keep track of this yourself and make sure you go through all your pull requests each morning manually. Respond to every single change request you get, even if it's just to add an "eyes" emoji or a thumbs up. If you disagree with a change request, respond with a comment and keep following up until you reach consensus. Everyone has worked a developer who says "I have nothing to do" despite having multiple change requests open against their pull requests. It's very frustrating. Every change request is "something to do", sometimes you might have to be proactive in following up your change requests to reach a resolution but that's one of the most important parts of a development job.
If your company is using GitHub then before you do anything else, learn how GitHub notifications work. With an adequate understanding of this you'll never miss another piece of information relating to your code again, then all you need to worry about is how to keep up with your project management tool.
Update your issue statuses in your project management tool at least once every morning. Leaving code that's been merged in In Progress state can be tolerate for up to a day, but any more than this looks lazy. 90% of your communication might be with other developers but advocating for, and facilitating transparency amongst the organisation will be recognised beyond your team.
Top comments (1)
true.