Tim's Triumph - He was required to participate in a coaching and mentoring workshop at his company. And, to top it off, she's proud of the fact that she was able to buckle-down and maintain a high standard of quality for her coding all the way to the very end! No cutting corners for this engineer! This is the culmination of weeks of hard work. Though, instead of hormones, we have event-streams, message queues, and pub-sub mechanism and, instead of cells, we have distributed, independently-scalable systems that are kept up-to-date through "eventually consistent" communications!Ĭarol's Triumph - Her team has moved all thirteen of their pending-work branches into testing. At the time, I had dismissed the thought as being crazy but, fast-forward to today, it turns out that my instincts were actually spot-on.
He's looking forward to the next 9-years!īen's Triumph (that's me) - I get a little nostalgic this week, recalling a thought I had 15-years ago about how amazing it would be to create a software system that worked like the human body, with cells that acted independently and communicated via hormones. Every day seems to be a stream of challenges which is exactly what makes the work so invigorating! When he thinks back to prior jobs that he has quit, they were always boring jobs building "forms over data" type products. Ben Nadel (that's me) → Website, Twitter, LinkedInĪdam's Triumph - He just had his 9-year work anniversary at AlumnIQ! And, as he reflects on the last 9-years, he's amazed to realize that he never wanted to quit.Adam Tuttle → Website, Twitter, LinkedIn.Plus, we find out that Carol can be bribed with tacos. And, of course, this is totally fine - every team has its own set of constraints that have bearing on how that team operates. This week, the crew meets to discuss my approach to Pull Requests, reaching consensus on some concepts and pushing-back strongly on others. The author of said PR has failed to decompose the problem into smaller, independently-deployable changes.Īs you can imagine, my "PR Commandments" don't work for everyone or every team. If a PR takes more than 15-minutes to review, the PR is too large. As such, if an open PR sits around for more than an hour, your team has failed to review said PR in a timely manner. For example:Ĭode completed is more important than code being written.
And, after working with git and GitHub for the last 10-years, I've formed a lot of strong opinions - oftentimes strongly held - about how Pull Requests (PRs) should be created and managed within a team context. I have "feelings" about many aspects of web application development.
0 kommentar(er)
