As an Engineering Mentor at MojoTech, my primary concern is the growth of our software engineers. I want folks to be thinking about how their career can grow and how MojoTech can grow with them. Helping our engineers navigate the demands of staying current, excelling at their job, and growing in a trajectory that they find rewarding is vital to their, mine, and MojoTech's success.
What Is Your Superpower?
A few years back, I read a chapter in a book by Zed Shaw. One of the points he touches on, that is relevant here, was the suggestion that writing software was best used like a superpower, used as a means to enhance some other skill or knowledge in another domain. If used in that fashion, it would be a big asset to you throughout your career. On the other side was a warning that if it were your only power, you ran the risk of being commodified (how many ads for Java Developer with 5 years of experience do you see?). The takeaway was that domain expertise paired with programming ability is where you can begin to set yourself apart. I'd worked for many years in the higher education sector and my knowledge of how the domain operated was at least as important as my engineering skills.
At a consulting firm like MojoTech, we're tasked with solving challenging problems for our clientele, who often operate in areas where we are not intimately familiar. So what is our domain? Our domain is software engineering.
The Technology Hamster Wheel
The challenge for our engineers is also made greater by the reality that most technical knowledge has a half-life. Not too many of us are using PL/SQL or Cold Fusion or Struts to build a web application theses days. All of those technologies, which required an investment of time have gone the way of the dodo. We see the same thing today at a more rapid pace with JavaScript frameworks. But at the same time, we need to know something to successfully build software and frameworks and libraries can save engineers tremendous amounts of time after up-front investment in time.
Faced with this conundrum, it is easy for a software engineer to wonder whether or not they are on some kind of a horrible technology skill hamster wheel. To ameliorate this concern, and help people with a path forward, we've broken down the skills required to be a successful engineer at MojoTech into three broad categories: Technology, Engineering, and Teamwork. And we also recognize that while the specific technologies are important, it is the Engineering and Teamwork skills that advance projects forward, year after year.
Teamwork skills transcend the discipline of software engineering, they are important for projects to succeed, but not specific to only software projects. Going forward, I will focus on the distinction between technology skills and engineering skills.
Defining Success
When looking at the individual skills in any one area, we try to look at them through the prism of the Dreyfus Model of Skill Acquisition and recognize that someone may be strong with one skill, but new to another. The Dreyfus model is somewhat of a formalization of the Medieval craftsman model wherein a particular skill, you advance through several stages to mastery. The hallmark of the transition is progressing from a contextless understanding of a skill to a point where the skill is seemingly as intuitive as breathing. We also recognize that not every tool in our skill set toolbox requires a level of mastery. While we require a level of proficiency at many technical skills, when we prioritize our growth and learning, we try to emphasize the skills that stay portable to the engineer.
Stepping off the Wheel
It can seem crazy to learn your third framework for building a dynamic web application, but if you've internalized the software design patterns that the frameworks embrace, and have learned the trade-offs that they make, you can quickly analyze whether the framework is valuable and the choice on whether to use it quickly boils down to a matter of syntax and whether its tradeoffs fit your needs. Building a strong foundation in engineering skills allows for a more rapid growth in technology skills. It facilitates a developing a breadth across technologies or delving more deeply into one as the need arises.
For the individual engineer, the approach I take to guiding them in their skill growth is to try to root it in their own interest. Nothing speeds the learning curve like a personal investment. If someone is interested in a particular technology, the next step would be to help them start seeing the patterns behind that technology. The understanding, forming, and generalizing of patterns in their heads increase their ability to solve problems beyond the specific technology they are working with. I suspect you've read lots of article or posts about building better abstractions or higher level abstractions in software. This is not something magical to software, it is how humans learn and think. You must understand basic concepts in any area, and incorporate them into your understanding before you can move on to harder concepts build on the earlier ones. New skills are reinforced by putting them into practice, and if an engineer is learning a skill based on their own interest, they are likely to put it into practice immediately.
Conclusion
Learning how to be an engineer instead of a technologist is an important distinction that will propel you through your career. There is nothing wrong with being a specialist, but placing that technical or domain specialty on top of a solid engineering-based understanding will allow our engineers to grow and stay relevant through their entire careers.
Dreyfus Model Image Source: https://www.cheatography.com/davidpol/cheat-sheets/dreyfus-model-of-skill-acquisition/