You know it within an hour of working with them. A special kind of sysadmin or developer that not only knows how to do their job, but really cares about doing it right. This is the person that makes you refactor that duplicate method or add that one last test. The kind of engineer that dots every i and crosses every t. David Lutz (@dlutzy) tweeted this last week “Of the IT professionals I’ve worked with, talented sysadmins and programmers, only a select few are worthy of the title Engineer.”, which really struck a chord with me.
I asked him what were the three common traits he thought these successful engineers exhibited, to which he replied “1. deep understanding of how things work. 2. thorough and methodical approach. 3. ongoing analysis of results”. I think he nailed this and I’d like to dig a bit deeper into each of these traits.
It’s one thing to be able to code to an API or install an OS from a CD. But, to really understand, on a system level, everything that’s happening in the background to make all the “magic” possible is a different level altogether. From taking measures to avoid race conditions in software, to ensuring an SCM based OS configuration for automatically bootstrapping new server instances, successful engineers employ these traits irregardless of time constraints.
For me, a deep understanding means decades of researching, experimenting with and testing of new technologies. I spent the first half of 2010 learning puppet and creating server configurations for not only my productive and staging environments, but the continuous integration server, wiki and blog. One year later, I’ve learned just as much about puppet (and my servers) as I did in those first intense six months. Do I have a deep understanding of puppet? Hell no.
Thorough and Methodical
So what about those pesky time constraints I mentioned. Unfortunately, they’re what make average developers bad developers. They are encouraged by management to “just finish it” at the cost of code quality, countless bugs and many late nights. How often have you heard a developer say “My manager says we don’t have time for tests.” ?
Successful engineers know that doing things right means taking the extra time needed to make sure that a feature or a service works exactly as expected. That means writing exhaustive tests and introducing monitors which ensure these things are up and running not only on the live site, but after every change made to the system.
Just because it’s out in the wild, doesn’t mean an engineer’s job is done. In the constant pursuit of perfection, they analyze how it’s performing – does it react to load and other issues as expected? Poring over megabytes of log files and checking those Cacti graphs every morning is just an ingrained habit by now.
As a system matures, usage changes, requirements change – refactoring and upgrades need to be regularly applied to keep the system healthy and growing. Often times, it’s those little tweaks months after the release that make or break the future of a platform. A simple query cache tweak here, or a refined Apache configuration there and suddenly the application is fun to use again.
Successful engineers know the intrinsic value of these often behind-the-scenes and unrewarded “patches”. They keep on doing it because they take pride in their work, and desire to honor the profession of engineering and engineers everywhere.
Twitter is such an incredibly cool platform. Being able to casually share such deep insights with like-minded people instantly is truly amazing. It’s exactly this kind of brain candy that has me totally hooked.
Who are some inspiring, successful engineers that you follow on Twitter? Please share with @mmarschall, @danackerson or in the comments below!
3 thoughts on “Top Three Traits of Successful Engineers”
Great post Dan (and the catalyst David).
I have found it quite rare for IT professionals to have 1 of these, let alone 3.
I am fortunate enough to work with people who really have all 3 of these. But Matthew is right: They are a rare breed.
Thanks for the great post!
Well said Dan!
One defense I’ll offer is that there are very few specialists today, we are frequently moved between differing tasks which totally kills #1 and then trickles down to a lackluster 2 and 3.
I’ve found that you can shortcut the time required for #1 if you can be provided the time to dive through the code… assuming you know the given language well enough to do that. Learning symptomatically/anecdotally is a slow and tedious process but often necessary due to the “just make it work” attitude.