.svg)
.avif)
What your Software Engineers want you to know
It takes a well-rounded team with different skills and roles to build and grow a successful software product and company, but all too often, we find that our teams or team members are working in silos. And if you don’t fully understand what other are doing (or why), your team can’t work to its full potential.
With this series, we’ll be digging into the various members of your team to help you understand and work better with them all. This week, we’re talking about what matters to software engineers.
It’s the software engineer’s job to bring product ideas to life. Depending on the specific engineer and their role, they’re often also responsible for debugging code (and sometimes hardware), helping to set and maintain the systems that keep things up and running, and dive in when bugs appear or sites crash.
So, given everything that’s on their plates, what matters to software engineers the most?
Engineers need an interruption-free environment
Whether it comes in the form of an impromptu meeting, a phone call, a Slack message, or a tap on the shoulder, interruptions are the bane of an engineer’s existence. As influential developer and investor Paul Graham puts it in his evergreen Maker’s Schedule, Manager’s Schedule blog post, people who create things “generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour.”
The engineers I spoke with echoed this, with many saying they wish more managers understood the need for heads-down time.
One engineer here at Shortcut noted, “One of my biggest struggles is saying, ‘Okay, I need to get some work done now,’ without it coming off as rude.” Another added that he marks off heads-down time on his calendar so he doesn’t get interrupted by other team members.
Jen Hamilton, an iOS developer, agrees. “Having to start and stop throughout the day severely impacts my productivity, as do open offices. It might take me 15 minutes to get far enough into the code to understand how something works, and then I can start working on it. Every time I’m interrupted, it’s another 15 minutes wasted.”
{{testimonial-component}}
There’s actually science to back this up. Every time you’re interrupted, you switch the task that your brain is focusing on, and the result is a “switching cost.” This is why multitasking is actually not a very productive strategy. Switching costs can lower productivity by up to 40% — so make sure to give your engineers the heads-down time they need to focus!
In short: unless it’s an emergency, engineers would prefer that you schedule a time to meet with them.
If you see them with their headphones on, staring intently at their screen, think twice before you nudge them…even if it’s for lunch or coffee!
Software engineers really do want regular and open communication
Though engineers want to keep distractions to a minimum, they also want to be kept in the loop about what is happening on the team and in the organization.
That way, they have the opportunity to quickly speak up if think an issue might arise or has already arisen.
In order to manage the balance the need for heads down time with the desire for communication, it can be helpful to let your engineers stack meetings back to back (preferably in the morning) , so that there’s less interruptions and they don’t have to figure out how to get back in the flow of work.
Daily standups are great for staying informed, and many engineers also expressed a desire for regular one-on-ones. The privacy of a one-on-one allows developers to get crucial feedback without feeling like they’re being dressed down in front of the entire team.
It’s also a good idea to make sure engineers know that they can schedule one on one meetings with people who aren’t managers — whether it’s other developers on the team, designers, marketers, etc. That lets them discuss how things are going, what they need from each other, and give feedback openly without having to use a manager as a go-between.
Software engineers don’t think estimates are budgets
Estimates are a hot topic among engineers (and others!). “Estimates aren’t a budget, they’re an estimate — but when you give a rough timeframe, people tend to think you’re saying it will absolutely be done by the end of that timeframe,” said one engineer. Another noted that they’ve worked with project managers and estimated that something would take 5–10 days, only to see that comment turned into “feature X will definitely be done in 5 days.”
Engineers don’t want estimates to be used as weapon against them. Sometimes things come up that aren’t foreseeable, or the scope gets changed, or a feature gets cut and that changes how other features work together. In any of these instances, estimates might turn out to be off track — but it’s not necessarily the engineer’s fault.
If an engineer tells you they’re running behind (and it’s not because of an error on their end), the best response isn’t getting angry at them for not doing their job but to thank them for the update and update the other people who need to know.
Software engineers need clear, detailed specs
Balancing the right amount of details in a spec doc can be difficult to do, but it can do a lot for relieving engineer frustration. If it’s too broad, your engineers wind up having to make a lot of decisions about how something is implemented as they’re coding.
The end result is that they’re often asked why something works a certain way, and the answer is “that way was the easiest way to get the end result you wanted.”
Engineers can struggle to explain the implementation of a specific feature to someone who doesn’t care about the back-end details, but instead cares about the behavior.
On a similar note, Mel Reams, senior developer at Referral SaaSquatch, says “One thing that I really wish non-developers knew is that ‘Can we do ?’ isn’t a useful question. Just about anything can be done…but it might take a research team and five years.”
<!-- Code for Testimonial component starts here-->
<div fs-richtext-component="testimonial-component" class="post_body_testimonial"><div class="post_body_testimonial-content"><div class="text-size-medium">
"One thing that I really wish non-developers knew is that ‘Can we do ____?’ isn’t a useful question. Just about anything can be done…but it might take a research team and five years."
</div><div class="post_body_testimonial-name"><div class="semi-para-title">
Mel Reams
</div><div class="semi-para-title">
Senior Developer at Referral SaaSquatch
</div></div></div>
<img src="" loading="lazy" alt="" class="post_body_testimonial-image"></div>
<!-- Code for Testimonial component ends here-->
On the other hand, our engineers noted that getting specs from a designer is often much less frustrating — they’re often super specific and note test cases. With these sort of specs, the engineer is presented with a specific problem to solve, and has a much easier time approaching it.
If you’re stuck when talking about a specific feature with an engineer, it might be time to pull a designer into the mix and see if they can be a go-between.
Software engineers are wary of trends
Similar to the vague/specific balance that engineers deal with in spec docs, there’s also a trendy/reliable balance that production-grade software needs to achieve.
Too often engineers find management coming to them and asking, “Why aren’t we using (insert trendy new tool or language here)?”
There’s always a tradeoff that comes with using the cool new thing. It takes time to adopt, and often, it’s not as stable as the old way. Engineers aren’t usually thrilled about doing the new thing for the sake of the new thing. They’d rather fix the existing infrastructure, and explore ways to extend its functionality.
Ruthan Freese, another software engineer, notes that these “let’s incorporate the hot new thing!” whims often happen in the middle of the project — serving as both an interruption and an unclear spec.
She says, “Scope creep is my mortal enemy as an engineer, so it’s especially frustrating when there are changes suggested mid-project, that come from internal requests and essentially boil down to, ‘Did we think about doing this new cool thing? We should try it!’”
If there is a good reason behind wanting to try Cool New Tool Y, let your engineers know what it is.
When you make it clear what it is you want to accomplish, your engineering team can work with you to explore the different avenues you can take to solve the core problem, instead of simply handing off deliverables that just obscure the problem at hand.
That said, if a new tool isn’t being forced on an engineer and they have freedom and time to experiment, it can be fun and engaging to work with a new technology.
Getting to use cutting-edge tools like Datomic and Clojure is one reason our engineers like working at Shortcut.
If you’re a software engineer, we’d love to learn more about what makes your days easier - let us know on Twitter!