Name: Principles for growth as an engineer
Rating: 1 (7435 reviews)
Author: mohanarpit

TL;DR notes from articles I read today.

Understand how your work is valuable to your company and make decisions that support quality, feature-richness, and speed.
If you find your path blocked, find a way forward by persuasion, escalation or technical creativity.
Think about what needs doing beyond your immediate task. Advocate for what the company or team mission can benefit from.
Write crisply and concisely to not just inform, but persuade and teach.
Understand dependencies, ensure key components have owners, summarize plans and status, and proactively inform stakeholders of progress (including obstacles).
Own your education and pursue constant growth. Make learning a daily task.
Master your tools: Mastering the editor, debugger, compiler, IDE, database, network tools, and Unix commands increases your development speed.
Communicate proactively, regularly and in an organized way to earn collaborators’ confidence and goodwill.
Find opportunities to collaborate, especially on cross-functional projects, to grow in terms of visibility and skills.
Be professional and reliable: come to meetings prepared and on time, and pay attention. Deliver what you promise or proactively communicate if things go wrong. Disagree respectfully and show your colleagues appreciation. Avoid complaining and help people stay upbeat.

Full post here, 4 mins read

As a mid-level or senior developer helping a junior developer grow, show them things they can only get from experience, not just coding.
Explain business-side decision making. Have your junior sit in on meetings with clients or production managers (or explain later), so they have context and understand where their tasks come from.
Do a demo and discuss the business logic of the project they are working on, so they can see the user perspective and know why certain decisions were made.
Cover best practices in code reviews: discuss better solutions if they have poorly written code even if it works. Decode jargon, especially for core concepts, and explain the team’s code decisions so they can see how applications grow.
Hear them out before you tell them the ‘right’ way. Resist rushing them towards the end of a sprint and let them learn to think fast and critically and to commit to decisions. Listen and then explain why (if) you need to make a different choice.
Talk them through your thought process while coding, then reverse roles: hearing them think lets you notice when they aren’t using a concept correctly and makes them more aware of their own process.

Full post here, 5 mins read