Lesson Learned
When you’re cross-posting your writing to five different social media channels, it behooves you to proofread, especially that first sentence.
Thinking In Future Tense
Last night I was reading an article on characteristics of a good startup, and this nugget jumped out at me (it was originally said by Marc Benioff):
People overestimate what you can do in a year and they underestimate what you can do in a decade.
Software folks tend to be impatient for success, perhaps fueled by seeing the lucky few like Mark Zuckerberg who achieve near-instant greatness. The temptation of moving around to chase pay increases is also ever-present. And it’s really easy to get tired of a particular project at about the 80% complete mark and leave it unfinished (that’s worth a post all its own).
However, great products and great companies almost always take time to develop. And deep satisfaction awaits the person who, through years of toils, takes an idea to completion or builds a fantastic engineering culture. When I was (finally) looking for a change after 12 years at one place, why did I turn down offers from the typical dream companies? Because they’re essentially solved problems, and the chance to make a long-term transformation is minimal.
My current workplace is far from perfect. Without a doubt it’s been more challenging than I expected since I started 3 years ago. But I’m learning to be patient. There’s no guarantee of success, but if it comes, I know it’ll be more satisfying than if it had come quickly.
It reminds me of a story I heard from Andrew Peterson of the designers of Central Park. Told briefly, the folks who planted those first trees knew they would never even see the fruits of their labor, since a generation had to pass before their landscapes could mature. But what a result it was! That kind of patience inspired a great song and it inspires me as well.
Sidenote: the title of this post comes from a book I snatched from the free table outside the library at Judson Baptist Church in Nashville. I highly recommended it (the book, not the church).
Jud’s Law
The quality of a company’s conference room technology is inversely proportional to the quality of the technology developed at that company.
Developers Have Personalities
The first 12 years of my career I worked for a large defense contractor. One of the perks of a big company is opportunities for training, and in 2009 I had the privilege of taking a year-long “front-line” management class. Some of it was corporate drivel, but a surprising majority I found useful. One area of focus was on personality testing and analysis.
Why would that be of importance to managing a software team? Well, as I’ve said before, software is written by humans, and understanding how to get the best work out of said humans is a critical part of management. One way to do that is to learn the personalities of each member of the team.
During the training we used the Myers-Briggs Type Indicator, but the new hotness is the Enneagram. I’ve listened to a podcast and have also started a book on the topic, both of which were particularly focused on the spiritual aspects of self-understanding. But I think there’s plenty of cross-applicability to the world of management, and I look forward to exploring that in the coming days.
P.S. I walk the line between INTJ and INTP, and am either a Five or Nine (still figuring that one out).
The Other Full Stack
Typically when a software person says he is “full stack developer” what is meant is “I can do UI, business logic, and databases.” All well and good, those kind of folks are important to have around.
But there’s another dimension to development that I consider even more useful. Let’s call it the “life-cycle stack”:
“I can write requirements, design, implement, test, deploy, and maintain.”
An engineer who can do everything across that spectrum is tremendously valuable.
More Pascal
“If we look at our work immediately after completing it, we are still too involved; if too long afterwards, we cannot pick up the thread again.”
A big challenge for managing a software development team is the problem of context switching. Interruptions in general are productivity-killers, and it’s especially true of a discipline that requires sustained focus like coding.
But in addition to small-scale interruptions (of the 5-15 minute variety), large-scale switching of priorities can also have a disastrous effect on productivity. I’m thinking here of diversions of the 1 day to 1 week variety. Frederick Brooks couldn’t have been more right:
“How does a large software project get to be one year late? One day at a time!”
(You have read The Mythical Man-Month, right? If not, get thee to a library immediately. It’s required reading for anyone in the software profession).
I do my best to take the above warnings to heart, but it can be tough in the day-to-day realities of production bugs and last-minute requests. One way I try to mitigate is to serve as the buffer between my team and these sorts of interruptions. No doubt there’s a huge cost to my productivity, but I can plan for that when I recognize it as a critical part of my role.
Pascal’s observation has a second application to software development, one held in tension with the “no interruptions” philosophy: sometimes a developer needs to take a break from her current tasking to get refreshed and refocused. This can play itself out in a number of ways, whether it be jumping from front-end to back-end development for a few weeks to avoid getting pigeon-holed, to taking a half-day to go through a tutorial on a new technology, to simply grabbing coffee for 30 minutes and getting out of the cubical. Project planners would do well to build in significant amount of “productive diversions” into their roadmaps, and front-line managers should not get grumpy when they don’t see developers at their keyboards 9 hours straight.
Ultimately my philosophy is simple: trust your team to be professionals, and let the results be your guide.
Anomaly
Don’t think I’ll normally write on weekends, but thought it worth stopping by to say so, lest my throngs of anxious readers go wondering.
Wisdom Of Pascal
“I would have written a shorter letter, but I did not have the time.”
Blaise Pascal was a smart dude. Much of what he had to say is surprisingly applicable to software development (which is why if you show me a well-read developer I’ll show you a good developer). The above quote came to mind yesterday during an all-hands meeting where we were discussing our company core values:
“We build elegantly simple software.”
I love that sentiment. But make no mistake: elegance and simplicity take more time to build than complexity. This is true up and down the process, from prototyping, to requirements development (holy cow is this step often rushed; we’d do well to heed Mark Twain here), to implementation and testing.
My first task after moving to San Diego was to help a development team push through a particularly challenging set of features for a digital mapping system. Twelve hour days and weekend work was expected, and all tasks had to be done as quickly as possible. The technical architect had put together a mockup of a few of the screens using a prototyping tool, and unfortunately the quickest way to make those screens a reality was to copy and paste the auto-generated XAML (sort like Android’s XML-based UI markup, but for C#) and then tweak it. This led to a ton of duplication, with hard-coded screen positions everywhere. By the time we got the initial release of the application to the test team, it had become an unmanageable nightmare. But we limped along, duct taping bugs as they came up.
Then came the back-breaker, under the guise of a single requirement: “by the way, this needs to work in landscape as well as portrait orientation”. Just like that, our brittle implementation became untenable. It needed a complete re-write.
I was assigned the task, and (thankfully) given a month to do it. My delete key was never busier as I learned how to abstract and consolidate the XAML, replacing tons of repeated values and cleaning up duplication. Turns out XAML is pretty easy to author and has plenty of features for writing clean and responsive implementations, but no one had bothered to learn it. By the end of my process, in addition to adding a landscape capability, I’d shrunk the code base by over 90%, and gained a near 5x boost in performance to boot.
The moral of the story? Well, actually there’s two. The first is that using SLOC is a dumb measure of productivity (I was averaging about -10,000 lines written per day or something like that). And the second is that the best developers delete as much code as they write. Maybe even more. Refactoring isn’t a separate step on the task list; it’s part of every task. Yes it takes more time. Yes you might need to let go of your ego and trash that super clever function when it becomes unneeded. But your product will be better for it.
Pumping Iron
When I created this blog a couple of years ago, I’d been inspired by Soft Skills, a book of general life advice for software developers. It covered a range of topics, but one that particularly caught my attention was a recommendation to build an online presence through writing, primarily as a résumé building exercise.
That made a lot of sense, but I didn’t stick with it for long, perhaps because I wasn’t in the job market at the time. Nor am I now. So why the revival?
Part of that had to do with a conversation I had with our UX designer about domain names, which reminded me of how happy I’d been to snag this one. But the biggest reason was a side comment made in Joel Spolsky’s four-part series on writing effective software specifications:
Writing is a muscle. The more you write, the more you’ll be able to write. If you need to write specs and you can’t, start a journal, create a weblog, take a creative writing class, or just write a nice letter to every relative and college roommate you’ve blown off for the last 4 years. Anything that involves putting words down on paper will improve your spec writing skills.
The average software developer needs to write more than what you might expect, and those who do it well are rare. I want to be among them.
Say Hello
I checked my site statistics yesterday, and to my surprise, I actually had some visitors. The majority came from Twitter, which is funny because I don’t tweet except for when I post here.
Could you do me a favor? If you’re reading this, leave a quick comment so I know who’s reading. Thanks!