How to Make Your Life as a Software Developer More Meaningful

March 09, 202213 min read

While the COVID-19 crisis has threatened the jobs of millions around the world, many of those who managed to keep theirs took the opportunity to pause amidst the chaos and think about the role “work” has in their lives. 

How useful is it to society? Is it important to the economy? And how does it contribute to their personal growth and well-being? At the end of the day, we all want to find a dream job that’s enjoyable and meaningful, right? But what does that actually mean?



What is a meaningful profession, anyway?

Having a meaningful job is something (almost) all of us are striving for but don’t always find easy to achieve. It certainly helps to be well-paid to generate motivation. But once you’re content with your salary, having more money will not help much. You would probably need something more to keep you moving forward... and with gusto, too.  (In fact, we have an entire article before about whether money should really be a dealbreaker when job hunting. You should check that out.)

Of course, learning how to properly write clean code, learning the fundamentals, and all that technical jazz is exciting and crucial for the first few years of your career. But what about later?

For many software engineers, we’re usually motivated by new technologies. But then many also become tired of them quite quickly, especially when most new technologies don’t bring anything valuable to the table. Have you heard of the Javascript Framework Fatigue? You see, embracing new tech, just for the sake of it, can often be due to a lack of maturity. As a software expert, you need to learn or hone skills that you can actually use. No matter how shiny and new a technology is, if it doesn’t help you find the solution you need then it’s basically useless to you.

What you need is to develop the right mindset and habits that will serve your professional life for the long haul. Below are a few pointers to give you some inspiration, and to tackle one of, if not the most pressing problem of the software developer life—the search for meaning.



Let's start with the projects

Every project is different so there are no hard and fast rules or list of priorities you can abide by. However, there are basic pointers on how you can tackle every project. Here are a few. 


1. Understand business needs

Understand what is valuable for every client. 

How do you do this? The right way, of course. Do some research on their business and their end-users and ask questions. Remember that software solutions are created to solve real-life problems based on real users' struggles, so make sure you understand the "Whys" behind them.

Also, understand user feedback properly. Don't take it personally. Instead, consider these... Why did the user request the change? Why is that change essential for the client? This mindset will allow you to come up with relevant feedback, based on your experience, from the many web applications you have already created. On top of that, it will also open up new horizons and let you gain more knowledge on markets or industries that you might not know yet.

Another thing that may help is to involve a business stakeholder in the feedback process. And when you do, emphasize the timeliness of their response and the clarity of their priorities. Avoid having middlemen who may have a poor or insufficient understanding of the business.


2. Manage your tasks properly

There is a certain pleasure to having a neat schedule and well-organized agenda. Managing tasks is not easy, but doing it properly establishes a flow in the creation process and a sense of predictability. It also removes some uncertainty and lowers your stress since you know what to expect.

Also, being able to see results, and have tangible progress, is the best way to keep your motivation up. Below are some of the things you need to get a handle on from the get-go. 


Priorities

One of the most challenging tasks in software development is determining the tasks to prioritize. At the same time, it's also the most critical task to ensure project consistency and help understand how modules and objectives are related to each other. If you simply receive a set of assignments to accomplish without understanding how they are related to the short- and long-term objectives, you will end up as a mere cog in the machine executing tasks blindly.

You should avoid this at all costs. Why? Because it will most likely create disparate or unconnected modules or components that, when put together, will fail to create a consistent whole.

There are two notable points you need to know about priorities:


  • Business value
    This is a simple consideration on what will bring the most value to the business, at the lowest cost. For example, when building an e-commerce website, having a list of products and a way to purchase the product, will bring high business value. In comparison, being able to display or write reviews, or being able to save delivery addresses in an account, or even simply having an attractive design are features that maybe be less significant.

    Surprisingly enough, when discussing with a stakeholder, it’s often very difficult to convince them that the reviews, their promotions or coupon system, or other secondary tasks, are not so important if they don’t have a working checkout. And the stakeholders often want everything, and everything is of high priority, which obviously doesn’t work. So one of your tasks is to negotiate and explain... a lot. 

    It is to be noted that a lot of projects fail because stakeholders don’t trust their engineers and just dictate priorities when they do not necessarily make sense. This is also proof that your job is meaningful.


  • Vertical slicing
    A very common mistake when organizing tasks is to work on modules that cannot be tested without their dependencies… and at the same time not working on those dependencies. For instance, having a frontend team and a backend team that work on unrelated modules. As a result, many modules are not integrated and tested together for consistency.

    Vertical slicing is about discovering sub-tasks that traverse all the architectural layers of an application such as those from the database to the front-facing application. For example, if the backend team works on the endpoint to retrieve and edit products, the frontend team should work on the products list or the product edition in tandem.

    It is also critical to gather feedback from the stakeholders, as they can quickly use the application from beginning to end. So they will have the opportunity to create their products and see them appear in the products list, without any intervention from the development team.


Bugs, tasks, and releases

Don’t delay fixing bugs. The longer you wait, the more difficult it will be to correct the bug.

Also, work only on one task at a time. Multi-tasking breeds distractions and slows down the whole process of creation. If your client has a tendency to have a lot of ideas, ask them to set up a list of priorities. If they can’t make up their minds, make the decisions for them.

Lastly, don’t delay releases. The ability to release fast is one of the most important metrics of performance in the software development industry. If you’re afraid of releasing, it’s probably because you have an underlying problem of quality, lack of automated tests, or you’ve lost touch with the complexity of your own code. If you want to avoid that last bit, read about how to manage your stress effectively below.


3. Make sure the output passes the ramp on the first try


We all hate redoing the same job twice. After all, you want to avoid technical debt. Rewriting software because it became unmaintainable is the worst thing that can happen to a project. If you catch yourself wanting to rewrite everything too many times it’s probably because you have a quality problem in the first place.

So make sure you answered the described stories properly and followed all the acceptance criteria. Don’t second guess. Step up and ask for clarification if necessary. Asking questions is the mark of someone who’s interested in their work and wants to do it right.


4. Keep it Simple, Stupid (KISS)


This has been repeated a thousand times throughout history but it’s still a valid point to seriously think about. Create simple solutions that are loosely coupled and open for change, using interfaces and layers of abstraction. Avoid using unnecessarily complex tools and libraries when something can be solved using a small and simple solution. There is a library for everything but that doesn’t mean you NEED a library for everything. A lot of very popular libraries—moment.js, among others—are also terrible in terms of performance, size, or security vulnerability. So think twice and be mindful about installing things. Make sure the ones you do are performing well and actually bringing value to the project.

Also, create a simple user interface and avoid cluttering it with unnecessary functionalities. Consistency, after all, is the mother of all good code.



And continue with yourself


Having the right attitude is essential with any job, more so if you’re working in a team. After all, maintaining good (if not excellent) team dynamics at work is equally important as the project output you'll deliver. And how do you ensure everything is copacetic when you're at work? Here are some pointers that could be of great help. 


1. Manage your stress


It's easy to feel overwhelmed, especially when working in an unorganized environment. For instance, if you work in a company that is full of bureaucracy that heavily relies on vertical communication and validation... or is constantly in rush mode. What you should do is manage stress, accomplishing one task at a time, such as... 

  • Have a to-do list, organize your priorities, and don't multitask. Move one problem to done before you jump to the next one. 

  • Learn to say NO to new tasks when you're already overwhelmed (see above section about priorities). Avoid building unrealistic expectations about your capacity to accomplish tasks. When setting up priorities the next day, add only the 3 most important tasks to your to-do list. We are not machines, after all (not yet, anyway :P).

  • Make your own life easier by creating small stories in smaller episodes, and storing them in small sprints. Everything must be "human" size to avoid cognitive overload. Split tasks and split teams. The ideal team size is about 6 people, if you're wondering about that.

  • Tackling "low-hanging fruits" sort of tasks first can help free up your day early on. But do them only if the processing requires 20 minutes or less of your time. Do these early in the morning before moving on to your main tasks.

  • Learn how to make your tools more efficient and how to avoid over-complexification (see the previous chapter on the KISS principle).

  • Lastly, avoid unnecessary meetings and learn how to keep them short and focused as much as possible. Avoid face-to-face communication as they create interruption and distraction, and opt for asynchronous communication such as emails and messaging apps. More about asynchronous communication here and here.

    Get rid of unnecessary notifications that are blinking on your phone and computer.


2. Be a good team member

Naturally, you won't always agree with your teammate's solution. But if it's not endangering the project such as adding technical debt or unnecessary complexity, then it's probably good enough, and you should give it a try.

The cost of creating unnecessary conflict is much higher than the benefit of always being right. Also, try to build rapport with your teammates. Enjoy some time with your teammates outside work, during which you can share some non-professional chit-chat and show some interest in their hobbies or families.

Being socially adept starts when you stop being selfish and egocentric and learn to think about others' feelings.


3. Be prepared

As with most things, it’s always good to have forethought and be ready for possibilities. So…

  • Have the proper tools for the job already installed to avoid idle time, such as for daily communications, ticket management,  access permissions, etc. It would also help if you were the same hardware-wise such as having the proper PC, headset, camera, and all.

  • Make sure your teammates have all the information they need, such as team roles, tools, preferred processes, proper specs/designs, timeline, etc. Also, don’t forget to provide info, such as client/business background in general (i.e., their struggles, reasons for creating this app, etc.)


4. Learn how to communicate effectively

Learn how to properly express your ideas in a straightforward manner. If you don't know where to start, Toastmasters clubs are typically focused on helping you develop your communication and leadership skills. Check out clubs in your area and try getting an invite to a few of their club meetings. Don't worry, they're quite a welcoming bunch.

Avoid beating around the bush and answer questions directly. People constantly changing topics can be pretty annoying to deal with. It’s almost impossible to get an answer without going back to previously asked questions or having to clarify everything over and over again.

Hone your writing skills, so it is easily understandable. Today, the bulk of communication (including your code) is via writing, especially now that we are all stuck at home. So knowing how to properly put something on paper is not just for your recipient's benefit but is also a sign that you fully understand what you're trying to say/convey. 

And if you can spare the time and money, invest in some English language classes, especially if English is not your native language or if you learned it by simply watching sitcoms and TV shows.



After all is said and done…


The ultimate question you should be asking yourself is not whether your profession as a software developer is meaningful or not... but whether you have rendered any significant contribution to the profession/industry. 

As with most things in this world, everything has a purpose, given the right time, place, and circumstances. The question should be whether you have made your profession count for something in the grand scheme of things. Have you created a solution to a real-world problem? Have you delivered a great application to a client that helped his business in a significant way? These are the right questions to ask… and having these is better than having the correct answers to the wrong ones. 

Eric Jeker

Eric Jeker

Software Architect

Eric Jeker

Software Architect

Eric has been working as a software engineer for more than 20 years. As a senior architect for Arcanys, he works closely with the developers to instill the habit of learning, clean coding, re-usability and testing with the goal of increasing the overall quality of the products delivered by the teams.

Need a better tech hire option?

Let’s connect