How To Talk About Deadlines At Work
- Wes Kao tl;dr: For both managers and direct reports. For managers: (1) Encourage your team to be honest about timing, especially high performers. (2) Temporarily “over-correct” to convince your team it’s safe to push back, celebrate their behavior when they do so. When they feel comfortable, become tactical. For reports: (3) Speak up at the first sign that you might miss a deadline. (4) Wes shares scripts of what to say. (5) Suffering in silence is not useful.featured in #500
How Uber Tripled Developer Productivity And What You Can Learn From That (Video)
- Debo Ray tl;dr: In 2016, as Uber’s engineering team grew beyond the hundreds, things started to break. Velocity averaged 1PR/developer / sprint. Production wasn’t doing well either. Over the next 5 years they introduced many changes and tools like Cerberus, SubmitQueue and DevPod to triple productivity. Many companies today are Uber in 2016 so Debo and Mihai, early Uber engineers, decided to share their story.featured in #500
An Evolutionary Approach To Staffing Software Product Teams
- Patrick Roos tl;dr: “A common pitfall that many companies face is the temptation to staff a product team quickly and from scratch with a large number of mostly external developers.” Phase (1): Lay the Foundations with a minimal team i.e. 1-3 entrepreneurial engineers and domain expert (2) Expand with precision: 1-2 engineers who match the culture and work ethic. (3) Scale through specialized feature teams.featured in #500
featured in #499
The Developer’s Guide to Directory Sync (SCIM)
tl;dr: SCIM is an open source protocol for implementing Directory Sync, which is crucial for user lifecycle management (user provisioning/deprovisioning). When selling to enterprises, this is a highly requested feature that can determine whether the deal goes through. However, when choosing to implement this yourself there are a number of pitfalls and implementation details to consider.featured in #499
featured in #499
Leadership Requires Taking Some Risk
- Will Larson tl;dr: Will discusses the scenarios when taking risks make the most sense as a leader. “Taking direct, personal risk is a prerequisite to taking ownership of interesting problems that matter to your company. A risk-free existence isn’t a leadership role, regardless of whatever your title might be. Indeed, an uncomfortable belief of mine is that leadership is predicated on risk. The upside is that almost all meaningful personal and career growth is hidden behind the risk-taking door. There’s a lot of interesting lessons to learn out there, and while you can learn a lot from others, some of them you have to learn yourself.”featured in #498
Are You Ready For PCI DSS 4.0?
- Robert Curlee tl;dr: If your organization handles or processes card payment data, an important milestone is upon you with the coming retirement of PCI DSS 3.2.1 and the following adoption of the new PCI DSS 4.0 standard. SonarQube can help you prepare for the new PCI DSS 4.0 requirements by identifying vulnerabilities, automating standards enforcement, conducting regular code reviews, and training developers on secure coding practices.featured in #498
Patterns Of Legacy Displacement
- Ian Cartwright Rob Horn James Lewis tl;dr: “We have spent most of the last couple of decades helping large organizations overhaul their legacy systems. In doing this we've learned a great deal about what works and seen many paths that lead to failure. We've decided to set aside some time to writing down what we've learned in the form of various patterns that we've seen used.” The authors believe the following four activities should be done in sequence: (1) Understand the outcomes you want to achieve. (2) Decide how to break the problem up into smaller parts. (3) Successfully deliver the parts. (4) Change the organization to allow this to happen on an ongoing basis.featured in #498
Estimating Software Projects: Breaking Down Tasks
- Jacob Kaplan-Moss tl;dr: Jacob describes his process: (1) Begin with a list of tasks or sketch. (2) Think through the steps you need to take to accomplish that task and write them down. Don’t worry about completeness. Each pass just needs to expand on the previous one. (3) For each item, ask the following: Do I understand what change is desired? Do I understand what “done” looks like? Can I define all the steps I would take to get to “done”? Do I have all the information I need? If the answer is “no”, take that task and break it down further using this algorithm again. (4) Repeat until all tasks are sufficiently broken down.featured in #497