#career
43 posts

Being a great engineering mentor

Be ready to listen. Your mentee should always feel free to ask you questions, especially in the first few weeks of onboarding.
Read more

Being a great engineering mentor

  • Be ready to listen. Your mentee should always feel free to ask you questions, especially in the first few weeks of onboarding.
  • Help anchor them socially in the new place. If possible, carve out a weekly team ritual.
  • Let them feel safe enough to pursue novel solutions by showing them how to evaluate risks within the context of your organization and team.
  • Explicitly inform your mentee of technical safeguards in place as well as providing non-technical assurance of help with failures.
  • Understand their strengths and weaknesses, and encourage as well as challenge them technically with tasks that let them level up while having fun, gradually adding more unfamiliar or challenging jobs. Offer code hints but don’t unnecessarily prime them with warnings of difficulties ahead, and occasionally add stretch goals and praise their resolution to build confidence.
  • Have 1-on-1 discussions and reinforce when you notice they are doing a great job while challenging them to do even better and share business context they might not readily see, as well as the engineering context of their project predating their on-boarding.

Full post here, 8 mins read

Don’t be a jerk: write documentation

Documentation can be minimal and yet helpful. Take whatever you have in volatile formats (email, chat logs, shell I/O) and paste it into more durable ones (README files, diagrams, websites, FAQs, wikis).
Read more

Don’t be a jerk: write documentation

  • Documentation can be minimal and yet helpful. Take whatever you have in volatile formats (email, chat logs, shell I/O) and paste it into more durable ones (README files, diagrams, websites, FAQs, wikis).
  • Document based on your audience:
  1. For newcomers, focus on what it does, why you wrote it, who should be using it and for what, how it should be used (how to build, configure, run and get started), and where additional information may be found; do not display the source.
  2. Regular users could do with a reference manual, examples, EDoc/JavaDoc/Doc, wiki or website, and API descriptions.
  3. Contributors should have access to the source repository, as well as project structure and architecture (where to find out about specific functionalities and where new features should go), the project principles, tests, issues, and a roadmap.
  • An easy way to get started is to imagine you are talking to a new user. Then vary the user and add different scenarios (of their business context and experience/knowledge, budgets) to expand the documentation until it is comprehensive. Finally, you might split it up into categories for different people or reimagine/format it for different media/platforms.
  • Another approach is to find a problem a user might face and show them how to solve it.

Full post here, 11 mins read

How to feel less overwhelmed as a developer

Identify the specific problem - be it too steep a learning curve, too much information incoming, too many responsibilities, peer pressure or your own expectations of yourself.
Read more

How to feel less overwhelmed as a developer

  • When you feel overwhelmed, either there is too much going on at once or you are overstimulated. Refocus and reprioritize.
  • Identify the specific problem - be it too steep a learning curve, too much information incoming, too many responsibilities, peer pressure or your own expectations of yourself.
  • Zero in on your key goals, set your boundaries, focus your ambitions, and recognize what’s not really relevant to you.
  • Find a process for self-education. Don’t try to memorize everything, learn where to find the right information. Make a list of what you don’t know, and add to it every time you come across a new idea or a skill you don’t have. Sift through the content and establish your key resources so you aren’t overwhelmed.
  • Beware of getting overwhelmed by other people. Make sure you have a balanced perspective on social pressure. Know that a lot of people write bad code, even great developers in great companies. People have different priorities and you don’t have to keep up with theirs. Remember that people will write about what is possible but you don’t need most of it on a day-to-day basis.
  • Work smarter by spending time on core skills like problem-solving, critical thinking and testing. Use proper project management tools to plan, manage tasks and track bugs. Take breaks for fresh air, exercise, and conversation so you don’t lose sight of the big picture. Ask your community for help with good resources, pointers or support with your workload.

Full post here, 9 mins read

Three types of risk: making decisions in the face of uncertainty

Fatal risks can kill a company, so you need to be extra careful to watch for them as your company grows and ages. It is easy to get complacent but there is no recovery from such decisions gone wrong.
Read more

Three types of risk: making decisions in the face of uncertainty

  • Fatal risks can kill a company, so you need to be extra careful to watch for them as your company grows and ages. It is easy to get complacent but there is no recovery from such decisions gone wrong.
  • Painful risks have lower but significant repercussions: missing a key goal or losing key people. But you can recover from them.
  • Embarrassment risks have no significant impact beyond just what the name states. You just need to acknowledge the mistake, change course and move on.
  • Another way to think about risk is Jeff Bezos categorization of decision making into Type 1 (irreversible, so spend time on them) and Type 2 (reversible, as with painful and embarrassing risks, so make the decision quickly and move on).

Full post here, 4 mins read

Absolute truths I unlearned as a junior developer

Don’t be led by job titles alone. Value collaborative experience, being reviewed and having a mentor. Avoid an early position where you have to work alone.
Read more

Absolute truths I unlearned as a junior developer

  • The title of ‘senior developer’: Don’t be led by job titles alone. Value collaborative experience, being reviewed and having a mentor. Avoid an early position where you have to work alone.
  • Everyone writes tests: Loads of companies have little or no testing, because they have either never felt the pain of not having tests or felt the pain of having legacy tests.
  • We’re far behind everyone else: Beware of ‘tech FOMO’ as academic settings and conferences often cover proof of concepts rather than real-world scenarios. Dealing with legacy is normal.
  • Code quality matters most: Often, good enough code that works and is maintainable is good enough. Overarching architecture is more important than nitpicking.
  • Technical debt is bad: Disorganized or messy code is not the same as technical debt. Technical debt actually slows you down or causes errors or makes changes difficult. A certain amount of tech debt is healthy because it assures delivery.
  • Seniority means being the best programmer: Senior engineers need many skills, from communication and dependency management to estimation and project management. And the truth is that we all remain junior in some areas.

Full post here, 14 mins read