Generally speaking, when a software development organization says that they’re going or practicing agile development, they mean they’re following the Scrum methodology. Most jokes about doing software development have nothing to do idiosyncrasies of programming itself (Gary Bernhardt’s classic “Wat” presentation notwithstanding), but rather about dealing with Scrum. I get the frustration, As fun as it is to make fun of Scrum (and I’ve made my fair share of jokes about it), I really do think it’s a good development process (when done well), and that we would do well to keep it in mind. So having said that, here’s my attempt to defend Scrum.
1 of the most iconic components to running software in production are consoles full of graphs and metrics about how that software’s performing. Generally, they’re called “dashboards,” but in my experience you want something that provides the ability to act on the data being shown on the console as opposed to a dashboard which is generally read-only. That action could take the form of filtering or drilling down on the data being shown, or triggering some administrative task. Like with everything else in life, 1 size, or in this case 1 administrative console, doesn’t fit all. If you group the different types of users who have a need for an administrative console, you’ll find they fall into 3 general personas.
Part of having mature infrastructure management is treating infrastructure as code. If your infrastructure is on a public cloud, Terraform is a good choice for that “code.” It’s platform-agnostic (at least as agnostic as you’re going to get), easy to learn, and easy to run. If you’re coming from something platform-specific, like AWS’s CloudFormation, you’ll probably feel right at home with Terraform in short order.
Continue reading »As I noted in my last post, it’s really easy to hate meetings (I’m certainly not the biggest fan of them either), but that doesn’t mean that all meetings are inherently worthless. Some meetings can help give focus and clarity to your work, and that’s a requirements meeting.
Continue reading »Generally speaking, my posts are for people who are already working professionals. However, after a couple of spectacularly bad initial interviews (not even making it to a technical screen), I’m starting to think it may be prudent to offer some advice to the younger set hoping to become working professionals.
Continue reading »Following what’s probably a very predictable course of operational maturity, my team at work started out manually uploading jars onto VMs, maybe with a few simple services, scripts, and setup tricks to keep the manual steps for deploying software to a minimum. As the amount of code we wrote and maintained grew, we started to focus on automating more and more of our code deployments, with an emphasis both on rolling deployments (so there’s no visible downtime to users), and on increasing reliability by reducing the number of steps we could possibly mis-type or forget. Since our code was heavily deployed on AWS anyways, OpsWorks seemed like the perfect setup for us. So far, while it isn’t actually perfect, it’s been a good tool for getting our app deployments and instance configuration more automated, which is what we really needed.
Java 8 introduced a lot of cool features, 1 of the most useful of which was the stream()
method. This nifty little method lets you treat an Iterable as a stream, enabling cool things like lambdas operating over a list. Related to stream()
is parallelStream()
. This lets you group your stream into smaller streams that are run in, you guessed it, parallel. Specifically, your data is processed in a thread pool the size of the number of cores on your machine, minus the one running your app. That’s a handy piece of information you’re going to want to keep in mind before you start throwing this nifty little call around in your code. Continue reading »
For a while, I worked for a manager that wore a lot of different hats on our team, including that of “product manager.” Sadly, that meant he was often really busy and thus hard to pin down to get a product answer from. He knew that this was an issue, and wanted to get a full-time product manager for our team. At the time, I was thrilled about the idea. Fast forward a few months, and a little reorganization later, and our team now has a dedicated product manager, and I’m regretting my earlier enthusiasm. There seems to be a disconnect between product people and developers, so for any product managers reading this, here’s a few tips to help improve your interactions with developers.
The team I’m on at work currently has a remote developer. He’s very good, but he lives in another country, and is technically a contractor and not a full employee. That means there are restrictions on what he can and can’t have access to or do for us. These limits have started me wondering, at what point is a remote developer’s ability to contribute so limited that it limits their value to the organization as a whole?
We all work with somebody who’s day job appears to be best described with phrase “has and attends meetings.” Think of any product or project managers (there’s a difference between the 2 I’m told, but I couldn’t tell you what that was) at your office. They’re always in meetings, and it’s not at all uncommon for them to insist that you join them. In fact, it seems like the more you work directly with these managers, the more time you spend in meetings. The thing I have a hard time understanding is, if all you’re doing is sitting around in meetings, then at what point are you doing anything valuable for your employer or their software? Continue reading »