Name: Truths about code optimization & developer careers
Rating: 3.7 (9575 reviews)
Author: mohanarpit

TL;DR notes from articles I read today.

Make sure you start with working code in the first place and have good unit tests so that speeding it up does not break anything.
Don’t assume you know the problem. Run your code with a profiler and see which bits are the slow ones before you start to write new code. Your obvious best guess could well be wrong.
As you optimize your code, run the profiler after every change to check whether the change actually helped and whether there is a new bottleneck now.
It is obvious but if a change did not measurably help, take it out no matter how brilliant you think it was.
You can always keep on making things faster, lighter, cheaper but it will also gradually make the code harder to read, longer, complex. Know when to stop.

Full post here, 5 mins read

Accept that you don’t know everything, that tech knowledge is competitive and that you have to keep working and learning to stay relevant throughout your career.
Acknowledge that social and soft skills matter as much as tech knowledge. You will need to hold mature human conversations that solve human problems to grow through your career.
You don’t need to reinvent the wheel to make a difference. In the early years of your career, aim to learn about others’ thought processes and why things are being done the way they are.
You will not always get the help you need, so seek out a mentor you can trust, who is also invested in your success and with a 5-10 years’ experience gap.
Your goal in the workforce is not just your success but that of the product. So assume that in interviews you are being evaluated not for accuracy but for brainstorming human factors that can affect the product’s success and learn to test for them.

Full post here, 9 mins read

Consider the impact of your words. If necessary, rewrite comments for empathy and clarity both.
Elaborate on your concerns to be more specific and to avoid ambiguity, even if it sounds more verbose.
While suggesting changes include code samples. Treat a code review as a public conversation, and remember even experienced developers can gain from ideas on implementation.
Include a link to relevant documentation when referencing a function, commit or pull request. For concepts, link a blogpost. Make it easy for the author to get to things you reference with a single click.
Offer to chat in person or on video call for clarifications, and volunteer to pair up and collaborate on any suggested changes.

Full post here, 5 mins read