I'm a Software Engineer by trade -- developing embedded systems. I've worked mostly on larger embedded systems like the computers that control large aircraft, but I also work on smaller systems, like a computer that controls a single display in a small aircraft, or a PC that controls a vehicle test system. I've not really done the tiny kind of embedded systems like inside your microwave or your coffee maker. Some developers say those are a lot more fun and challenging. I'm learning. I hope to get there.
I've been developing software for 30 years now -- and as you can imagine, we've seen changes. Back in the day, the big discussion was whether to buy your PC at Radio Shack or call up Gateway. Can I afford to get the larger hard drive? Why bother? You'll never use the *whole* 10 Mb. You get the idea.
Even 10 years ago, the question at hand was "vi" or "emacs?" Today, few know what those are and fewer remember how to use them. Today, we're arguing over UltraEdit, SlickEdit, Sublime Text, Eclipse, or Visual Studio. The number of options for tools we use to do our jobs has changed drastically.
E-Mail used to be the communication medium of choice. We had "notes" forums also, for more collaborative chatting. Today, there's literally hundreds of chat choices. I was just getting the hang of using Google Hangouts to instantly interact with my team members, when today I was invited to "#Slack". After 10 minutes with slack, I was liking it a lot more. It has the ability to integrate with many of the other tools we're using, like GitHub and Jira. I've installed it on my cell phone as well, and I can keep in contact with my project teams _even while on vacation_. (Hey. Wait a second...)
But when do we have to admit that there are too many choices? The free software realm is HUGE and collaboration is run amok, so that there are dozens of potential solutions to the simple question of "how do I communicate with my coworkers effectively?" I was told today that slack is a good alternative to e-mail chains. But why do we need an alternative to e-mail chains? What makes the older methods necessarily "bad?"
This is one of my concerns with the younger engineers I'm working with. [In addition to my concern that I see myself as an "older engineer". That one worries me more, actually.] When is a tool "Good enough", and when is it better than always chasing the next good alternative to what I'm using today? When we change tools like we change shirts, day in and day out, we necessarily incur cost -- the overhead of acclimatizing to a new tool. Some tools take this into account and make themselves so easy to use that you don't feel the pain. I believe this is almost always done at the expense of flexibility and features. Simpler tools are simpler because they are simple. They don't offer as many complex features, and only support the 80% most common needs, leaving the 20% unsupported. And I almost always need the 20% because that's where the power comes from :-)
I read a story once about a lumberjack who entered a contest against another. The first began swinging his axe with all his might, powering through the massive trunk as fast as he could. The other sat down against his tree, dug his whetstone out of his pocket, and began spitting and rubbing, spitting and rubbing, polishing the edge of his blade till it shone with the sharpness of a finely honed peak. At the halfway mark, he stood, raised his axe, and began powering through his own trunk -- at more than twice the rate that the first man, with his dull axe, was chopping. The winner was the man who took the time to first sharpen his axe.
There's an advantage to taking the time to carefully select the tools that will make you productive in the development process. This is the edge that makes the difference between a good engineering team and a great one. However, once needs to be careful to minimize the impact of learning new tools, and not switch too often. Sharpening the axe for too long may simply consume your advantage, earning you nothing in the end.
The corollary to this story is just as important. There is *power* in keeping your edge sharp. An engineer that plows forward using the same old methods and the same old ways without learning from mistakes and learning new methods and new tools may think it an advantage, since he/she is adept at the tried and true methods and familiar tools. But as everything gets better with time, tools improve and change, and the engineer has to learn, improve and change as well, or he/she becomes dull with age. We become unable to recognize the slow decline in productivity, because we don't recognize the leaps in progress around us. Take time to sharpen your axe -- hone your edge. LEARN from those around you. But be wise enough to stop trying new tools early enough in the project to be successful with what you've learned. Balance in life seems to be a running theme. Balance is Good(tm).
Plan, Learn, Focus, Produce, Review, Change, Learn, Focus, Produce. Lather, Rinse, Repeat. Teach.
The Circle of Life.
Sing it with me. Hakuna, Matata. :-)
-dan'l
No comments:
Post a Comment