ruthmoogWeek Two Complete!
It's been an uplifting week with great pairing, meeting personal goals and getting better at setting daily targets that tie in with the week’s objectives. I'm becoming more comfortable with never finishing a project (well, there's always more to do...).
Code Review
Reviewing other people’s code can improve code-reading skills in general and, could help you uncover different approaches that you can apply to make your own code better. Having at least two pairs of eyes on code - especially on code built without pair programming - is a gatekeeping measure commonly used to reduce the risk of pushing dodgy code, or, for maintaining robust and fresh-smelling code in production.
At Makers, Code Review is an opportunity to give feedback, especially on readability. Theres no absolute measure for this, and using a linter to meet style guidelines is a good start. As long as your code is readable within your team, you’re good to go.
Approaching the code review process:
- Look at the list of commits to understand the journey. Add comments to the last commit to be relevant.
- Look at the README to get info on their approach, limitations etc…
- Verify if the User Story specs are in fact being tested. (If the code passes, try running some manual tests - do they work?)
- Read the code from the human perspective - that’s where your eyes can really add value, because you are human*. Does it tell like a story?
*’the reader is human’ is an assumption I made - assumptions can also be listed in the README!
Feedback Workshop
“People who go out and solicit negative feedback — meaning they aren’t just fishing for compliments — report higher satisfaction …They adapt more quickly to new roles, get higher performance reviews, and show others they are committed to doing their jobs.” Sheila Heen
To be effective at giving or receiving feedback, don’t think about positive or negative feedback. Giving feedback should be considered an act of kindness (although, it can be unskilfully delivered, which might not feel very kind). As a receiver, be empowered to place your boundaries and become more assertive; you can choose not to accept feedback that is not valuable to you. Having said that, be wary of discarding uncomfortable feedback - we all have blindspots. Consider as a giver/receiver, is your feedback useful and actionable? Also, try using a framework to make your feedback more effective and well received.
Top Tips for Feedback:
When giving feedback, what mindset are you delivering it with? Are you a sword, a doormat, or a lantern?
Giving feedback:
- Consider purpose
- Ask permission
- Be specific
- Thank them
- Ask for feedback
Receiving feedback:
- Get in the right headspace - or defer?
- Take time to respond
- (It’s ok to reject the feedback)
- Thank them
- State your intention - what will you do to grow?
Coding Challenges
This week I continued working on the Secret Diary project (still unfinished!). We spent the week pairing on a program replicating the Oystercard transport ticketing system. This weekend’s challenge was to create a Takeaway app, that sends an order confirmation with the delivery time. It made everyone hungry, I decided to make a mochi delivery service that guarantees delivery in 10 minutes! I WISH. I ran into problems with environment variables (used to keep private info like secure IDs and account numbers private) and overall this was a fun project - I want to complete & extend it to make a super cool app!
Quick Note on Feature Tests
I’ve spent a bit brain power on understanding feature tests. Feature tests look inward, and mimic the actions of the user, or a user journey. They can be small like a unit test or big like a function test. So far at Makers we’ve been writing feature tests in rib, but they could be written wherever.
