Flow can mean many things but when it comes to workflow it usually refers to that feeling, discussed by Mihaly Csikszentmihalyi, when you enter a state of intense focus and lose yourself in an activity. 

Video games are a great example. They take advantage of this feeling to keep you immersed, which is why it’s so easy for gamers to “lose time” and just get wrapped up. The same feeling usually drives your most productive and best work.

When you manage developers, their workflow should be treasured and valued. That’s why, to improve developer focus, it’s vital to avoid weighing them down with minor interruptions or non-urgent pings. 

“Flow is characterized as this experience where the task that you're doing is perfectly matched to the skills that you have.” -Katie Wilde on the Dev Interrupted Podcast at 7:51

1. Acknowledge that it take 23 minutes for devs just to get into flow

Did you know that it takes 23 minutes to get into a flow state? For some people it takes even longer. That means that for every question, disruption, email, and interruption that you or your coworkers are subjected to, it could be half an hour of productivity down the drain. We talked to Katie Wilde, VP of Engineering at Ambassador Labs, about how she manages workflow

“Say you got a Slack ping, and you're like, “oh, I'll just ask a question.” How long does it take you to find the thread again? What's that total interrupt time? It's 23 minutes…that's been measured.” -on the Dev Interrupted Podcast at 11:11

2. Defrag dev calendars

Some interruptions are unavoidable but many of them aren’t. Planning your calendar in a way that works around the needs and workflows of your team is necessary to maximize everyone's productivity. 

For instance, scheduling meetings on days when weekly meetings already occur can help preserve focus time by not disrupting other working days. 

Devs need to communicate with their managers on what times they have available away from normal workflow and then it’s up to engineering leaders to plan around those schedules. As a dev leader, you have to look at your devs’ calendars, not your own, and react accordingly. 

“If you're a manager, when you're scheduling, don't look at your calendar, and then find a time and then see where you can slot the engineer in…look at the engineer's calendar and see, where can you tack the meeting on that it is after another meeting, or it is maybe at the start of the day, the end of the day… and ask them!” -Katie Wilde on the Dev Interrupted Podcast at 12:31

3. Suck it up - schedule your work around focus time

When managing large numbers of devs, it can seem like a chore to work around many different schedules or attempting to get meetings done only on specific days. We asked Katie what her trick to juggling so many different calendars and meetings was, and she had one thing to say: “Suck it up.”

Devs are the backbone of software production and it’s important to prioritize their productivity whenever possible. To help them stay on task and be able to really focus on their work, they need to have meetings planned around their day - not yours.

Providing consistency for your devs - meeting them when they are ready, available, and focused - helps them maintain a flow state and maximize productivity. But more than that, it’s the right thing to do. Devs want to build cool stuff, not have their days ruined by their own calendars.   

Katie says it best:

“That might mean that, as the manager, you have a little bit weirder hours. I hate to say this, but kind of suck it up… There's no way to get around that.”-on the Dev Interrupted Podcast at 13:23

Watch the full interview-

If you would like to hear more about how managers can work around a developers schedule and other great insight from Katie Wilde, check out the full podcast on your favorite podcasting application, Apple Podcasts, Spotify, Stitcher, YouTube

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

In a typical manufacturing company, a supply chain is the chain of companies that you rely on to make your product. For example, a mobile phone manufacturer buys processor chips from a supplier. That supplier needs to buy a part from another manufacturer. And that manufacturer relies on yet another company for the raw metal.

But what is the software supply chain? And how do you keep it secure? We spoke with Kim Lewandowski, co-founder and head of product at Chainguard, to explain the details.

Your software supply chain is more complex than you think

The software supply chain can be complicated. Mainly because it’s difficult to know how far it reaches. Take a simple example: If you use Salesforce to keep track of your customers, you store your customers’ data on Salesforce’s servers. Not a problem, surely? But Salesforce could have a breach. And what about the servers themselves? Those servers might run on Windows. If that has a security bug, hackers have another way in. How about the software that Salesforce uses to host its website? If that is hacked, you have yet another breach.

 

“When I think of the software supply chain, it’s all the code and all the mechanics and the processes that went into delivering that core piece of software at the end,” Kim explained. “It’s all the bits and pieces that go into making these things.” -On the Dev Interrupted Podcast at 11:28

Keeping the software supply chain secure involves checking who has keys

The important part of keeping your supply chain secure is making sure that you track down what you’re using. And checking that they’re secure and reliable. Every new third party can be a potential problem. If you don’t do your due diligence, you won’t know what risks you’re taking.

As Kim explained, a favorite analogy of hers is thinking about doing construction work on your own home.

“You have a contractor. Well, they need keys. They have subcontractors. You give the keys out to all their subcontractors. Who are they? Where are they from? What materials are they bringing into your house?” -On the Dev Interrupted Podcast at 12:09

The more third party tools you use, the more out of control it can become

It all comes down to accountability. It can easily start spreading rapidly. One third-party tool that you use to create your software might rely on five separate third parties. And you don’t know what code they’ve got hidden under the hood. Your keys are suddenly all over the place.

The only way to keep it under control is to remind yourself to check and to do regular audits of the services you use. Kim believes it’s helpful to think of every new tool as a package coming to your home.

“How is your package getting to your house?” Kim said. “What truck is it riding on and who is driving those trucks?” -On the Dev Interrupted Podcast at 12:44

Get the full conversation

If you’d like to learn more about the software supply chain, and how to make sure that yours is secure, you can listen to the full conversation with Kim over on our podcast.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

Managing the software development process has been likened to herding cats. In other words, you can’t really do it, but you can sure give it the old college try. 

It’s no secret that managing the development of a software project is an imprecise science. Here are nine truisms that I’ve learned over the years that have helped me to understand the limitations of our ability to manage the strange world of software development projects.

1. Estimates Are Always Wrong

Whether you estimate something at one hour or one year, your estimate is wrong. That’s just the way it is. They won’t necessarily be extremely wrong — they might only be a little bit off — but they will be wrong.

If you look at a bug report and think, “That will take an hour to fix,” it almost certainly won’t take an hour. It might take 45 minutes, it might take three hours, but the chances of it taking exactly an hour — even give or take a minute or two — are slim. Now, you might say, “about an hour” instead. That’s a better estimate because actual, precise estimates are wrong.

Now for short projects that might take an hour, this isn’t a big deal. But…

2. The Bigger the Project, the Less Accurate Your Estimate Will Be

The bigger the project, the less precise the estimate will be — especially if estimation takes place at the very beginning of the project. As with the hour estimate above, if you estimate a project at a year, it might take nine months or 36 months. In some cases, it might take five years. There is no way to know when the project is starting out.

The bigger the project, the more “unknown unknowns” there are. There are usually more people involved. That is, as a project’s size increases, there are more variables and more things that will happen that you cannot anticipate. All of these things will add time to the project that you can’t plan for at the beginning because by definition you don’t know that they are going to happen.

3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities

When building software, the single most valuable thing required to complete a project is the ability of the developers on the team to concentrate in an undistracted manner.

The fewer distractions, the more productive the team will be. It’s really that simple. One of the main responsibilities of a software development manager is to reduce the number and duration of distractions to the team.

Software developers, when left alone, can be quite productive. When they are interrupted — whether for meetings or by people asking questions or anything else — they can lose that productivity very quickly. We all know about “flow” and how hard it is to get into the flow and stay there. That flow time should be valued like bitcoin and protected as such.

4. Hofstadter’s Law Is the Truth

Hofstadter’s Law is stated as follows:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Wikipedia

This is related to estimates, but it’s important to note the beauty of this aphorism. You can pad your estimates because you think it will help buy you time to get things done. You can add in extra factors, plan for “unknown unknowns,” and increase your estimates to take into account the belief that it will take longer than you think, but in the end, it will still almost always take you longer than you think to get a project done.

5. You Can Only Run in the Red for Very, Very Brief Periods

You can demand the team put in more hours, come in on weekends -- all those “crack the whip” kinds of things -- and you might get some (very) short-term gains out of that.

But if you try to make it the norm — if you try to run your team's engine at the red line of RPMs on a consistent basis — you will burn out the engine. You will see diminishing returns pretty quickly. Employees will leave. People, like race car engines, cannot be overstressed for extended periods of time without breaking down.

6. Brain Time Is More Important Than Butt Time

This one is so important, I wrote a whole blog post about it.

Nothing will decrease productivity more than demanding Butt Time (i.e. that your developers be seen sitting in their chairs for hours on end). You can measure Butt Time and feel like you’ve got a metric that will really show how productive people are being. But you’d be wrong. Demanding Butt Time will demoralize a team that really wants to spend Brain Time.

Brain Time is what really matters. Think about it this way: Let’s say you are a manager and it is most important for you to see your team sitting at their desks “working.” You wander around the office seeing those developers sitting in their chairs, pounding away at their keyboards. All is well with the world.

But then you run across one developer, and they’re just sitting there staring at their screen. That’s it. They’re sitting and staring. For like half an hour. What the heck! They’re not doing a thing!

But of course, they are. They’re thinking. They’re spending Brain Time solving a very difficult problem. Maybe they even get up and wander around the building for a while. In the end, they sit down, type 11 lines of code, and mark a user story complete.

Did they meet your “Butt Time” criteria? No. Did they produce an elegant solution to a very difficult problem? Yes.

Butt Time proves nothing. Brain Time means everything.

7. Hardware Is Cheaper Than Developer Time — Way Cheaper

Developers are expensive. You pay competitive salaries to attract top talent. An hour of their time is not cheap. Despite this, many companies don’t realize the incredible value of an hour of a developer’s time and skimp on hardware for the team.

But come on, computers are expensive! That extra RAM will bust the budget for hardware!

Well, it might bust the budget, but that’s because you’ve got a budget problem.

Look at it this way: Let’s say that you pay a developer $100,000 a year — or around $50 an hour. Let’s say they spend an hour a day waiting for the compiler to do its work. However, you could add some RAM and a faster processor to that developer's machine and cut that time down to 45 minutes a day. You save 15 minutes a day. At 200 days a year, that is 50 hours. At $50 an hour, that is $2,500 saved per developer per year. But what if the incremental cost of the faster machine is $500?

You get the point. If you have 20 developers, getting the faster machine saves you $40,000 for a $10,000 investment. That ought to be a no-brainer.

And that is only for the faster compile times. Everything else they do will be faster as well.

If your budget doesn’t allow for faster machines, then you need to adjust your budget.

8. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager

As far as I’m concerned, there is but one book that will teach you how to manage software developers: Peopleware by Tom DeMarco and Timothy Lister (be sure to get the third edition…).

This book is excellent, insightful, to the point, clear, and pulls no punches. It is full of wisdom about managing software projects and software developers. It is timeless.

Read it.

9. Quality Is a Perception — Not a Bug Count

This one is really hard to accept.

Here’s the basic premise: You can have close to zero bugs in your bug tracker and people can still think your software is buggy. You can have a large number of bugs in your bug tracker and people can think your software is as solid as a rock. There’s no correlation between the number of bugs in your tracking system and the perception of the quality of your software.

Now I’m not arguing that you shouldn’t try to reduce your bug count — quite the contrary. But in the end, your software can only be said to be of high quality if your customers perceive it that way — and your bug count won’t necessarily dictate that. Weird, huh?

And while we are on the subject, what does it mean to have a “high” bug count? What is the definition of “high” when your codebase has 100,000 lines of code? 5 million lines of code? Who’s to say?

Embrace Flexibility

Bringing a software project in for a safe landing on a short runway is a challenging and difficult proposition under the best of circumstances. Add in the ambiguities and all the things that can go wrong along the way, and it’s a miracle anything gets done. Development managers need to be flexible and take things as they come

The trick is to accept and understand those ambiguities and to work with them — not against them. Accepting these nine truisms will help with that.


Sponsored by LinearB

Want to reduce a lot of that ambiguity?  LinearB can closely track what is happening in your software pipeline, enabling more brain time, and automating things that require butt time. 

Book a demo today and find out how you can drastically reduce your code delivery times and continuously improve your development process.

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>