11

Working at my first job as a software developer and it seems every task comes with a deadline of this Friday. Mostly applying patch works or undoing previous features. I do have the technical skills, it is not like I cannot do it, but the pressure makes me feel overwhelmed. In particular, I have this tendency to take my own time on things, think it through wide and deep, understand it upwards from the lowest abstraction level visible to me and then do it.

Further, it seems a lot of the job has reduced to meetings, zoom calls, chasing people (members of other teams, or my own) for the necessary information, and going through stacks of old emails to figure out who said what, and preparing necessary justifications of why I did X the Y way etc. Working from home (thanks to Covid) does not help much either. It seems I am not really learning anything for sometime just by fixing endless bugs and applying patches.

Is this feeling normal, especially when I am starting my professional life? Or am I simply at the wrong place, or having wrong expectations from a workplace? Would love to hear from more senior professionals. I still love writing codes though, but not repetitive codes that fit into the same template, or trying to bug fix others' code that nobody understands.

1
8

I do have the technical skills, it is not like I cannot do it, but the pressure makes me feel overwhelmed. In particular, I have this tendency to take my own time on things, think it through wide and deep, understand it upwards from the lowest abstraction level visible to me and then do it.

It's not uncommon to feel this way - part of it is just getting used to the ways that working in industry is different to what you might have experienced in education (or wherever you learned your skills). Over time as you gain more experience you should find that you'll need less and less to do that sort of ground-up level of research on small tasks. "Taking your own time", is something that you need to balance with the business needs, you can't always have as long as you'd like to spend on something, but that's okay because with experience you should get faster.

Further, it seems a lot of the job has reduced to meetings, zoom calls, chasing people (members of other teams, or my own) for the necessary information, and going through stacks of old emails to figure out who said what, and preparing necessary justifications of why I did X the Y way etc.

It's not fun but it's part of working life. While the level might change from job to job this isn't going to go away.

It seems I am not really learning anything for sometime just by fixing endless bugs and applying patches.

It's not glamorous, it's not sexy, but it's still necessary and it's still a valuable opportunity to learn. "Learn from your mistakes" is almost cliche, and that's because it's true. What you're getting here by fixing bugs etc is the opportunity to learn from other people's mistakes, take that opportunity and take it on board well and when it's your turn to write something like that you (hopefully) won't be making the same mistakes.

It's also good practice - the more often you go through the process of identifying the cause of a bug and fixing it the better you'll get at it and the faster you'll be able to clear them. While it's not the same sort of "learning" as picking up new languages and technologies, it's arguably more important and valuable in the workplace and for your career. And when you aren't spending as long to do these things you have more available time to be put towards larger non-bug fixing tasks.

I still love writing codes though, but not repetitive codes that fit into the same template, or trying to bug fix others' code that nobody understands.

I've been doing software development professionally for nearly two decades - trying to bug fix others' code has been a non-trivial portion of every job I've had in that time. I'm not saying you have to love it, but you probably need to accept that it's unlikely to ever go away completely.

2
  • 5
    "It's not glamorous, it's not sexy, but it's still necessary" - i dare say that practice in debugging is THE core skill for developers. THe more you train it, the better.
    – TomTom
    Dec 14 '20 at 12:30
  • obligatory Dilbert Dec 14 '20 at 17:43
6

Welcome to the IT industry. It can be a hard place. But trust me, you can learn how to make the best out of it.

Working at my first job as a software developer and it seems every task comes with a deadline of this Friday. Mostly applying patch works or undoing previous features. I do have the technical skills, it is not like I cannot do it, but the pressure makes me feel overwhelmed.

Working on hard deadlines is common in software development. People are waiting for us to finish things. When we are late, then we cause problems all the way downstream to the end-users. Which is why we are expected to stick to schedules.

However, the only people who can realistically estimate how long we will actually need to finish something are we. Managers are really just guessing, especially when they don't have a developer background themselves. Which is why it is important to push back when we get unrealistic deadlines. When you don't believe that it will be possible to complete a task in the time the project managers decided it should take, tell them as early as possible, so they revise their schedule.

In particular, I have this tendency to take my own time on things, think it through wide and deep, understand it upwards from the lowest abstraction level visible to me and then do it.

The problem is, developer hours are expensive. Too expensive to spend them on understanding every single detail. Yes, in a perfect world, we would have a wide and deep understanding of the problem domain, so we can provide the absolutely perfect solution. But the perfect is the enemy of the good. It's far more important to find a good enough solution on time than a perfect solution which comes too late.

Further, it seems a lot of the job has reduced to meetings, zoom calls,

It's a common misconception that software developer is a job where you just sit in a dark office hacking code all day. It's actually a very communicative job. I like to compare our role to translators between humans and computers. The humans tell us what they want the computers to do, and we tell the computers. And when the humans don't understand why the computers do what they are doing, they ask us to translate for them. That means we need to spend just as much time talking to humans as we spend talking to computers (by programming).

However, sometimes there is a tendency of some people to overdo it with the communication aspect when it comes to scheduling meetings. Some managerial types like to err on the side of inviting rather too many than too few people. So you might sometimes find yourself in a meeting where you wonder what you are supposed to do there. When you feel that you get invited to meetings which are not a useful use of your time, feel free to push back and tell them. Remind them that developer hours are expensive, and the time you spend in their meeting is actually more expensive than just the meeting itself, because you also lose time for getting mentally back to what you were doing before.

But one positive thing about working from home during the pandemic is that when you are stuck in a meeting where you don't belong but can not get out of, is that nobody will notice when you actually work on something useful in another window.

chasing people (members of other teams, or my own) for the necessary information,

This usually gets better with time. You will figure out how to get which information quickly or know enough about what's going on so that you have the information yourself.

going through stacks of old emails to figure out who said what,

Try to improve your system for organizing information. Everyone has their own system for this. Some have elaborate filing schemes in their email clients. Some people use applications like One Note. Me? I just have a text file on my desktop where I write down notes about everything I am working on right now. You need to figure out a system which works for you.

preparing necessary justifications of why I did X the Y way etc.

Documentation is important. It might seem like annoying bureaucracy now, but in a couple years when someone need to figure out why someone did something the way they did it, then good documentation can be a real life-safer. Still, excessive documentation can cause more trouble than it's worth. And when quantity is valued higher than quality and you end up with a lot of documentation which isn't actually useful, then it can actually become harmful.

So when it comes to documentation, try to work smarter, not harder. Spend time on the documentation of what's actually relevant and only do the most necessary part of those things which are not. When you established a bit more clout in your organization, you might also try to actively influence the documentation habits in your organization by suggesting changes to your guidelines. Try to convince people to abandon unnecessary documentation and better organize documentation which is important.

However, recognizing which is which is also something that requires some experience. So that's something you might want to get involved in later.

It seems I am not really learning anything for sometime just by fixing endless bugs and applying patches.

I feel you. Everyone wants to develop new software. But supporting old software is also an important part of our work, even though it is a lot less fun. But don't think that you can't learn from it. By fixing buggy software with awful spaghetti code architecture, you can learn a lot from other peoples mistakes. You will see a lot of ways how not to do things and what kinds of problems they will cause later. This can really help you to create less buggy and more maintainable software later when people trust you to develop some software of your own.

1
  • 3
    Small tweak to this (good) answer: "When you don't believe that it will be possible to complete a task in the time the project managers decided it should take, tell them as early as possible, so they revise their schedule" -> If you don't have experience in evaluating how much time is required for a task, start by making an estimation in your head, and then double it. Most programmers have a tendency to under-evaluate the tiime required for a given piece of code or feature.
    – m.raynal
    Dec 15 '20 at 13:56
2

Regrettably I have to inform you that the things that make you unmotivated/unhappy about your work will probably not get different or better.

Even senior developers spend a lot, or even most of their time writing bugfixes. In a lot of cases that mean you will be working on/in other people's code. Of course it differs from workplace to workplace, but I think most developers spend less than 50 percent of their working hours on developing shiny new things. And even if you are lucky enough to be able to work on a shiny new thing you probably have to work within an existing framework, existing architecture, existing code-standards. Although they may be outdated or less than ideal you still have to work with them and cannot just do it your way.

However over time you might also come to appreciate the challenges that come from working within an existing codebase.

1

What you have described is all part and parcel of being a software developer for the most part.

Unrealistic deadlines, pointless meetings, fixing other peoples crappy undocumented work, not enough time to do a decent job, feeling like you're rushed and have to justify yourself all the time etc...

Am I simply at the wrong place, or having wrong expectations from a workplace? Would love to hear from more senior professionals. I still love writing codes though, but not repetitive codes that fit into the same template, or trying to bug fix others' code that nobody understands.

I think it's possible you have an unrealistic view of the industry.

If you follow social media, that could be 1 issue. It's full of people glamourizing the industry to gain followers and sell content. Most of it's not a true representation of the industry. I speak regularly to juniors in a private chat group and many of them are disappointed on entering the industry because it's not as it was advertised to them.

A lot of the time it's repetitive work, and not every company has fun and exciting clients / projects to work on.

In my experience, most juniors find development overwhelming to start with, but over time and with experience, you will get used to handling all these situations. You may enjoy it, or you may not. With more experience you will likely get assigned large projects too, but there's no guarantee they will be fun or interesting.

Is It Normal for Early Career Developers to Feel Demotivated?

For most people, regardless of level, a job is just a way to make money so we can afford shelter, food and material goods. You don't have to be overly motivated or passionate about your job, and the sad reality is most people aren't. Only the lucky ones are (or those pretending on social media).

Am I simply at the wrong place

Possibly, only a judgement call you can make. Do you work for an agency (software house) or in-house? I think of agencies as sweat shops for developers. They're a great learning experience, but their focus will always be on speed, and with that comes erratic management, tight deadlines and lots of bugs. It can be very stressful.

Working in-house is usually a bit more relaxed, with better management and more time to document and build things correctly, as the company is more likely to care about the product being successful.

0

It really depends on alot of factors.

In some companies/times you are working on short-term tasks, where the dead-lines might be tightly-nit. At other times, you might be working on a big release, where you have more freedom to manage your own time.

The current industry is very prone to the concept of agile development (whatever that means). The implementation of the concept differs from team to team, but it will usually result in the project being split into smaller junks of work, which are implemented in sprints of something between 1 and 4 weeks. Usually the individual tasks of these sprints would be measured at around a few hours to a few days of work.

As restricting as it might be, it currently is one of the approaches to get a hold of the complexity of a big project while still staying on a planable schedule.

So my guess is that these small tasks might be what your deadlines are. If that is the case, then you should not feel too restricted by them. It is an estimation for planning the entire sprint rather than a hard deadline for your task. If you take longer, then you (or better: the team) should learn from it and estimate better the next time.

It is hard to tell from a distance, but it could also be that you are simply getting shorter, individual tasks, because you are a beginner and your manager/team leader feels that you need stricter guidance in terms of time management. So by proving your own merits you should quickly be able to shed these restrictions.

1
  • "It is an estimation for planning the entire sprint rather than a hard deadline for your task. If you take longer, then you (or better: the team) should learn from it and estimate better the next time." This also should be taken for the second part. As a beginner OP should not invest too much ("too much" as it's hard to do 9-5 at home) of his own time. So being honest about time really needed to do tasks should be passed to others. Dec 14 '20 at 9:32
0

Is this feeling normal, especially when I am starting my professional life? Or am I simply at the wrong place, or having wrong expectations from a workplace?

In a workplace, there will always be a need to make technical changes so that the business can continue to operate and survive. Writing code that you love because it is interesting and you understand it completely is a relative luxury that even senior developers don't always have.

It does vary from place to place. It's responsible for a company to invest in things like having dedicated sysadmins, and cleaning up technical debt, just so it doesn't drown under this operational burden.

It's hard to say whether the place you're currently at is below or above average in this regard. Perhaps a little below average, because patching systems is usually sysadmin work (but perhaps you are in a small company that doesn't have dedicated sysadmins), and following up paper trails, while it does happen, isn't very common (but perhaps you are in a highly regulated industry).

Useless meetings and chasing people up are universals though, best just get used to them.

Regardless, the idea that the life of a software developer is one that involves a lot of freedom to create beautiful solutions to abstract problems is a myth. The harsh reality is that stuff needs to get done.

-3

It happens, but it is not really ideal or even standard to work like that as a junior, at least to my experience.

Employing a junior requires considerable effort from other people in the team. They would need to give you:

  • proper tasks,
  • clear directions,
  • room to grow,
  • constant feedback, so you wouldn't feel lost.

Including juniors to every meeting and throwing unsatisfactory bug fixes to them with short deadlines is not a good way to grow a junior.

I would ask the following questions to myself:

  • How long it has been like this?
  • How do others work in the team? Do they get proper stories, or is all your team in a maintenance phase at the moment?
  • Is there any other junior that you can compare?

Before thinking about changing your job, you can try to raise the issue with your manager. Just try to be very clear and reasonable, otherwise you might come across as a complainer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .