Merriam Webster dictionary defines a toy as something that a child plays with. That’s the context in which the word is most used. But it also defines it as something, such as a preoccupation, that’s paltry or trifling. Kids obviously don’t think of toys as trivial; it’s us, the adults, who think they are. We also think that we give up toys as we grow up, suggesting that what we preoccupy ourselves with is somehow more important and serious. But that’s hardly true. We merely start playing more refined games, with more sophisticated toys. Money, ego, gadgets, fancy cars and other such material possessions are all toys in some sense. Our misplaced priorities make them far more important in our lives than they deserve to be. One thing that’s common between kids and adults is that we seldom think about the need, or utility, of toys. Kids, up to a certain age, can’t reason, and adults often don’t. Such desires come from a more primitive part of the brain. They are the answers that are handed to us down by somebody but to questions that we have long lost. I had never given much thought to what it means to be mature. But as I write this, it seems to me that an important part of maturing is one’s ability to reason about their emotions, behavior, and choices. That’s why we call people child-like, or immature, when they act like free spirits, doing things in a carefree way. What we mean when we say that is that they don’t think through things and that their choices don’t seem rational. While it’s good to be like that at times, in some form and fashion, it has its problems too.

In the world of software, tools, frameworks, and patterns are toys. Freshly minted engineers, like kids, are enamored by the world of infinite choices. They focus more on exploring what’s available than on their utility. Just as a child’s brain develops from being exposed to ideas, an engineer’s mind sharpens from being exposed to the possibilities of technology. Part of evolving as an engineer is to start seeing technology as a means to solve real-world problems rather than as an end in itself. By that definition, I feel like Silicon Valley has lost its way. Companies are increasingly coming up with solutions to problems of their own conception, and then trying to convince people about the existence of them. The power of technology and the maturity of people holding the power are heading in opposite directions.

In my first job after college I worked as a frontend engineer and was tasked with building web and mobile apps. Building user interfaces was not what I had in mind when I thought about putting my knowledge and skills in Computer Science into use. But as I grew more familiar with it, I came to love it more. I liked being able to see the product I was building, as I was building it, and to be able to see it from the lens of the customer. The field was also more dynamic than the backend ecosystem at the time. New frameworks and tools sprung up every day and like a kid who’s handed new toys, I enjoyed tinkering with them. Anything that was deemed cool drew my attention. My age and experience working in technology matched the age and maturity of the domain of frontend engineering itself. As this post says about the lifecycle of ecosystems, frontend engineering was accelerating in the phase of innovation while the backend ecosystem was thriving in the phase of commoditization.

A few years later, I went to graduate school, to study more of what I hadn’t used in my job. After school I got back into frontend engineering, to do more of what I didn’t learn in grad school. I don’t say that with the slightest of regret or guilt. It has taught me things that I would have otherwise never learned, most important of all, empathy for designers and frontend engineers. The realm of frontend engineering was markedly different relative to what it had been two years ago. In the time I did my Master’s, MVC frameworks in the browser gave way to reactive, event-driven systems. After a few more years of building user experiences at scale, I finally felt exhausted by the constant need to catch up with the trends of the industry. I found myself spending more time debating about the tools and frameworks rather than the problems we could solve. Backend engineering, at least from my vantage point, seemed like a more reasonable, a more stable, place. So I switched my focus to backend engineering a few years ago.

A similar change happened recently when engineering challenges started to hold less of my attention than the other critical aspects of the work we do – people, principles, and processes. I grew curious to explore the paths of management and leadership. To be an engineer is to focus on how to build good systems; to be a technologist is to also care about what and why we build systems using technology. Their value is not nearly as acknowledged by engineers, but it has been amazing to see how laying out the purpose and focusing on people, principles and processes organically lead to better engineering solutions.

These changes of perspectives and desires perhaps say something about my maturing as an engineer, a technologist, and a human. While no one decision, or choice, makes you mature, it’s the ability to reflect and reevaluate, to be more aware of what drives you, that hints at your maturity.