This blog post is adapted from a discussion during an episode of our podcast, Code[ish].
Over the last twenty years, software development has advanced so rapidly that it's possible to create amazing user experiences, powerful machine learning algorithms, and memory efficient applications with incredible ease. But as the capabilities tech provides has changed, so too have the requirements of individual developers morphed to encompass a variety of skills. Not only should you be writing efficient code; you need to understand how that code communicates with all the other systems involved and make it all work together.
In this post, we'll explore how you can stay on top of the changing software development landscape, without sacrificing your desires to learn or the success of your product.
User experience depends on technical expertise
When the iPhone first came out in 2007, it was rather limited in technical capabilities. There was no support for multitasking and gestures, no ability to copy and paste text, and there wasn't any support for third-party software. It's not that these ideas were not useful, it’s just that the first generation of the phone's hardware and operating system could not support such features. This serves as a good example to underscore how UX has sometimes been constrained by technology.
Now, the situation has changed somewhat. Tools have advanced to the point where it's really easy to create a desktop or mobile app which accepts a variety of gestures and inputs. The consequences of this are twofold. First, users have come to expect a certain level of quality in software. Gone are the days of simply "throwing something together"; software, websites, and mobile apps all need to look polished. This requires developers to have a high level of design sensibility (or work with someone else who does). Second, it means that the role of the engineer has expanded beyond just writing code. They need to understand why they're building whatever it is they're building, why it's important to their users, and how it functionally integrates with the rest of the app. If you design an API, for example, you’ll need to secure it against abuse; if you design a custom search index, you need to make sure users can actually find what they’re looking for.
On the one hand, because you're running on the same devices and platforms as your users (whether that a smartphone or an operating system), you're intricately familiar with the best UI patterns—how a button should operate, which transitions to make between screens—because every other app has made similar considerations. But on the other hand, you also need to deal with details such as memory management and CPU load to ensure the app is running optimally.
It’s not enough for an app to work well, as it must also look good. It's important to find a balance of both design sensibilities and technical limitations—or at least, a baseline knowledge of how everything works—in order to ship quality software.
Follow everything but only learn some things
When it comes to personal growth, learning to prioritize solutions to the problems you encounter can be critical in your development. For example, suppose you notice one day that your Postgres queries are executing slower than you would like. You should have a general awareness of how higher rates of traffic affects your database querying strategies, or how frequent writes affect the physical tables on disk. But that doesn't necessarily mean that you should sink a massive amount of time and effort to fine-tune these issues towards the most optimal strategy. When developing software, you will always have one of several choices to make, and rarely does one become the only true path forward. Sometimes, having the insight to know the trade-offs and accepting one sub-optimal approach above another makes it easier to cut losses and focus on the parts of your software which matter.
Sometimes, having the insight to know the trade-offs and accepting one sub-optimal approach above another makes it easier to cut losses and focus on the parts of your software which matter.
It seems like every year, a new web framework or programming language is released. This makes it difficult, if not impossible, to follow every single new item when they are announced. The inverse is also true. We might feel that adopting new technologies is one way to stay "relevant," but this attitude can be quite dangerous. If you are an early adopter, you run the risk of being on the hook for finding bugs, distracting you from your actual goal of shipping features for your own application. You should take a calculated approach to the pros and cons of any new tech. For example, switching your database entirely to MemSQL because you heard it's "faster" is less reasonable than making a switch after reading someone's careful evaluation of the technology, and realizing that it matched your own needs as well.
Keeping calm and steady
At the end of the day, you should be very invested in your own stack and the ecosystem you work in. That work can be something as simple as reading Medium posts or following Twitter accounts. Broaden your knowledge of other services outside your own realm of expertise only if you come across someone confronting problems similar to yours. You should own tools which you know how to operate, rather than keep a shed full of all sorts of shiny objects.