A system for killing disruptions
Subscribe to Engineering Impact, the weekly newsletter for managers of software teams.
This week: Writing effective job listings, a system for killing disruptions, smart pointers and moving semantics, 5 development metrics you should care about.
Kasra Rahjerdi discusses some of the things that software leaders shouldn’t do when writing job listings for developers. This post focuses on listings that squander the opportunity to attract top candidates by only appearing to be interesting.
Software managers routinely use stock phrases in job listing that don’t really tell the reader anything, especially when talking about the company or requirements for the position. For example, phrases such as “collaborative software development shop” are just noise since they apply to all developer jobs.
A job listing should have a high signal-to-noise ratio to minimize the effort required to determine if it’s applicable to the reader. Each step needed to make this assessment is another opportunity to move on to the next listing. A poor listing negates the benefits of an interesting ad by forcing the reader to work for the information they need.
Disruptions are the primary killer of developer productivity, according to Jon Dowdle. Specific examples include drop-in managers and email, but all disruptions interrupt an engineer’s workflow. Developers are typically able to work for only two hours each day without disruption, which often causes them to wonder what they accomplished during a long day. Developer heroes are one solution to the problem of frequent disruptions. These people are the development team’s representative to the rest of the organization.
A hero’s primary responsibility is to handle these disruptions, allowing developers to focus on their work. This responsibility helps developers, although it doesn’t go very far on its own. The second responsibility of a hero is to develop automated responses for issues that occur frequently. This responsibility becomes more important as the organization grows and is needed to prevent the hero from becoming overwhelmed.
O’Reilly discusses the benefits of smart pointers in C++. Developers generally consider modern C++ to begin with the C++11 standard, which was implemented in 2011. The C++14 standard implemented in 2014 completed the feature set that the C++ standards committee has been developing since the last major update in 1998. Modern C++ has many features that improve performance, including smart pointers.
Raw pointers are prone to errors, but programs that use them run extremely quickly because they’re so close to machine code. Applications that require maximum performance have used raw pointers for decades despite the development costs of long debugging sessions due to memory leaks and segfaults. Raw pointers also require programmers to repeatedly initialize them and release dynamic memory.
Smart pointers can mitigate the problems of raw pointers or eliminate them entirely. These class templates encapsulate raw pointers and significantly improve their reliability. C++11 supports smart pointers, and code written in C++14 doesn’t need raw pointers at all. Furthermore, C++14 code rarely requires raw delete and new operators.
In our latest blog post, Travis Kimmel writes about top 5 developer metrics every software manager should care about. Version control data from code repositories such as BitBucket, GitHub and GitLab can provide a variety of developer metrics leading to insights into an engineer’s work patterns in real time. Click here to read the full post.
If you enjoy Engineering Impact, sign up to get it weekly.
Ben Thompson is a co-founder at GitPrime where he leads design and customer experience. He is a Y Combinator alumni, with a background in product design, branding, and UX design. Follow @thebent on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.