Feeling a sense of job satisfaction is incredibly important, especially for developers: If you’re happy, you’re more motivated at work, and at a lower risk of burning out. Even though a salary might contribute to your happiness, it doesn’t always help you push through grindwork, or through solving hard problems. In this article, I’ll take you through some questions that helped me evaluate my job satisfaction, and some tips I used to answer them.
The value we get from our jobs is not only about the salary we are paid; it’s about the satisfaction we feel in being part of something larger than ourselves - and any individual will value different aspects of being a developer. For some, it’s writing super clean code, while for others it’s building something that is useful to the world, or being part of a diverse team that just works like a well-oiled machine.
Recently, I embarked on the journey of evaluating my job satisfaction. I decided that I had to take a hard look at my current position: Although I was content, I had grown a lot. For any outsider, it would have looked like a great gig, but as time went by I started to realise that I was not as happy as I once was - but not because anything ‘big’ had changed about my job.
Instead, what was getting me down were the smaller things: colleagues moving jobs, projects ending, how the team dynamics felt, and other day-to-day events. These happen at any job, but it’s when I noticed that they were affecting my moods that I had to stop and question whether I was still on the path to fulfill my goals.
I will detail the process of evaluating my job satisfaction below, but what it helped me do was realise something really important: That I was the master of my own happiness.
By following a process of asking myself a set of questions, I had a structured way to think about my happiness as a developer. Having that structured evaluation meant I could - with confidence - say whether I was happy or not.
How to evaluate your job satisfaction effectively
I went about evaluating my career satisfaction as I do any software project: Asking the right questions, and laying out a plan.
I believe a successful software project is not devoid of any problems or struggle, but is successful despite having things like scope creep, or any other derailing factors, for example. This is the same for your job satisfaction.
My exercise can be summed up into the three core concepts of this article:
- Discover what makes you happy (set the requirements)
- Make notes of what makes you happy and what makes you unhappy, anxious or frustrated.
- Check your silos and your environment (manage your resources)
- Take the time to walk the fine line between being ‘selfish’ and being part of a team.
- Speak to colleagues and research aspects of your job that you found made you happy.
- Set achievable goals to fulfill the requirements with your available resources.
- Revisit your requirements and align your goals to your team’s.
- Make them actionable, and actively pursue them.
#1: “What things excite me on a day-to-day basis?”
Finding what makes you excited to come to work can be one of the most difficult things to do, especially while you are currently still at your specific job. Deadlines and responsibilities can take up a lot of a software developer’s time and effort, and leave us with very little energy for ourselves. If you can relate to that feeling, you should pause and check in with yourself.
This is a hard question to advise on with answering, though, because only you can really decide what you are excited about or not, but some areas you could focus on include:
- What do you enjoy about your current team?
- What would you change on your current team, and why?
- Do you feel as challenged by the software problems you’re given as you want to be?
- What makes you look forward to going to work?
When trying to answer this question for myself, I wanted to know from my colleagues what made them happy at their job. Some mentioned that they were most happy when they were given clear leadership that supports and nurtures the team. For others, it was about having great mentors to learn from, and the space to upskill. It was interesting that not one of them listed a job perk, money, or job titles.
Any intentional focus on your current situation and its impact on your happiness will lead to a better understanding of those things, and how to improve them. It seems so simple, but we neglect it so easily in an industry like tech, where we are constantly needing to move harder and move faster.
Two hacks that helped me with this question were:
- Set an intentional reminder: What helped me was to set an alarm for a random time of my day, and when it went off I would stop for 2 minutes and ask myself these questions: What happened today that made me feel satisfied with what I am busy with? What am I looking forward to in the rest of the remaining work day?
- Make detailed notes using Google’s Keep app: Taking notes well - and remembering to take notes regularly - is really important to make this discovery process effective. Every day, I would make detailed notes on Keep. By working through them, I realised that some notes weren’t things that made me happy, which helped me feel like I was on the journey to discover.
A few ‘wrong turns’ were not necessarily a bad thing, and at the end of a few weeks, I had a clearer picture of what made me happy at my job.
#2: “Where are my biggest silos right now?”
When you have your notes on what makes you happy, it’s good to start taking stock of your current work environment by focusing on where you feel there are ‘gaps’ and figuring out how to close them. You should also consider the eventuality that you might have outgrown your current situation with experience, and should be moving to a new job.
I started answering this question by doing a few of the following things:
- Research and read up on career advice: I wanted to see whether I was following the advice that’s out there, and looked into how to navigate the work environment. I focused on looking at the ‘softer’ things, like working well with bosses, colleagues, and stress.
- Speak to people about how they stayed happy at work: This included friends, family, colleagues and supervisors. I wanted to see what things they focused on when it came to being happier at work.
- Actually start planning on how to improve my job satisfaction: With all the notes I had made, I formed my plan into something I could use to explain what I wanted from my job to someone in a clear and concise manner - something close to an elevator pitch.
I used the information I got from the above and made a kind of pros and cons list. I also wrote a list of my “happiness snags” - places where my needs were not met - and investigated what had to change in my current position to fulfill each one.
Once I had that, I prioritised the things from most important for my happiness, to least, and used that to decide which things were my ‘pillars’ - the non-negotiable things I needed to actively pursue.
This process helped me separate what I’m told should make me happy, where those silos currently are, and what I actually want from my job.
Companies spend a lot of money trying to figure out how to make their teams satisfied. Often, in this process, they unintentionally create a lot of stigma about what should make you happy: Perks, job titles and pay grade do form part of the environment, but don’t necessarily cover everything that makes someone happy.
#3: “What goals have I set, and what goals have others set for me?”
When developing software, goals get set for us quite often - some in the formal sense, like key performance indicators and deadlines, and sometimes more informal, and closer to a ‘want’ rather than a ‘need’, like learning a new framework or language.
As I set out to find a place where I am happy, I realised that teams shape each other using goal-setting, and to be happy I had to understand what goals were set for me and what goals I set for myself.
After being able to identify these goals, it was easier to pursue real joy at my job because I could see whether I was actually setting any of my own goals at all. It’s important to have a good balance of ‘give and take’ in any relationship, and goal setting with your team is no different, otherwise someone is likely to become unhappy.
For everyone to be happy, it should always be a two-way street: If I can help my team get closer to their goals, I can get help from them to get closer to mine.
I hacked my goal setting by writing them down in my notebook. Everytime I open and look for some other notes, I stumble across the goals I have set, and pause for a minute to check if I am still confident that I’m on my way to achieve them. Some people use the same method in other forms with sticky notes.
What’s important, though, is to remind yourself regularly and adjust when you feel the goals don’t resonate with you anymore. Motivation is something we all seek from time to time, so check in with a mentor, friend or colleague that you trust and share your ups and downs with them.
Our careers are our projects
Although the process sounds simple, it gave me the courage to make hard decisions. Even though I’ve often felt like it’s my company’s responsibility to keep me happy at work, I’ve learned that it’s me who has just as much responsibility for my own happiness, and I should be putting it first.
We change, as do our jobs. Things like perks and environments are catalysts that help shape and highlight the company/team culture, but if the experience is not great, developer productivity and happiness will drop and potentially break a business.
Our careers are our projects. We are responsible for our own satisfaction and happiness at our jobs, more so than anyone else’s. When we do better our teams do better, and when our teams do better we are more satisfied.
Allow for the not-so-great-times, focus on the reasons why you first became a developer, and know there will be times that you are not happy - and that’s OK.
“On the other hand, there’s only one way to justify work that’s better than it needs to be: Because you cared enough.” - Seth Godin
Frikan Erwee is a front-end and mobile developer by trade, and currently works at OpenVantage. He studied Geoinformatics at the University of Pretoria, and Computer Science at the University of South Africa. In his spare time, he contributes to Google mentor programmes for students and school learners, and advocates for open source software. He is a firm believer that the digital divide will only become smaller if young developers are not held back by ‘gatekeepers’ and their proprietary software.