While taking a much-needed sabbatical, working as an airplane pilot, I wrote a Rails application, myFltTime.com , that pilots could use to track their flight time. With the MVP complete, I talked it around and got some pilots to try it. I added some features that they wanted.
I found some books about sales and marketing, about bootstrapping a startup, about pivoting, being responsive, and using agile processes to move toward something people want and will pay for.
In the end I spent much too much time building and too little time talking with people. Building is what I like doing. As I became more familiar with professional pilots I learned that, for the most part, they stop tracking their time once they start getting a paycheck for flying. (This result is not obvious. Pilots pretend to keep track. Learning that they don't do so formally: that requires some development of rapport, not a survey or casual query.)
Knowing that building is what I like doing, I don't mind signing-up to build something for someone else. At the same time, I understand the business. I understand what it means to create value and make things that people find valuable.
The Rails application I worked with at Rogue Wave had started at Rails 2. The application did source code scanning and open source governance. It had 163KLOC, 164 models; more than 60K users; a 200TB, five server HBase cluster with about one billion rows; and a five server Solr cluster with over 100M indexed documents. The application ran on four servers with twelve Unicorns each. We had four background process servers running Resque workers.
The application had models and controllers that had grown to fifteen hundred or two thousand lines. It had code in it that had been written nine years prior.
Some developers came to it and immediately wanted to rewrite and refactor everything. Not me. What would be the value in that? Why would we think we would do so much better?
Over and over we found things that were present for a reason that no-one had thought of since. The code represented hundreds of bug fixes and refinements. Doing things over in whole cloth would mean making new mistakes and repeating old ones. It really never makes sense to do that.
A little bit of refactoring is good if it's done to enable a new feature, to make that feature even possible, to keep the code clean, simple and dry across the extension. It's good to leave the code better than you find it. However when "refactoring" is really rewriting it's likely a waste of time.
That said, I'm much happier working on new features than trying to do surgery on someone's bloated code base. I keep it clean and well organized. Working code is good, yes. More than that, you can count on me not to produce a mess.
Another thing we did at Rogue Wave was rotate support duty. We had a role called, "Pierre". It was useful, rewarding, challenging, and instructive to help customers work through problems using our software. I liked it. Liked it and hated it, but mostly liked it. Our customers appreciated the communication I gave to them and that felt good. Making their problems disappear felt good.
When problems weren't simple usage issues (which can be instructive regarding interaction design and flow), they were often either logic or data errors on our part. Pierre could use database or Rails console commands to troubleshoot and make corrections. Occasionally Pierre would make a "hot-fix" change to the code base that was deployed outside of the flow of production releases. Other times, Pierre would prepare a fix for the current production release, or add an issue to be prioritized for future work.
Here are two recommendations from recent colleagues. First, my manager. He wasn't at all disappointed that he hired me.
"It was a pleasure to have Doug on my team for the past couple of years. Doug is a great senior engineer with strong skills in complicated logic and algorithms. He was able to dive in to extremely complex code, take methodical approaches to performance evaluations and isolate issues, and provide new solutions to solve issues. He has always been willing to speak out in constructive ways to question practices and decisions when necessary and to help keep the team on track, sticking to agile principles of creating quality software. Doug also continually stepped up to take care of support issues efficiently and effectively to provide outstanding service to our customers. Doug is a rock solid addition to any team."
This second came from a peer, who participated with us in a QA role:
"Doug is an excellent mentor and teammate. I found his work to be very reliable and well thought out. It was a pleasure to test code that he had written. He would often spend time to teach me strategies for simplifying and drying up difficult code. I am a more valuable engineer because of his willingness and patience.
"Working with Doug on our scrum team was great. He is always in a good mood and eager to get things rolling. My impression is that he is very dependable and accountable to the scrum process. I am certain that any team he is on will consider him to be invaluable also.
"I hope to work with Doug in the future."
"I really enjoyed reading this book. The author writes clearly and succinctly, focusing on potential points of confusion. His brief explanation of how XSL works in Appendix A is the best I've ever seen — short, but clear and explanatory."
You'll find substantial contributions on GitHub to tear-into regarding coding style. Some things you'll like. Others not. Please be gentle.
In general, I like clarity over cleverness. I'll favor directness over terseness. A reader shouldn't have to be as clever as the parser to figure-out the meaning of a statement or code block.
Code is best that is low in cyclomatic complexity, high in cohesion, well factored to avoid repetition. Code is best that is well organized into files and modules with a single area of concern. Code is best that does not have too many or too few methods. The implementations of those methods are not too long or too short.
In Rails, while learning, I put too much logic into controllers and too little into service objects. Controllers containing business logic are undesirable because controllers are a pain to test, thus not well tested. Service objects are relatively easy to test. I'm more or less converted to the advice about controllers in Henning Koch and Thomas Eisenbarth Growing Rails Applications in Practice .
In general, we know good code when we see it. I've been around long enough and cared enough, I hope, to internalize a lot of lessons about what constitutes well written code. I also understand that the best code is the code you finished yesterday, followed by the code you wrote last week, then the code you wrote last year, followed distantly by the code that anyone else has written. For that reason, I take care to try to learn from others and be flexible about adapting to the needs of the organization, team, and code base.
And I'm way beyond feeling a need to rewrite everything I see. The best code is working code that delivers value.
On the other hand, if you've been sloppy: If you have models with 10+KLOC and views strung throughout with business logic, I'm probably not your guy.
Every company likes self motivated and self directed achievers. I've told you about myFltTime.com. However also I have produced a substantial RoR code base for the International Aerobatic Club, IACCDB that keeps records of aerobatic competitions in the United States. Find the project open sourced on Github .
IACCDB enables pilots, judges, team managers, and organizers to know how they are doing, who is doing well, and to make decisions about how best to improve.
Pilots compete with each other in categories. Within a category, at a contest they fly multiple flight programs— up to three. Each pilot flies a sequence of as many as fifteen figures on each of their flights. Three, five, or as many as eleven judges on the ground watch the flight and give grades to each figure. There are about four dozen contests in the U.S. each year. IACCDB contains data going back to 2006, about eleven years. 6 * 5 * 2.5 * 12 * 3.5 * 45 * 11 = 1.6 million grades. It isn't Amazon scale data, but it's pretty good for one guy.
The biggest challenge with IACCDB has been maintaining clean data. That challenge is especially evident with the names of member participants. We have made improvements with the scoring program, but data still arrives with misspelled names and incorrect member numbers. For that reason, I've invested substantial effort into cleaning and merging member records.
If you glance at the schema for IACCDB you'll see that just about everything is tied to a member record. You'll understand how merging members can be a delicate proposition.
Getting back to the point, all of that work, every bit of it has been accomplished without a penny of renumeration and very little recognition. The IAC President gave me a nice plaque last year. All of the motivation has been internal.
I'm always interested to learn and apply new ways to create value. At Rouge Wave Software, I applied the Aho-Corasick string search algorithm to get three magnitude speed improvement from a text matching component. I recently took an online course about Machine Learning, and I'm currently learning how to use and apply the R programming language to some statistical problems in aerobatic contest results.
My best wishes for you to find a person who does well for your product. In essence, that is the name of the game and what I would deliver— good software that people find useful, from which they perceive great value. I hope I'm your choice. I'm ready to get to work for you. Let's get started.
Copyright (c) 2001 - 2017 Douglas Lovell