Personal standards for work[notes]
— work — 3 min read
Hi,
I am Aman, and this safe space is where I am most raw with my thoughts, hop on if you'd like to interact with them :))
This is going to be a fairly shorter one, It's been a long time since I wrote these
You probably don't care enough
This blog is a collection of chapters that mostly reflect what I think about work, health, life and anything in general, hence it would make the most sense for me to attribute a chapter to the personal standards I have for my work.
Disclaimer
This is a high opinion bulleted[all about my work] list which is very much inspired by Thorsten's newsletter, so please guys no cancelling on twitter!
The list
Always test your code or a bug fix before saying yes to whether you have fixed it or not
Think through the edge cases. That doesn’t mean you have to handle them all right away, but you should have an answer to them.
Develop a sense of critical thinking and always see from a bird eye perspective
Send small prs which is easy to read and review
Understand what problem you’re solving. Knowing why you’re doing something is a requirement to knowing whether you’re actually solving the problem, always ask the question why, sometimes people are being irrational and they don’t know about it
Accept that sometimes you’ll have to do things that you don’t find interesting or exciting or that don’t bring you joy. Sometimes it’s just work.
Always read the error messages.
Always think about error handling and the purpose of your function
- Always write good error messages
Always Be on time, just because you are up late night does not mean you should be late, in a team being truly positive sum means to be available at the time they are available, get your basics right
Know why your fix is a fix.
Ask a lot of questions if you don’t understand something, never assume and always read the code(it is the source of truth)
If you helped a non engineer getting unblocked by doing a quick fix, always make sure your team members are aware of it
Do what you said you’ll do. If for some reason you can’t, let the person assuming you’re doing something know about it.
Don’t ask for “quick” reviews when you never review other people’s code.
Make it a goal that people want to work with you.
Always improve the code that you are touching, even if someone else before you wrote a bad code, improve it, because you are positive and you are the last one to touch it.
Think from a user perspective, pay attention to the smallest of details, put yourself in users shoes
Always talk in public channels
Ask people to remind you in sometime if you are busy at that moment, or log in a public channel if they asked you to do something
Be patient, if you are in panic or nervous, call for help or talk out loud.
Over communication is better than less communication
Always be available to help your teammates, being in team does not mean shipping your features fast(which you should always try to do) but it also means taking out time for
- Bug Fixes
- PR Reviews
- Helping teammates
A bug is a bug, even if the code/UX will be refactored in the future, you should still fix it. Don't let future promises stop you from fixing something which is broken in the present
The purpose of check ins and eng standup is so that your teammates know what you are working on and will be working on, make sure there is no communication gap with regard to this thing, try to document every medium-large project you are currently a part of.
Learn to unblock yourself, let the non engineer know in advance if you know you will be blocked on them, it is your responsibility to get the job done
Learn to estimate the timeline of the project, build an intuitive sense of the difficulty, understand what is being asked from you to build
As the engineer implementing something you have the most context on the larger scope and the backlogs that the project includes, always flag it to the team, so that they are aware of the problems. Knowing what we need to build and have not yet is better than not Knowing and not building it.
I don't think this will be it, I am sure that there will be more learnings as I become more pragmatic towards my work. Let this be the chapter I come back to again and again :)
Btw, you know you can reach out to me at gmail or twitter right?
