How do people work the same job for several years? I am 7 months into my 2nd job and already bored

Question

I am a dev who hopped from one job to another 7 months ago. I quit the other one after 6 months for similar reasons. And yet I am bored again.

A lot of it is the crap, I partially wrote this during my Friday sprint retrospective, which was a pointless whineathon. 45 minutes into it, I ran out of reddit to browse, emails to respond to, and online surveys to do for Air Miles.

Between review, retrospective, and planning, I logged 6 hours on my phone. Drained a full battery to 30%.

The actual work is more interesting, but it is still often repetitive.

Is this just how work is?

Answer 1

Well, you get paid, right? At some point you must realize that:

• A job is there to get paid.
• Some parts of ANY job are not exciting. Even the most exciting jobs will spend a lot of time doing boring stuff.
• Most people do not have a career but work in a profession, get possibly a little up and THAT IS IT. You will not become the CEO of a top 500 company, most likely, because at any time there are only 500 of those.
• It is how you handle it, not how the job is.

Obviously your job is grudge - no idea how a sprint retrospective can even take more than 45 minutes. We do those in 4-15 unless something really awkward comes up and requires action.

But your expectations should not be "oh, I need excitement all the time". NO job will handle that. Unless you fix that attitude, you better start looking for work outside IT - because you are going to ruin your CV with another couple of job hops. Now things are not bad, but you need to find a job you can handle for more than half a year.

Answer 2

You wrote that this is your second job as a developer and that you have been working in both jobs combined for around 13 months. I assume you still have a junior developer like role.

When you are bored by the tasks a junior developer does then I would argue that this is actually a good sign because it means that you are ready to step up. And you might want to talk to your manager that you want to work on more complex stuff or want to have more responsibilities.

To prove that you are ready you should start acting like a mid-level or senior developer. IMHO that most important aspect is: Instead of wasting your and your company's time, pick up things you are interested in and that are valuable for your company without waiting for someone to tell you to do that kind of stuff.

Some examples:

• Improve the stability of your applications or update its dependencies
• Investigate bottlenecks and optimized database queries
• Look into new technologies and evaluate if they are useful for your company
• Help others or train others to reach their sprint goals
• Prepare talks and represent your company at conferences

and so on.

Show initiative because when you only close tasks that you got from other people without being pro-active you will never reach more senior positions and that means you will never be able to really in control of your working environment.

Answer 3

I know a lot of developers who think that meetings are not work. I may have thought so myself long ago. Escaping into your phone (or doodling, or daydreaming) may all seem like better things to do than listen to people whining about something.

But here's a cool trick: if you truly engage in these meetings (including helping to make them shorter when that's appropriate) you will be less bored, enjoy your job more, and probably get promoted faster too. If you really had 6 hours of meetings in a single day in which absolutely nothing was accomplished, then there's a golden opportunity waiting for you to take!

Consider a retrospective after a sprint where something went wrong and people are blaming others for that and whining. "I never got the G124 form, and no Steve a text at 11 pm begging me to do a reset is not a G124 form" kind of thing. Here you have a chance to ask some great questions, or make some great suggestions, that could really change things at your company. Why is that form needed? Why don't some people do that form? Why do some people try to bypass process? What can you do to make process work better for the whole team? How does the problem you're having this month relate to the problem you had last month? This whole thing is a puzzle with a lot of moving pieces. Can you solve it? Not to the "well Steve is a selfish jerk" level, but to figuring out what's really behind some of the binds your team finds itself in.

Sometimes you'll share your insights right in the meeting, other times you'll approach someone one-on-one afterwards. Sometimes you'll learn from the meeting why some things you dismissed as pointless paperwork are actually important, and start doing them, and make your coworkers happier. There are many ways you'll become a better developer by truly engaging in these meetings. And you'll be less bored as well.

Give it a try for a week or two! What do you have to lose?

Answer 4

You mention sprints and retrospectives, so I assume you're following some variety of Agile. The heart of Agile is the concept of continuous improvement, and a team empowered to enact it. If you're bored, then congratulations: you've found something that can be improved. Here's some ideas:

Streamline Meetings

A retrospective that takes 90-120min is way too long. Next time you have one, take a notebook, listen in carefully, and note down any time you feel like things are taking too long.

• Are people repeating each other's points? Perhaps you could all put your suggestions on notecards or post-its, so that they can be rapidly grouped and discussed as one, rather than rehashing the same things.
• Do people miss things, and have to have it repeated? Maybe it's as simple as a "no phones/laptops/distractions" policy so that people stay aware of what's already been said.
• Does the meeting go off on tangents? Perhaps the meeting needs a chair who will step in and keep things on track - or the person who is already supposed to be doing that is not very good at it. Maybe you could start (politely) pointing out when things go off-topic, rather than starting to look at your phone or whatever.
• Does the discussion go into unecessary detail, or focus on a niche that only involves a few of the people present? Maybe you could ask if there's anything the other people could contribute, and if not, suggest that those involved discuss it outside the meeting and report back at the next one if necessary.
• Are there people in the meeting who aren't needed? Everyone present should be part of the discussion, which means that they provide information, take part in discussions, and go away knowing something they didn't before. If they're only there to provide info, then they could present and then leave, or even just send a report for the attendees to look at. If they're only there so they're aware of the outcomes, then they can skip the meeting while someone present takes notes to send to them afterwards. Since you're already taking notes, you could volunteer for this role - it's often a great way to learn about how things work at a company, which is useful for a junior.

Fill Your Time

If you're completing all your tasks for the sprint and still spending a couple of hours per day on your phone, then clearly you don't have enough work to do. Meanwhile, you mentioned that other developers frequently don't complete their assignments, which implies an issue in your process.

• If the team as a whole is routinely not finishing the work they committed to for the sprint, are you taking on too much? Next time you're planning the sprint, you could point out how much unfinished work you usually have and ask whether you should scale down your ambitions for the next sprint so that it's actually achievable.
• When you run out of work, could you assist the other developers in finishing their tasks? Maybe the reason you keep taking on work and not finishing it is because there's the right amount of work, but it's unevenly distributed so that your tasks are smaller and easier to finish, while others are working on larger things that take longer. If you're a junior, then the others may be working on things that are more complex and more likely to keep you interested, and you'd be helping the team to succeed. Less unfinished work also means less things to discuss in retrospectives, which makes those meetings shorter.
• Could you assist your QA or testers by running through the UX scenarios or test scripts? Less time spent waiting for tests to finish means work is finished faster, and seeing those tests in detail is often a good way to learn more about your software's use cases and to spot possibilities for improvement that you would otherwise have missed.

Improve the Process

If you can't help directly, is there anything you could do to speed the process? It might be that the other developers are spending a lot of time waiting for things, or that there are things they're doing that could be faster. If you've got time to be on your phone, then you've got time to tackle some of these.

• Can you automate anything repetitive? Software development contains many tasks that are done the same every time - builds, tests, deployments, etc - and these can usually be automated. This means that developers are now free to focus on more varied and interesting work.
• Is there anything difficult or error-prone you could automate? An automated process means less chance for human error, which means less time wasted on mistakes and less to talk about in retrospectives.

Keep Things Tidy

There are usually some side jobs available with software.

• You could check the backlog for low-priority bugs that you can fix easily.
• There might be some simple changes that have been requested that weren't made a part of this sprint, like changing wording in the UI, styling changes, or small tweaks, that you could fit in to make use of any spare time.
• There may be documentation that needs writing or updating.

Level Up

If you've been through all the above, you may have found some things that could be done, but you can't do them yourself. Perhaps this is because you don't have the expertise, or because you're not familiar with the code involved.

• Is there a training course you could work through to gain a new skill?
• Could you spend some time reading through some code you haven't worked on before, in preparation for working in that area?
• Is there an area of the codebase known for being hard to work with? Perhaps you could look at it and do a little code review to see if you have any ideas for improvements to suggest.
• Could you shadow a more senior developer, or even try a little pair programming, to improve your skills and experience? Maybe you can't help with their task, but by observing, you might learn what you need to be able to help out with the next one.

If all else fails

As you go through all these points, you may find things that you can see, and want to do, but are prevented by management, company policy, the apathy of your colleagues, etc. This happens sometimes, but if it's quite common and you find that you're stuck in an unpleasant working situation because they won't let you fix it (rather than other, more reasonable causes) then it may be that you just landed in a bad company and you'd be better off seeking out somewhere better.

If you've been through the whole list and decided that actually, all these things are fine, your processes are perfect, the code is excellent, and there really is nothing more that can be improved... well, then please tell us where you work, and if they're hiring.

Answer 5

If meetings are bad for your motivation, either raise that problem with your manager or find a company that does less of them. Seriously, "a pile of meetings that lasted all day"? I've never been in meetings for more then two hours a day, my average is about 2 hours per week. So NO!, that's not "just how work is".

It's pointless to be forced into meetings were one hasn't anything meaningful to contribute. If you current employer does not realise this, then you should look for a company that does. Look for the smaller ones, they usually can't afford to waste time like the big ones. Raise that problem in the job interviews, working culture and such are legitimate things to talk about.

Answer 6

What would you prefer to be doing with this time, if not attending meetings? You said you're a developer. Is something stopping you from using this time to improve the codebases you work on?

I note that you said you were on your phone, not a laptop. If you have to be physically present in the meeting and you don't have a way to write code from the meeting room, can you use the time to devise future plans for what you can work on?

For example, if the retro is whiny because of technical problems ("our tests take 2 hours to run") then maybe you can spend the meeting time digging into what could add value there.

If it's whiny for organizational reasons, does that really prevent you from helping? ("We keep missing our deadlines because shared services keeps prioritizing Dana's team's work over ours, and by the time they merge our commits there's a huge merge conflict and we have to fix new bugs and go through it all again!") maybe you can devise a way to make changes that are merge-conflict-proof.

Maybe the meeting really is none of your business. (That would be odd, since you're getting paid to be there, but I've seen odder.) Even then, is there really no technical debt, design problem or underprioritized backlog item you can put your mind on while you're bored?

Answer 7

Sounds like you've been unlucky at finding a couple of crap jobs. All I can say is that they're not all like that.

While there is always going to be an element of boredom and drudgery in any job, there are many out there which will keep that to a minimum. The trick is finding them.

The best way is to get networking - meet other developers and find out about their workplaces. Then you can apply to those places when a job opens up, or you might even be asked to join them.

If you're applying somewhere you haven't already gotten an inside look, all them lots of questions in the interview until you're satisfied, or ask if you can talk to the team you're going to work with.

Answer 8

Is this just how work is?

Mostly, yes, because it's not your company or choice amongst other things.

Answer 9

If you think that the retro is an excuse to whine and there are too many meetings, you should make suggestions for how to improve things in retro or in other meetings. You may find that other people agree with you.

This happened to me recently, actually; we had a lot of meetings on Wednesdays and it made it hard to get other work done. I brought that up in retro. It turns out that several other people felt the same way, and we're now working on revamping the meeting schedule.

You obviously don't want to be obnoxious or combative about it, but in general, don't be afraid to speak up in cases like this - you may well get what you want. Be sure you bring up a concrete proposal for improvement, though - don't just say "everyone is constantly whining!" or "We just talk about nothing for hours!" or something like that.

Answer 10

Yes, that is the way work usually is. In tech (or any hierarchial environment) even more so, because junior devs exist mostly to do the boring stuff so the seniors don't have to do as much of it.

You really don't seem to understand, though, that most people work because they really like being able to do things like eat regularly, have a warm, safe place to sleep, and even take a hot shower whenever they want*.

You might reflect that instead of a job (and presumably a fairly well-paying one) that lets you deal with boredom by spending 6 hours on your phone, you could be doing things like picking fruit in the hot sun, scrubbing hotel toilets, or carrying bags of cement around a construction site, all of which I can assure you are far more boring than any tech job. People do these things so they can a) survive, and b) earn money to do interesting stuff when they're not working.

Now it does seem that you might be in a job culture that encourages boredom. Perhaps in your next job search (whether voluntary or not) you might ask more questions about the culture: how much time is spent in meetings, whether they subscribe to fad development methodologies, and so on.

*If you keep spending 6 hours (or even 2 hours) of your work day playing with your phone, you may get to experience the lack of these things for yourself :-)

Answer 11

I'm in almost 5 years and already jumped ship 3 times, I too can't imagine working in a same place for like 20+ years like one of my ex-coworker.

But one of my job has given me a little insight about what I might look forward when working, feedback and collaboration. One of my job was frankly really out of context 3 months in I'm the only programmer left, and all that stuff about project that I will work on together, nope not even a preliminary design or anything. Suddenly I'm on a support role with really minimal coding, which is totally different from what I'm promised with, but I stayed there longer than any other job that I have before, I helped users with their problem, made some small project / function to help them and getting feedback and seeing that they are useful for them really made my job feel fulfilling. Though due to management crisis , I had to move to a different job before it eats my insides.

Point is, maybe instead of just focusing on the boring aspect of the job, you can try do more in your spare time, or you can try look into what makes you feel a bit "alive" , if it still does not work, why not try doing freelance or consulting job, it will make sure you can reduce the boring part and get into the point of your craft with probably less overhead (though handling a client might be much more harder if you're not into it).

I'm still looking for the answer too like you, Best of luck for us.

Answer 12

Sr. Dev. here.

Quit whining and take initiative, the job CAN BE what you make it, ex.

1. You have to do a repetitive task, can you automate it? Is it hard to automate? Sounds like a learning opportunity to me.

2. You have bad code that is hard to work on, refactor it. Don't know how? Read a book on it.

3. You are in too many meetings > decline meetings you don't need to be in.

The list goes on, but the point is to be proactive in developing both yourself and the business (which needs new technologies much more than any of them care to admit), employer doesn't like it? Find a new one.

Back to my k8 cluster ;)

Answer 13

It's a tough break for OP - they should try a job that requires 12 hours worth of work for each 8hr shift! Not a critism, just a point that they need to hear - I'm sure if they look for other work, they will find that kind of a job right away and after a few years will then be remembering the "good ol' days when life was good and stress was low" :)