On Being an Effective Software Engineer: Don't Fall in Love

Dennis J. McWherter, Jr. bio photo By Dennis J. McWherter, Jr. Comment

You read that title right: don€™'t fall in love. But of course, you€™ve read enough cheeky blogs to know that I don€™t mean that in the traditional sense. If you have found or are looking for a significant other, go for it. If that€™s not for you, then don€™t. After all, you want a happy life as much as you want a successful life (I€™d argue the two aren€™t necessarily the same). In any case, I digress. What I mean to say is that you should never fall in love with the tools you use, the code you write, or otherwise. If you do this, you will likely fall behind and our industry isn€™t so forgiving for that. Let€™s examine this a little more closely.

First off, many engineers become €œreligious€ about their technologies. I think this often occurs due to, as Michael O. Church puts it, Never-Invent-Here Syndrome. In short, the only decisions that engineers have to make are in what technologies they will glue together to build the next product. Not only is this harmful for making the wrong decision in building the project but more importantly, as Church points out, if these tend to be your largest problems then you€™re problem not exercising your engineering skill enough. The result will be that your effectiveness and skills atrophy. This is detrimental to both you and your company.

Similarly, all technologies have their particular use case with important trade-offs. For instance, one problem make take me one-line in Haskell that takes me thirty lines of Java. However, since functional programming is still not widely adopted in the world (though select hybrid features are being taken from it), the one line of Haskell code may end up being less maintainable than the thirty lines of Java code (see: Combining Functional and Imperative Programming for Multicore Software: An Empirical Study Evaluating Scala and Java). Since fewer people actually understand Haskell and many people understand (or at least can fake that they understand) Java, it will likely be easier for a new developer to come in and make changes and fixes to the Java code.

NOTE: The debate between Haskell and Java (or simply functional vs. imperative languages) is for another post.

The same thing happens with libraries and tools. Popular libraries are useful within a company since people are likely to already know them. That is, from a company€™s perspective, time where employees are learning new technologies without producing substantial output (i.e. this usually happens one time for the first 3-6 months after hiring) is money lost. As a result, if you fall in love with a library or tool that solves your problem very well and elegantly (yet it is, for some reason or other, unpopular), it is still unlikely that your large company project will adopt this approach. Even though it may be the right tool for the job, we often think of these problems on a micro level instead of a macro level for the whole company. Loving this technology then does nothing but upset you when someone on a higher floor makes the decision for you to use something else.

Finally, as engineers we want to continue to explore the world. People are creating new things everyday (and so should you!) providing new solutions to all sorts of problems. By stubbornly attaching ourselves to a single technology, we deprive ourselves of growth and knowledge. If you want to continue to advance in your career, you must continue to learn. Yes, that even includes learning to play the game within the corporate structure.

In summary, getting attached to technology is generally a harmful practice. You may either atrophy your skills by deliberately refusing to learn other tech or you may be experiencing a problem in your current position (read: Never-Invent-Here). In any case, you can avoid such issues by being vigilant and learning whatever you can. When you have €œfully€ learned a stack in your day job, go home and look at other technologies which perform similar tasks. Learn about them and use them. If you have the power, you can try to incorporate better technologies into your workplace. However, if you cannot seem to break this potentially harmful cycle, then you€™ll be well-versed for your next interview!

comments powered by Disqus