I had the pleasure of keynoting at Ruby Nation where I expanded on one of the core values at Corgibytes: Communication Is Just As Important As Code. This post is pretty much a transcript of my talk. I got great feedback and am looking forward to presenting on this topic more.
If we want our developers to have more empathy for our customers, we as employers need to have more empathy for developers. We need to cast off the stereotype of good developers being only those people who are emotionless, data-driven, Spock-like caricatures, and embrace the fact that as humans, we all experience emotion.
I’m going to list tools and strategies that a state-of-the-art application development project should be using. Essentially a portrait of the infrastructure of a successful IBMi application start. I’ll start with suggestions on dealing with the daunting task of selecting a language and framework. Then, I’ll recommend tools for source control, testing, editing, collaborative communication, knowledge base management, and project management. And I’ll finish with some considerations for RPG integration strategies and database enhancements.
At Corgibytes, we have five core values: Think of Others, Calm the Chaos, Communication is Just as Important as Code, Adopt a Growth Mindset, and Craftsmanship in Context. These values are the nucleus of our company: the center of all decisions, big and small, for the Corgibytes executive team and staff. Here's a look at each one in detail.
How do you interrupt your engineers appropriately? At Corgibytes, we use Inception Layers do describe how interruptible we are.
When we put empathy at the center of our technology, human connection becomes stronger. Infusing empathy throughout your organization and development strategy can have profound positive impacts on customer loyalty, employee retention, and vendor service.
Integration tests? Unit tests? Acceptance tests? How do all these tests work together and what should you focus on first? We like to think of testing as a pyramid. The goal is to build an entire pyramid and keep it growing at scale.
Estimates are useful. They help business owners predict and control their budget, scope, and timelines. Right? Well, not always. Over the years, we’ve learned that there are some projects where estimates work great and others where it’s a disaster.
One of my current projects' Rails application is hosted on AWS OpsWorks. OpsWorks is a lower-cost alternative to Heroku and EngineYard that still provides a full-suite of features, from deployment to scalability and fail-over. As with most Rails applications, this application requires background tasks.
When I was interviewed by Corgibytes for a lead developer position, I was asked who were my role models. I responded David Heinemeier-Hansson (DHH) and Kent Beck. I expounded: DHH because he is a business developer rather than a computer scientist and he has great ideas about achieving excellence while maintaining a work/life balance. And furthermore Kent Beck because, as brilliant as he is, he still sees himself as a coder. Whatever.... The thing is, I lied.