I worked in three companies. worked in small team, big team and I have seen a product growing from the scratch. Thourgh the years of learning I have shaped my decision framework. Here is some of them :). I might revisit and tweak it in future. Feel free to disagree on some of these.
"Best practices" are "Not a rule book". Everything has exceptions and outliers based on the context. Status quo bios can work in both good and bad ways. That applies for all the items below.
We're literally getting paid to 'think'. If we're not being creative in thinking that yeilds tangible results, we're not incentivising companies to pay us more.
When you move up and up, it is not just about technical skills unless you work in very specialised field.
If the company prioritizes velocity over the learning of an individual most of the times, you should start being selfish about grooming yourself. Otherwise you are doing long term damage to you.
Bad code or bad implementation is not always because of people's incompetency. It might be because of deadline or tight deliverable. If you're constantly giving these excuses for your bad code, you're incompetent or you lack ownership.
If you see a ugly bug, fix it or get it fixed. Not everything will be planned in sprint planning. 15 mins work (This time limit differs person to person) is not worth your backlog or mental space.
Sometimes it doesn't cost you a penny to be nice.
Your code demands some long term tax to be paid. if possible It is always better to pay it gradually. You can't remove all duct tapes in single shot.
Greater the common code and longer the code in production, lesser the bug.
Never hesitate to make some change that might break something which is not in prod yet or the cost of failure is low. The long term tax you're trying to pay now will be much lesser than the tax you will pay when you do the same thing in prod. You might not get rewarded for your work. But you might get blamed for your failures.
Sometimes going slow is the fastest way you can go.
Correcting or improving the implementation is always easier than correcting or improving the interface. Same with method signature and method implementation.
Sometimes you will be forced to win some battle instead winning a war.
Don't give too much credit to your intelligence.
Don't compare AIs evolution with human evolution that happened over millions of years.
A complex thing can be broken into thousands of small things.
You can't start eating the big pizza in the middle, but you have to start eating it to finish it.
Requiring too much tribal knowledge get started is a good recepie to kill the team.
Write code like a coffee bug which doesn't require a manual.
You should avoid writing some code if you feel that someone might break it if they try to change when you're not there. If you're forced to do so, tests are your final line of defence.
Effective two person review rule is a simple math. If one person has 0.1% chance of committing a mistake, two persons committing same mistake will be very very less than 0.1%. thus take reviews seriously. Don't approve something if you don't understand it fully.
Estimate - by definition of the word itself is it's approximate. How much you're off with your estimate defines the quality of your estimates.
QA is the last line of dedense and you shouldn't handover all of your fights to QA. Use them only when needed. If p0 is not working, it is your problem.
Don't be an intelligent jerk. You will do far more damange to the team than you think.
You will lose your goodwill for the every destructive fight you will pick. Thus pickup the fight only if you can win. Losing fights may not worth the goodwill you will be loosing.
You need to phase out after a sprint. Thank me later.
Rearchtecture is most often not solution for a system which handles 99% of the cases and no frameworks or libraries handles 100% of the cases.
Consciously spend perfection tax.
Over-engineering can kill startups. Under-engineering can churn big companies.
If something becomes a problem to the team, don't ever say it's not my line of work. acquire skill to fix it or "know who" will fix it for you.
At core you're engineer first. whether you're a backend engineer or frontend engineer comes later.
You need feedback loop to grow. A good feedback loop will get formed from the people who have different opinion than you. Thus listen to people who have a different opinion and corrected you in the past. Not all people can form good feedback loop also.
... to be continued.
Top comments (0)