DEV Community: Gokuldroid

IMHO - Being a software engineer.

Gokuldroid — Wed, 26 Feb 2025 06:37:21 +0000

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.

Local aliases using zen aliases

Gokuldroid — Fri, 05 Feb 2021 19:36:08 +0000

We can configure aliases very easily in bash or zsh. but those aliases are global to all directory. sometimes we need aliases or commands only for some directories alone. this plugin makes the process easy. those aliases will be available only to that particular directory. aliases will be loaded when you cd into the directory and unloaded once you leave the directory.

Configure in zsh

clone plugin from github

git clone https://github.com/Gokuldroid/zen-alias ~/.oh-my-zsh/plugins/zen-alias

check if the plugin is cloned correctly

ls ~/.oh-my-zsh/plugins

open .zshrc

open ~/.zshrc

vim ~/.zshrc

add zen-alias like this

# Which plugins would you like to load?
# Standard plugins can be found in $ZSH/plugins/
# Custom plugins may be added to $ZSH_CUSTOM/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
# Add wisely, as too many plugins slow down shell startup.
plugins=(
    git
    zen-alias
)

updating the plugin

cd <cloned directory> && git pull

Configure in bash

copy the file to root directory or somewhere in your system.

curl -S https://raw.githubusercontent.com/Gokuldroid/zen-alias/main/zen-alias.plugin.zsh > ~/.zen-alias.bash

source the file in bashrc

open ~/.bashrc

add this line at the end of the bashrc

source ~/.zen-alias.bash

Aliases syntax

Create .aliases file in the root directory of the project. add your per project aliases like this. You can find a sample file here.

yc: yarn w @zen-alias/client
ys: yarn w @zen-alias/server
ycommon: yarn w @zen-alias/common
ybg: yarn w @zen-alias/bg-jobs
yb: yarn build
yw: yarn watch

Tips

Excluding the .aliases file in git tree

incase if you don't want others to use your aliases, you can add it global .gitignore or project .gitignore

cd ~
touch .gitignore_global
git config --global core.excludesfile ~/.gitignore_global
echo ".aliases" > ~/.gitignore_global

Init command for a directory.

we might want to execute some script as soon as we enter the project. like updating local branch or setting up nvm or rvm version etc. zen-alias provides an easy way for this.

define a zen-alias like this,

init_zen_dir: nvm use && rvm use