While working in an agile environment, you may be assigned a user story that requires a very large amount of time and effort to implement. Typically, any user story estimated above a certain number of points should be broken down into multiple smaller, actionable user stories. Unfortunately, this does not always happen.
When I started on my current project, I noticed a few failing iOS builds on TeamCity that needed to be fixed. Since I was still on-boarding to the project and wanted to get my feet wet, I took it upon myself to resolve these issues as soon as possible.
Onboarding to a new project is difficult, whether you’re transitioning from an existing project or this is your first. Every project contains an intricate set of variables, processes, and tools to make it successful, and it’s your job to learn all of them by yesterday.
Recently, I’ve been working on taking better notes during team meetings. Notes help the team remember who’s supposed to handle getting which step done by what time. They’re also a great way to reflect on the discussions that were had during a meeting.
For a little more than a year now, I have spent a significant amount of time learning new programming languages and frameworks. With each new language/framework, there’s a chance that the value I receive will be greater than any of the languages/frameworks I have learned thus far. However, the opposite is also true.
While refactoring my current project, I needed to edit some fixture files that were used to populate data in a couple of UI components. Before diving straight in, I looked at these files and wondered how many ways there were to edit them.
I recently came across a Harvard Business Review (HBR) article by Daniel Markovitz called To-Do Lists Don’t Work and found it very insightful. I use to-do lists all the time, but I’ve never felt like they help as much as I expect them to—that is, until I started following the suggestion that Daniel mentions in […]
Over the past couple of months, I have expressed much interest in learning Clojure. The problem was that no matter how motivated I felt on any given day, I didn’t seem to put in the time and effort required to actually learn it. This was bothering me a quite a bit. After all, I had […]
During EmberConf 2017, I had the pleasure of attending Sarah Mei’s closing keynote on Livable Code. It encouraged me to think about making the current Ember application I work on more livable.
As software developers, one of the most common features we are asked to build is the automation of a predefined workflow. This benefits the client by increasing their capacity to pursue other tasks which require their attention, and it also improves the quality and reliability of the task being performed.