I was the go-to for tracking down crazy bugs. It can seem like I pick up new skills quickly, but the reality is I just have a bulldoggish stubbornness that won’t let go until I’ve grasped a new skill or concept. The same stubbornness made me track down bugs from vague error messages or inconsistent user stories. This also gave me a very in depth knowledge of our code base. Several big issues involved our custom Freemarker templates, Struts validations, and our custom data merging strategy that allowed several people to work on the same data sets at the same time without completely wiping out each other’s changes. In the process of digging deep into the code, I vastly improved our logging in several applicationss to help future developers track down issues faster.
I’m a big fan of TDD as my brain often jumps ahead of my fingers, and TDD makes sure I stay on track with all my objectives. It’s also been instrumental in my ability to track down bugs quickly. When I started at Franklin American, the standard mocking library was EasyMock. I found it complicated to read and the error messages frustratingly vague. After researching, I implemented and championed the use of Mockito, which is the standard there today.
Most of my experience is working within previously setup Spring applications, but in our last company Hackathon, I took the opportunity to start a Spring application from scratch (using Spring Boot). I have some exposure to Play, and though the company decided to go in a different direction, I really like Play’s ability to hot-reload without having to resort to a third-party software like JRebel and its non-blocking I/O.
I cross-trained in-house for several months as a SQL developer, which probably makes me slightly more dangerous than your average bear, learning about views, stored procedures and unions. The most terrifying year of my life was when I was the sole project owner of our Sugar CRM, which included the entire responsibility of managing all stages of its MySQL DB, from test to production. As terrifying as it was, I never had a critical production issue.
Ruby on Rails
I created my sales tracking application for authors with Ruby on Rails so that I could learn a new language and quickly get an MVP up and running. I’ve loved how quickly I’ve been able to prototype my idea with Ruby. I also appreciate Rails’ built in testing support that encourages TDD.
I’ve found that I’m most productive when there are little or no barriers between the user and myself. There’s no substitute for watching a user actually interact with software, whether in person or over a screen share. I’ve eliminated several cycles of development/testing when I can watch the user and we can talk about the application simultaneously.
I was initially hired as a PHP developer, but as we migrated away from Sugar CRM to Salesforce, I migrated to mostly Java. I continue to work with PHP in the WordPress framework, tweaking themes and creating plugins.