We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level, we put teammates first by using code reviews as a way to help them do their best work, and we ensure we consistently ship high quality code.
Expectations / Description
- We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level. Questions we may ask during these reviews:
- What is the problem that this change is designed to solve?
- What is the proposed change? Include details, especially where there is some risk.
- How does this change impact other systems? How does it impact the codebase?
- What are the risks of this change?
- What alternatives are there, and what are the drawbacks of those alternatives?
- What data backs up the proposed change?
- We put teammates first by using code reviews as a way to help them do their best work
- We offer advice and resources to share knowledge and teach others
- We discuss the advantages and disadvantages of different approaches
- We ensure we consistently ship high quality code
- We have a higher than average code review ratio so that we can share knowledge with others and keep stories moving forward while keeping in mind how changes might affect dependencies, engineers, users, the codebase itself. . We may give feedback on (but not limited to):
- Dependencies
- Test coverage
- System level impact
- Performance concerns
- Security concerns
- Architectural pattern concerns
- We have a higher than average code review ratio so that we can share knowledge with others and keep stories moving forward while keeping in mind how changes might affect dependencies, engineers, users, the codebase itself. . We may give feedback on (but not limited to):
Handbook
- More details exist within the Architects handbook
Requirements
- Back End Architect's must have a position with the reach of 2.3 or higher
- Back End Architect's must be milestone 3+,Ruby
- Back End Architect's must be milestone 3+,Data
- Back End Architect's must be milestone 3+,Rails
- Back End Architect's must be milestone 3+,Collaboration
- Back End Architect's must be milestone 2+,Infrastructure
- Back End Architect's must be milestone 3+,Estimation
- Back End Architect's must be milestone 3+,Engineering Communication
Configuration Health
- ✅ Has 7 Abilities
- ✅ Is a part of 7 Positions
- ✅ Has been referenced in 3 pieces of public recognition
- ℹ️ Fewer than five people (1) have reacted to this Assignment. To ensure anonymity, analysis will only appear after at least five people have reacted.
- ℹ️ Fewer than five people (1) have an official rating on this Assignment. To ensure anonymity, analysis will only appear after at least five people have ratings.
- ⛔️ Last updated: over 4 years ago
- ℹ️ Never conversed about
Examples / Observations
Observation created almost 6 years agoFeaturing:Alec R.Ethan M.Waseem D.We share before we're readyDecomposition & SequencingEpic shaperFront-end architectBack-end architectThis thread speaks to it: https://lessonly.slack.com/archives/CPHPVJSTH/p1574698910011200
This is a great discussion and approach to taking on what could be a larger project in Linked Elements. The team was able to work together to identify and slice up the work in order to get value into the hands of customer faster. Alec said it in his summary here:
We are going to structure the epics so at the end of each element the element is fully implemented. This means that at the end of epic two the paragraph element will have all of the linked element functionality. Then epic three will be the photo element fully implemented.
- This will mirror how the platform team rolled out a role management, a fully functional piece of a larger whole. This means we can learn more about the entire linked element process earlier.
- It gets to value quickly. We have been hearing for years from clients about the linked element functionality. With this plan, we will allow admins to do this whole process faster!
- It will make the delivery manager role more smooth. Because of this plan, each epic will look similar technically speaking. The first element will take the longest because we have to implement all of Linked elements but after we will be able to determine with reasonable accuracy how long each element takes to build start to finish.
As a result...
- This enables the squad in efforts of successful decomposition of ideas into shippable units of work to deliver customer value, validate P&E assumptions, or both
- Developing right-size slices of work that fit into the checkpoint and quarterly goals
- Thinking through the stack in a way that promotes flexible story creation (e.g. model/database, API, routes, react components, UI).
- Your squad consistently gets slices of work into customers hands for testing as early as possible in the lifespan of a project
Observation created about 6 years agoFeaturing:Kyle W.We don't wait to be told what to do, we take initiativeWe put the team before ourselvesWe represent Lessonly positively in the communityWe put learners firstBack-end architectBack-end engineerImplementation engineerTechnical investigatorTier-3 escalation engineerMultiple times over the last few months (and likely the last few years), Kyle has been working closely with Karlie and the US Cellular team on their integrations/enhancements/all the things. This has required him to jump on multiple phone calls and to work ridiculously late hours; a few times, he's been up in the middle of the night for a few hours to make sure everything worked as expected. Each time he's done this, he's still been a team player first thing the next morning. I appreciate his willingness to always take this on and do it with a positive attitude. Thanks, Kyle!
Observation created over 6 years agoSo Tom was promoted to a new level of software engineer a month or two ago and it was well desearved in my opinion. But that's not what this is about. This is about how Tom hasn't stopped progressing. Most recently Tom has taken the lead on defining the architecture of Draft Mode and done so in a way that has made it seem like he is a seasoned vet who has been here well beyond the years he has been here. He has put together a POC and written up the architecture review doc that will be shared with the architects tomorrow. It could have been easy to let a more tenured engineer take the lead on this, but Tom stepped up to the challenge and I think we are better off because of it!
Thanks Tom!
Official Back End Architects
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Teams needing a Back-end Architect
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Positions that reference being a Back-end Architect
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Conversations about Back-end architect
This section is for Lessonly folks only. Sign your team up to find your Gruuv!