loading...

Truths about code optimization & developer careers

mohanarpit profile image Arpit Mohan Originally published at insnippets.com ・2 min read

TL;DR notes from articles I read today.

Truths about code optimization

  • 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


Hard truths for new software developers

  • 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


Tips for more helpful code reviews

  • 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


Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().

Posted on by:

mohanarpit profile

Arpit Mohan

@mohanarpit

Co-founder & CTO, Appsmith. ❤️ Distributed Systems. 3X Founder - backed by YC, Sequoia Capital & Accel Partners. Strongly believe in the philosophy “Always be building"

Discussion

pic
Editor guide
 

Hard truths for new software developers

  • This should be for any dev. The majority of issues faced are interpersonal issues, where someone doesn't want to change years of habits. This can be in the form of code, meetings or continued development. There is always room to learn and grow. Don't get stuck in your ways.
 

I often read the quote "You never want to be the smartest person in the room" that fits very well here as well.

For me it is beneficial for dev jobs, because I never want to stop learning and the best way is working together with smarter people.