What does a coding job actually look like

I do 90% maintenance and 10% development, is that normal?

You are facing several problems here ... let's start with the obvious ...

Is that normal?

No way. But ... is it common? Unfortunately yes.

Regarding bug fixing frustration

While that doesn't excuse the rest of the mess to deal with and the many projects they overload you with, I just want to point out that the "troubleshooting" approach just for you, the developer, can be frustrating be a perfectly reasonable approach for the company and its management.

Surface for more errors and costs

The more code you touch, the more likely you are to introduce bugs, even if you intend to improve them. That means longer development time, testing time and costs. And when it comes to a service version with a medium to high defect, that's a big mess for them.

Noise / fog in your logs

From an SCM point of view, it also makes sense to work directly in the branch of a service release in order to have a clear overview of changes in connection with troubleshooting. When there are 15 commits with thousands of changes surrounding a bug fix that might require a change to the 1 line code, this is a bit of a pain.

As a new hire, it makes even more sense to ask you not to redesign and / or improve the software, and in my mind it's okay to be as "surgical" as possible with your bug fixes. It just keeps headaches at bay.

Can you do something about it?

Now, this does NOT mean that there would be ways to achieve both the common sense of the Code and the common sense of the people involved. As a junior, you should have someone review your changes, especially bug fixes, and make sure they are approved before going on to the service release builds. That would prevent or limit radical change and be safer.

The project from hell

Crap code, herd of programmers, duplication, crap architecture

Again, Devil's Advocate is here but just showing that your original request had some inconsistent bits in it.

My point is this: I really really have really seldom adopted a code base that was not in this state. And on the opportunity I've had, there has recently been a project or prototype started that has been started by quite awesome programmers. But the amazing majority of them looked like crap, and a frightening number of them were real crap. Even those started by good or great programmers can be crap, deadlines, and other commitments that help ...

Welcome to real industrial software engineering!

And do you know what is fun? In the world of web development, things are often much worse. Have fun! :) :)

Too many projects and inquiries, not enough hands and time

The problem here probably lies in:

  • Your management (perhaps subconsciously) is abusing you,
  • Your colleagues (perhaps subconsciously) abuse you,
  • you (maybe unknowingly) don't cover your ass and fight your battles enough.

Your managers should be aware that you are working on too many projects to manage. If not, make sure they are there asap. Also, make sure they know that it wasn't just a pick nick in the park and that you felt pressured and that it needs to stop.

Take a look around and make sure that your coworkers are no longer distracting tasks and projects directly (by really saying "X can take care of it") or indirectly ("I'm not the right person for you") to distract you find someone else "-> ends with that you are).

Personal anecdote here: I did an internship a few years ago, and it wasn't until my very last day, when I got my rating, that my boss told me, although he was very satisfied with my work overall, that one of the managers felt that I had dumped some "not so fun tasks" on another intern than they expected me to pick them up. I was ashamedthat I felt disappointed and at the idea that I would look like I was slacking off as my intention was just the opposite: I tried to snap up more tasks and let the other younger interns deal with less hair-raising problems. Little did I realize that if I had been in his position I would have gotten bored of the lack of challenge and probably felt the way he did. The point is, you need to communicate to make sure no one makes wrong assumptions about three very different things:

  • what you can do,
  • what you wanna do,
  • and what you are ready to do.

In part, it's your fault that it turns out to be so. But it's normal, it's a lesson everyone needs to learn. It contains two letters: N - O .

Usually you use it as a prefix to a longer, but not that overly charged answer: No, I can't. No, I don't know how to do this. No, I am not sure if I am the right person for this. No, I've never done that before.

At first it's very easy to feel like you can just say, "Yes, I'll do it (sometime)" and stack things up and get things done, maybe by investing a few extra hours. It's all wrong. You need to understand that according to your abilities, your time is your most valuable asset to you and your company. When she is abused does this affect projects, deadlines, and budgets. As simple as that.

It also looks a little worrying that you have too many people to report back to. It's okay to have multiple clients and multiple project owners or even key players to communicate with. Overall, however, most of the time, especially if you are a new hire, you should only report to a few managers (and most likely only your direct manager and possibly a senior or senior developer). How did it come about? I dont know. This could be an organizational problem in your company, or it could be the result of doing a favor and then being contacted directly instead of saying "no". Or, as far as I know, your direct manager may be having issues with shipping tasks (I'm really guessing, but the pattern is recognizable and familiar).

I would recommend that you do the following fairly quickly: speak to your direct manager personally, explain that other managers may be a little pushy, or (probably less tearful) that too many things are piling up from too many people, and that you are need his input (and possibly yours) to know which to prioritize.

180 degree change requests

This is another big problem. They are probably not your fault, but you can try to help them address them.

"180 degree change requests", as you beautifully and precisely call them, are included from the start clear sign that the requirements are blurred and no one tries to chisel them and clear time.

That's usually when someone has to make a phone call (or rather on their feet) and grab the stakeholders by the hand and tell them clearly: "That's where we are, that's where you want us to go." Do you confirm that we are going in the right direction? It's okay not to get clear answers at the beginning, but the more time goes on, the clearer they should become, or this project is a disaster waiting to happen.

Normally I would say that you have all the stakeholders within reach, put them in one room, guide them through litigation, and gradually try to resolve them - and prioritize while you are at it. In your case, however, that might not be your call yet. But you mention that they really put you in charge of the projects. If that's really the case, then take responsibility and do that. And don't be shy to say in front of it "we can't do that" or even "we do not do that". It's really important to limit the scope of a project.

If there is no scope, there are no clear requirements at the end of the discussion.

Email overload

People tend to behave differently depending on the communication medium used. Personally, while I'm a rather softly spoken person (and have worked mainly overseas so I don't end up like talking on the phone too much either) I would prefer it in order of preference based on productivity:

  • speaks to people face to face,
  • talk to people on the phone
  • talk to people about IM,
  • talk to people via email.

Email is good for tracking, getting confirmations, and sending notes.

They are almost useless for planning, planning and discussing problematic points. Knock on the man's door until he / she opens it and sits down with a notepad and a copy of your documentation to clear things up. When you're done, send an email asking for confirmation. If it comes back with a negative answer or a slightly hidden attempt to sneak something else into the envelope, besiege the interlocutor's office again.

This is software engineering. Not typing on a keyboard is often more productive and can cut down on the crap to deal with upfront.

Worth the work of a team

Are you doing the equivalent of working a team? Maybe.

Are you doing the equivalent of your team's work? Probably not.

What I mean is that your team is probably busy and you are overworked. And that's the problem: you're overloaded with things that should be pushed out of current project schedules or made available to someone with time.

Was I an idiot when I initially expected things to be different?

No; just new to the party. It's like a first hangover or a relationship. You will get over it.

I think this post turned out to be a big joke, but please tell me this is not the same for every developer.

This applies to any developer in chaotic organizations, be it startups or established giants, and with no experience or confidence to get things moving a little and improve your chances of survival on the right side of the scale.

P.S. My salary is almost the same, if not lower, than a cashier in a supermarket.

I've made decent salaries for jobs that would seem crappy. It's not the number on the check that matters, it's the context. What you do, your age, where you live and work, etc ...

That being said, if you are severely underpaid, work too much and are not entirely younger, ask about that raise or get a new job!

It's easy:

  • if they value what you do, they will happily agree to an increase.
  • if it doesn't, the future doesn't look very bright for this company (at least for you, what matters). So don't feel bad about leaving.

Know that asking for an increase is a good thing iseven if you might not be inclined to think so at first. It shows that you are on top of what you are doing and it indicates that you are keeping an eye on other options while remaining ready to stay on board. And it's a good thing to get used to requesting them as they're like interviews or negotiations in general: it's something that takes practice and they won't fall from the sky if you don't reach for them yourself. Some companies regularly hand out raises without asking, but that's just because they're smart enough to know that you're half happy, less willing to change, and that they are cutting the grass under your foot want (most people would feel a little uneasy about increasing an increase offer that was offered to them directly).

The process of approaching this request is a little outside the scope of THIS project here, so I will not go into the details. However, I would recommend that you keep a record of your SCM Commit IDs, bugs fixed, and achievements, and generate reports comparing them to the team's overall effort. This way:

  • You can measure yourself whether you have effectively done a lot more than your colleagues or not,
  • You can assert yourself when they say your request is not justified.