In a previous post of mine I asked the question: do programmers get bored? And yes, sometimes they do, especially if there are no challenges.
The usual software project out there is trivial – implementing business case after business case. But programmers still find challenges even in the trivial applications and websites they are writing:
- Complex user interface – implementing a complex UI on the web is a good challenge – often good components come out of that, that are later open-sourced and have the potential of getting popular. And if you are really good, you may solve a problem that many people have and make your component a standard solution.
- Architecture – if a system is big, the architecture matters. Separating components and deciding on the way they communicate is a challenge that requires both advanced skills in concrete technologies and the ability to get a good overview on a complex system.
- Big data – if you are lucky enough to work at a company that handles billions of records, you would be required to solve problems related to that previously unusual amounts of data. That requires deep understanding in databases and strategies for distributing and synchronizing data. As a result tools or even new databases can emerge. Look at Cassandra, for example, which was initially developed inside Facebook.
- Algorithms – it is rare that a business application requires complex algorithms, but in case there is, this is a great point for putting your efforts into and get satisfaction from your work. For example, you can optimize the delivery routes of a transport company, which in turn saves thousands of dollars for fuel. If you can do that, not only the clients will be happy (which is rarely an incentive for developers), but you will be happy as well for having cracked down a complex problem.
- Low-level implementations. Normally you work with tools and frameworks that are already developed and stable. However, sometimes you need to implement some low-level detail yourself. My most recent experience is the connection pooling and high-availability for a RabbitMQ client. It is a gratifying experience when you finally see that thing working properly in production, under heavy load, and allowing for any node to go down without affecting the system health. Other examples may include distributing scheduled jobs, augmenting a distributed cache solution with additional eviction policies, etc.
- Open-ended problems. There are problems that don’t have a solution yet. There are problems that are not known to be problems yet. Web search was such an unsolved (or poorly-solved) problem back in the nineties, when Google solved it. You rarely find these problems in a regular company, so you usually have to take them up yourself at home. My most recent example is my algorithmic music generation service
The list is not exhaustive, of course (feel free to add to the list in the comments), but you get the idea – even in regular companies there can be tasks that go out of the standard business-requirement box which makes you bored. If you are good at what you do, you have a chance of picking these tasks yourself. Note a common pitfall here – if something sounds cool and challenging it isn’t automatically something to go for. Writing an ORM is challenging, but you should instead reuse an existing one. Writing a web framework is also cool, but it’s most likely to take a lot of time without providing the benefits and stability of existing frameworks. Evaluating whether an existing solution works is also a challenging task, by the way.
Certainly, there are things you won’t be able to work on in your company. You have two options. Either change your job or do interesting things at home (and then, possibly, reuse them at work). The computer-generated music is nothing related to my current job, but I did it. The RabbitMQ pooling on the other hand was a task in my current job.
Overall, if you are really interested in doing interesting stuff, rather than just “completing business goals and getting the paycheck”, then you should put some thought into what is interesting for you and how can you get to working on it.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.