Logging in your application is super important. Early on it’ll be fine to peruse your logs manually. As traffic increases you’ll soon have a need to aggregate all that data into one place so it can be easily searched. At Hudl, we chose Splunk. There are a lot of competing products, but it works well for us.
Either way my advice is clear: Log. All the things. You won’t regret it.
There are thousands of Android devices on the market running 18 different versions of the Android OS. It’s impossible to test every combination of OS version, hardware, and screen size in house - but you have to face the reality that your app will run on all those configurations once it goes live. And you will run into unforeseen problems.
How do you manage the fragmentation problem and minimize the risk of problems when it goes live? I’ll give you a hint: it doesn’t need to be expensive or complicated if you use the right process.
Until recently, product update meetings at Hudl sucked. They didn’t used to, but that’s one cost of growing a product team of 10 to a team of 40. We promised a brief, 5-minute update of what we’d been working on. Instead, we presented a 15-minute barrage of words, hand-wavings, and most shockingly, no demonstrations of actual software. Plus, if you couldn’t make the update meeting, you were SOL.
Those problems led us to try out a new video format for our weekly updates.
Quality Assurance is a crucial part of the software development process. But as a novice, it can seem daunting and unclear. After all, QA is responsible for ensuring the product is ready for the masses. What if I miss something? Where do I even begin with my testing? These were questions that plagued me at first. It took a month, but eventually I found myself growing more confident in my testing abilities and the impact I could make on Hudl’s products.
Before coming to Hudl in January, I spent more than five years as a developer at Microsoft working on Dynamics AX. It was your very typical, old-school software product. However, in my time here at Hudl, I’ve been thrown into the world of Software as a Service (SaaS) and have come to absolutely love it. There are so many reasons why SaaS is better but here are my top five reasons why developers should switch to building SaaS products.
The tech community has cherished remote work for literally tens of years. Many companies, including Hudl, allow employees in certain roles to work remotely. For tech startups like us, a huge benefit of remote work is that it allows us to look beyond the borders of Nebraska for top talent. We currently have remote workers based in California, New York, and Texas.
However, remote work has come under attack recently. My previous employer temporarily banned remote work after one employee started watching TV at home all day instead of working. Earlier this year, Marissa Meyer declared remote work to be verboten at Yahoo, prompting waves of outrage from the tech community. That news also led me into a Twitter argument on the subject with a friend of mine (side note: never argue with a lawyer on Twitter).
In the wake of that decision, and since we want to make life better for our own remote workers, we decided to try a little process experiment. One of our small feature teams (we call them squads) decided to work remotely for an entire week last month. None of that team’s members had ever worked from home for any extended period of time.