wisdom for developers
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
LICENSE
PULL-REQUESTS.md
README.md
REGEX.md
SHORTCUTS.md

README.md

developer-survival-kit

wisdom for developers

Handy Resources

Responsibilities of a Developer

Following are some useful traits and practices for Developers. This is by no means an exhaustive list, and it's by no means a required list, but rather a collection of recommendations. Your workplace will determine your required responsibilities and the things you must do to maintain your position in the organization. This is a list of things you should do as a good Development Team Member or a citizen of your organization.

  • Be a team player. Follow your team's conventions and processes
  • Be vocal. Communicate frequently: particularly blockers, risk or other inhibitors to progress
  • Be constructive. Offering criticism without solutions is poor form
  • Be helpful. You are part of a larger team working toward a common goal.
  • Be mindful. When you write code, leave it in the condition you would hope to find it in.
  • Be open. Your ideas are good and important, but so are the ideas of others. You don't know everything.
  • Be aware. Listen in meetings and to your team members. Information is everywhere.
  • Be present. Whether you're in the office or remote, participate in discussions, meetings and other events.
  • Be responsible. Deliver on your promises, set realistic expectations and communicate when you cannot meet your goals.
  • Be flexible. Process is good, but progress is better. Sometimes you have to work around process to make progress.

Responsibilities of a Junior Developer

As a junior, your primary role is to learn the domain knowledge of your workplace as well as tricks of the trade from your fellow developers. This is a list of recommendations similar to that of the developer, but with a focus on how it applies to you.

  • Be a team player. Follow your team's conventions and processes. However, as a junior, you should ask questions. If you don't know something, you should be asking.
  • Be vocal. Give your opinions. Ask questions. Communicate your blockers. Never assume you have nothing to contribute, but make sure you are valuing the experience of others as well.
  • Be constructive. Learn to ask questions in a positive manner and find ways to give criticism paired with solutions. Learning to accept these as well from others will go a long way.
  • Be helpful. Try things out. Experience things you aren't familiar with. This will help you learn and help build your confidence. Find those among your team that are most encouraging and feed off of that.
  • Be mindful. You are learning to write code. Ask for pattern advice. Copy patterns present in the codebase for practice and consistency. Ask questions about why a decision was made.
  • Be open. Please do bring your ideas forward. This will help you learn and bring new things to the table. Learn to be open to the ideas of others at the same time. This dance is hard. Don't sweat it, but do learn it.
  • Be aware. Listen. Gather information. Then ask questions about what you're missing.
  • Be present. Show up to things. Speak up in meetings and discussions. These things will help you learn and will help others trust you.
  • Be responsible. You will rarely be asked at this stage to estimate, but be careful that you don't overpromise things. Communicate blockers and anything that you don't understand.
  • Be flexible. Right now, you probably should avoid breaking the rules. If you think that you need to get around process to make progress, ask for some advice and help. Maybe someone knows another way! Maybe you were right. Discussion will help vet this out. Above all, be willing to jump in and help out in whatever way you're asked. Be willing to play whatever role your team needs.

Responsibilities of a Development Team Lead

Following are some useful tasks for Development Team Leads to take on and own. This is by no means an exhaustive list, or a required list, but rather a list of recommendations. Your unique work environment, team structure and team makeup will determine which of these items are useful or necessary.

  • Schedule and maintain recurring 1:1 Meetings with your team members
    • Understand their work/life balance
    • Understand their career goals and help to set new goals
    • Understand their motivations and objectives
    • Empathize with their issues and listen to their problems
    • Communicate issues to management, but only with team members' blessing
    • Encourage the use of PTO if it's not being used
  • Schedule and maintain daily stand-ups if they're not otherwise happening
    • Actually stand up.
    • What did you do yesterday?
    • What are you doing today?
    • Do you have any blockers?
    • No side-discussions, save those for post-standup
    • No laptops !!!
    • Maybe toss around a ball and have the speaker hold it
  • Work to clear blockers for your team
    • Own and resolve access/connection/account problems
    • Own and facilitate the resolution of human dependency issues
    • Own and facilitate the resolution of asset dependency issues
    • Communicate blockers early, often and to the right people
    • Set expectations for delivery based on unresolved blockers
  • Work to get team members out of unnecessary meetings
    • Ask "Who is required for this meeting?"
    • Ask "What role does this individual play in this meeting?"
    • Ask "Can this meeting be replaced by an email?"
    • Ask "Can I collect information and stand-in for people in this meeting?"
  • Work to improve processes
    • Does deployment take 2 days? Work to cut it in half, then in half again.
    • Are you not using Git or some SCM? Set it up immediately
    • Are your code reviews not effective? Work on a solution.
    • Are you experiencing a lot of defects? Work on a solution.
  • Work to set and enforce standards and best practices
    • Ensure teams are using some sort of Linter
    • Ensure teams are using some standardized or common set of rules
    • Ensure teams are using consistent branching strategies
    • Ensure teams are putting in useful commit messages
    • Ensure teams are using the recommended tooling for their tech stack
  • Own your team's communications to Stakeholders and Business Teams
    • Communicate successes
    • Communicate challenges (debt, blockers, risk, etc.)
    • Communicate early and often. Bad news does not improve with age.
  • Own your team's internal communications and promote active discussion
    • Promote discussion on #Slack, HipChat or whatever your team uses
    • If your team doesn't have a discussion forum, set one up!
    • Participate in discussion so that team members know it's ok
    • Share non-work-related information, news, etc. to let team members know it's ok
  • Own your team's deliverables, deadlines and commitments
    • Ensure that you can commit to dates
    • Understand the role that PTO plays in your deliverables
    • Evaluate and review team estimates to ensure you're not overcommitting
    • Ensure the impact of blockers and other delays are effectively communicated
  • Be the advocate for your Team Members to Management
    • "Did you know Bob is really good at X?"
    • "Did you know Jane worked 62 hours last week to meet our deliverable?"
    • "Did you know Pat's SO was injured at work and they have 9 kids?"
  • Create and Own Your On-Boarding Process
    • How do I get access to services?
    • How do I get help with issues?
    • How do I setup my environment?
    • How do I check-out the code?
    • How do I build the code?
    • Where is a list of your domain-specific terminology?
    • Where do I park?
    • Where do you all eat lunch?
    • Etc.