- A: Final Assessment: 3
- B: Independent Work & Projects: 3
- C: Group Work & Projects: 3
- D: Feedback & Community: 3
3: Developer completes sections 1 through 5 minor bugs and no missing functionality.
3: Developer generally writes clean Rails features that make smart use of Ruby, with some struggles in pushing logic down the stack. The application displays good judgement in modeling the problem as data. Developer can speak to choices made in the code and knows what every line of code is doing.
3: Developer writes solid Javascript code using common patterns and idioms. Code is organized appropriately within objects and functions. Developer can speak to choices made in the code and knows what every line of code is doing.
3: Developer writes tests that are effective validation of functionality, but don't drive the design. Developer uses integration tests, controller tests, and model tests where appropriate.
3: The application has many strong pages/interactions, but a few holes in lesser-used functionality.
4: The developer effectively uses Git branches and many small, atomic commits that document the evolution of their application.
I really wanted to make sure to have a solid back end and clean up some of the bugs on the front end. I was pretty pleased with my first Node API and I started to clean up some of the code on the front end. This is definitely something that I want to come back to once I have some free time.
I picked up one of the issues on the Turing Fridays app. The setup took longer than anticipated but once I got going it wasn't too bad. Below is my PR and my blog post.
I really wish that we could've done better on this project. We made the decision to try to get all of the functionality completed, sacrifice our testing, and make up the scores by taking some risks but it didn't work out for us. There were a few features that took longer than expected but I think we might have gotten there with an extra day.
2: Application is missing required functionality, deviates significantly from the spec, or serious bugs prevent features from being usable.
1: Team fails to effectively test the application.
3: Application is not confusing to use. HTML classes and IDs are kebab case.
3: Code logically divided into files. Developer can show examples of some SOLID concepts. Attention payed to indentation and naming.
3: Team is using the feature branches for small groups of cards, and has a pull request for each feature. Developers that aren't on the team have commented on PRs.
4: Team is using a project management tool and updating their progress daily. Team is approving each other's work. Team is documenting conversations and conclusions on relevant cards.
This project really tested my in a lot of different ways. I'm glad that my team chose to work on a brownfield project. I really enjoyed diving into someone else's code, trying to understand it, debugging and adding features on top of old code while keeping those who will come after in mind. I always knew that having a good test suite and documentation is important but after taking on this project I'll make sure that it's something that I keep in mind whenever I work on any project.
4: Tracker also documents feature related discussions.
3: Team is able to set and update expectations so that there are no surprises on the last day of the sprint.
3: Project exhibits maintainable well divided code. Developers are able to speak to architecture and implementation decisions.
3: Project has implemented one major technique that was new this week.
4: Project also features a screencast, tutorial or other wow factor.
3: Team has implemented code to increase accessibility.
3: Team is using well formatted user stories and moving cards through each status in realtime.
3: Team is able to set and update expectations so that there are no surprises on the last day of the sprint.
3: Project exhibits maintainable well divided code. Developers are able to speak to architecture and implementation decisions.
3: Project has implemented one major technique that was new this week.
3: Project features easy to navigate documentation showing how to setup and contribute to the application.
3: Team has implemented code to increase accessibility.
I really enjoyed working with Caroline on Quantified Self. She had a lot going on that week but always found a way to get everything done on time. She’s great at visualizing how the entire project is supposed to fit together and was able to get us organized which made it easy to get tasks done even though we worked remotely for most of the project. I appreciated how she always remained calm even though we had a short deadline on this project.
Briefcase was the second project that I got a chance to work with Laszlo. If I had to choose a team member for any project he would be at the top of my list. He makes a lot of great observations whenever the team is considering how a feature should be implemented. He takes ownership of important features and is willing to help the team in any way possible. He is also great to pair with and I’ve found that we get into a great flow whenever we’ve paired.
I really enjoyed working with Daniel on the Quantified Self project. He is laid back and really easy to get along with, and I think our work styles complemented each other. We worked remotely for most of the project, and Daniel was always great about communicating and he was always available to help when I got stuck on something. I appreciated the hard work and long hours he put in on our project.
Briefcase was the second project I got the opportunity to work with Daniel. Similar to last time a very positive experience. Daniel is very good at working through all the details of any assigned tasks. He is very detail oriented and great at explaining what he has done. We had several pairing sessions, which were extremely helpful to get familiar with an existing code base and successfully implement changes.
Pairing with students in Mod 1 made me realize how far I've come in just 7 months. I was pleased that I was able to provide guidance and reassurance to students that are just starting their own journey at Turing. Below are the names of the students I paired with along with the dates.
- March 28 - Yohanan Assefa
- March 31 - Charlie Corrigan
- April 3 - Kristen Mueller
- April 4 - Yohanan Assefa