Thoughts on Software Development, Productivity, and other random things
In a previous post, I talked about what makes a good goal. Once you’ve done the hard work of setting the right goal, it’s time to start thinking about execution.
A goal without a completion date is a wish [1].
Now if you want to actually accomplish that goal, you are going to need a deadline.
John Allspaw has a great tweet on problem discovery:
Reminder that it takes just as much effort (time, money, staff, etc.) to build the wrong thing as it does the right thing.
Problem discovery is under appreciated as a practice in software engineering, especially when compared to problem solving.
— John Allspaw (@allspaw) April 27, 2018
I’ve always loved the tweet, but I only recently noticed the paper he cites in the thread. It’s called “The Art of Problem Discovery: Adaptive Thinking for Innovation and Growth”, by Brian Mathews.
In the prologue, the paper tells the origin story of Swiffer – Proctor & Gamble’s billion-dollar hit product line. It all started with a simple question: “how can we make the floors cleaner?”
Does the above sound familiar? If you have worked in an engineering department for any length of time, you have probably had this experience.
So what is going on here?
The problem is that there is a fundamental disconnect between the two people about what they are actually talking about. The product person thinks the engineer is talking about a calendar time estimate. But the engineer is thinking about an estimate in terms of the effort involved – one that is completely divorced from any specific calendar or scheduling considerations. This is one of the reasons why many projects are late.
Analytics are critical to success in business today. Businesses can’t expect to understand their customers or the best path forward without constantly leveraging and gaining insights from their data. Just like business leaders use analytics to be more effective, so too should engineering leaders!
Leveraging analytics in your daily work as an engineering manager will help you make better decisions and increase your confidence in those decisions. Simply put, if you build the skills up and use them – it’s like a superpower. It will open up a whole new world of opportunities to make you and your team more effective.
You’ve probably heard of Harvard Business Review, but have you heard of the HBR IdeaCast? It’s a fantastic and free podcast that summarizes a lot of content in the Harvard business review publication and it’s been running for well over a decade.
I’ve been burning through the archives and created a list of the best episodes I’ve listened to. Hopefully these episodes give a sense of some of the great material available on the podcast.
I’ve recently begun the practice of maintaining a working thoughts document. The idea behind this document is to work through difficult or interesting problems I’m dealing with on a day-to-day basis at work through writing.
Another year, another podcast blog post. I’ve been binging on leadership podcasts for the last few months, and have hit on some new gems. The crazy thing is how many of these podcasts are super new – like in the last year or so. In particular, leadership content catered specifically toward technology and software engineering leaders. So without further ado, here’s my roundup:
In part 2 of this series, I talked about the lower levels of the test pyramid: unit & integration tests. In this post, I’ll be focusing on the highest level of the pyramid: browser-based tests.
Browser-based tests are slow. Really slow. They run an order of magnitude slower than other tests. Large browser test suites can quickly bog down your CI pipeline. Make sure there’s a good reason to write a test case as a browser-based test and that it can’t be accomplished at a lower level of the pyramid.
The sweet spot for browser tests
In part 1 of this series, I talked about the test pyramid, and how to approach applying it in your testing process. In this post, I’m going to focus on the lower levels of the pyramid, where you should ideally be spending most of your time.
In this series of posts, I’m going to cover my views on software testing. I’ve spent a lot of time recently re-factoring some fairly large test suites, and would like to share some best practices I’ve learned a long the way.
In this first post, I’d like to cover some high-level testing strategies and my philosophy towards testing. In subsequent posts, I’m going to dive deeper into testing in each part of the stack.