Or: “Everybody likes being given a glass of water.”
By Merlin Mann.
It's only advice for you because it had to be advice for me.
I was drawn to programming, science, technology and science fiction | |
ever since I was a little kid. I can't say it's because I wanted to | |
make the world a better place. Not really. I was simply drawn to it | |
because I was drawn to it. Writing programs was fun. Figuring out how | |
nature works was fascinating. Science fiction felt like a grand | |
adventure. | |
Then I started a software company and poured every ounce of energy | |
into it. It failed. That hurt, but that part is ok. I made a lot of | |
mistakes and learned from them. This experience made me much, much |
Andy Thomason is a Senior Programmer at Genomics PLC. He has been witing graphics systems, games and compilers since the '70s and specialises in code performance.
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
First, add pry-rails to your Gemfile:
https://github.com/rweng/pry-rails
gem 'pry-rails', group: :development
Then you'll want to rebuild your Docker container to install the gems
I have two Github accounts: oanhnn (personal) and superman (for work). I want to use both accounts on same computer (without typing password everytime, when doing git push or pull).
Use ssh keys and define host aliases in ssh config file (each alias for an account).
Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
Don’t rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.