Professional development week marks the midpoint in a cohort at LEARN. Prior to PD week, most of the topics have a singular focus as we learn the building blocks of development. After PD week, we put the fundamentals together into a series of full-stack applications.
When working on smaller challenges the errors can be spotted more quickly since there is less code to sort through. A larger app will inherently have more complex errors. More complex errors will require more in depth bug fixing tools and more time to narrow down the problem. This will require patience from all parties involved, including patience with yourself.
When working on projects there is more room for developer creativity. This is where the really fun aspects of development come into play. However, every app will have requirements that need to be met and workflows that need to be followed. A good developer will exercise attention to detail in not just creating code but how the code is being created as well as the overall health of the team.
When faced with a problem there are a series of troubleshooting steps that should be completed. The first step is to take a five minute break and come back with fresh eyes.
Next, look for the low hanging fruit. Always, always, double check spelling and syntax. Typos are very common errors. Use the built in functionality of the text editor to make sure all the tags, parentheses, and curly braces have their buddy. Writing clean, well organized code will produce fewer errors.
Next, read the error messages! Errors are a great way to learn about the code. Error messages will often contain the file and the line where the error occurred. Make sure the problem you think you have is actually the problem you have.
When making changes only change one thing at a time, test it, then make one more change, then test. Don't break working code during the troubleshooting process.
The job of a developer is to work through problems that you don't know how to solve. Naturally, this means that you will often find yourself stuck. Being stuck can be either not knowing how to solve a current problem or it can be not understanding the problem well enough to start solving. Both of these situations are valid and require external help.
First you must determine that you are, in fact, stuck. Being stuck means that you have tried to used various troubleshooting methods to solve the problem and you have not made any progress in 30 minutes. At this point you should ask a question.
There are three parts to this process:
- The asking prep.
- The question itself.
- The aftermath.
Once you have determined you are stuck, the next step is to start formulating the question.
Talk though your problem out loud. Whether you are alone or with a pair programmer, take a minute and verbalize your problem.
Organize your documentation and resources. Take screenshots of your error messages with as much context as possible.
- Start by summarizing the problem. Include the given input and expected output as well as the actual current output.
- Give a brief overview of the approach to the problem so far.
- Provide error message screenshots.
- Finish with a specific ask.
If the blocker is understanding the problem, be sure and state that clearly in the ask.
So you asked the question and you got an answer. It's not over. If you don't learn form the experience then you didn't finish the job. Write down the question you asked and the answer. Creating your own personal documentation is really important to being a successful developer.
The second half of the cohort can bring a lot of stress. It is important to revisit and embrace the brave space philosophy.
- Welcome multiple view points.
In programming there are always multiple ways to approach a problem and multiple solutions. Be open to learning and be open to being wrong.
- Own your intentions and your impacts.
Your words and behaviors have an impact on others. You are responsible for the effect of your words and behaviors.
- Work to recognize your privileges.
We are all working from a place of privilege to be in this classroom, but don't make assumptions about other's privileges.
- Take risks.
You can't grow if you stay in your comfort zone. Implementations and ideas don't have to be perfect to be effective.
- Step back.
Recognize how much you are speaking compared to others. If you are comfortable speaking, great, but make sure you are giving others space to contribute.
- Notice and name group dynamics in the moment.
Pay attention to the energy in the room. If there is a disconnect, take a time out and address the issue.
- Actively listen.
When someone is speaking make sure you are listening and not just thinking about what you are going to say next.
- Challenge with care.
If something doesn't feel right, let's talk about it! Always assume positive intent first. Then challenge with care.
- Confidentiality.
Focus on the problem not the person.
- Break it down.
Miscommunications can arise from misunderstanding the problem. Provide context and share all relevant information in simple language.
Being a successful developer requires being a good teammate. Being a good teammate requires checking your ego and putting your energy into the success of the team.