18

I work at ABC corporation and this is my first job. Over the past two years, I have completely redesigned ABC's corporation's DevOps system using programming language X in which I am proficient. The previous system was "spaghetti," costing the company hours in debugging efforts, etc. The new system follows ISO/IEC 9126 standards and has accelerated company development efforts.

Because of this, the company has deemed me the "best X developer" (which I find funny... because all I do is literally just write the simplest possible code whilst maintaining consistency. I also have a bit of a soft spot for unit testing and documentation) and have asked me to take over a high stakes project.

The high stakes project (let's call it System X) is written in programming language X and it's... bad. The project consists of a single God class consisting of >60 member functions. To top it off, each member function makes calls to other member functions and some functions are 100+ lines long.

It gets worse. System X synchronizes events between systems written in programming language Y, in which I am not proficient. Let's call this System Y. System Y is much more complex than System X, completely undocumented, and no one has time to "teach me" how it works.

A mistake in the System X/Y pair could cost ABC corporation significantly in the form of litigation.

The problem

ABC corporation is upset that I take long to fix client issues. ABC corporation assumes that I just "magically" know everything about System X/Y because I am proficient in programming language X, whilst neglecting the fact that System X is poorly written and the fact that I have never received training with regards to how System Y works.

I went in expecting to deal with legacy code... I think this is a fair expectation... what I didn't expect is to be expected to fix issues with legacy system X, which controls undocumented system Y, which can cost the company severely if I were to make a mistake, all with extremely minimal training.

I'm starting to really burn out because of this...

I have already communicated this to my manager and he more or less kind of has a "I don't have time... sorry" attitude. How can I communicate to my manager that this is actually quite serious?

I'm also seriously concerned about my long term career prospects if I were to make a serious mistake this early in my career.

4
  • 10
    the company has deemed me the "best X developer" (which I find funny... because all I do is literally just write the simplest possible code whilst maintaining consistency. I also have a bit of a soft spot for unit testing and documentation) That puts you ahead of a lot of the developers they will have worked with! :-) Feb 18 at 15:25
  • 7
    Your variable names are poorly chosen...
    – morbo
    Feb 19 at 7:46
  • 1
    Many teams I have worked with would have been much more productive if everyone in them would "write the simplest possible code whilst maintaining consistency" and "have a bit of a soft spot for unit testing and documentation" Feb 19 at 16:56
  • 2
    If you are lead on a project, it is your job to provide, explain and defend reasonable estimates of how long it will take. If you don't know language X, then the total time will simply be time to learn X + time to actually do project + error margin because estimating is harder when you don't even know the language. They may or may not like hearing this, but they are paying you to say it.
    – SquiddleXO
    Mar 25 at 18:27
40

Unfortunately, it's a case of "Welcome to the software industry!"

As a professor told me in college, "If engineers built buildings like programmers build software, civilization would collapse by Tuesday..."

There are 100s of such questions on this site, along the lines...

"I'm a new programmer with my first job. I'm shocked and amazed at the poor quality of software engineering / management / codebases. What to do?"

What to do:

  1. Never, ever, ever complain, ask, whine, bitch, question, query, or agitate. Say nothing other than "YES M'AM" (or Sir) and then ->

  2. Fix everything. Fix it to ISO/IEC 9126 standards!!!

  3. Make huge amounts of money.

  4. Make drastically more money every year.

  5. Thank God that there are so few competent programmers, and hence points 3 and 4.

--

Footnotes:

  1. You mention at length "how important" the software is. (In your particular situation it links or whatever and there's money involved.) Yawn. All software is incredibly critical. Wait until you're writing software to fly planes. Suck it up and accept it as the norm! This is your life. Every day will have exactly that much pressure. Every day. Enjoy!

  2. You mention "burnout". Could it be you are working more than 40.00 hours a week? If so, STOP THAT. STOP IT NOW!

  3. You mention "unrealistic time expectations". (A) every single thing, ever, in the universe, that any programmer as done, has taken longer than expected. (B) every single time any programmer has ever done anything, everyone involved has complained it has taken too long. It's like saying "wow, the sun rose today." Utterly ignore it, do your work, and when asked for a time estimate simply give your best guess.

Some specific language for this situation:

SystemX is a single God class of 60+ member functions. Each member function makes calls to other member functions. Some are 100+ lines long

Extremely simple, just send this in an email

"Hi Steve. I reviewed System-X. It is a God class with 63 [BE SPECIFIC] member functions, 138.2 loc average. It will take me 2 days to rewrite each one properly."

It's that easy.

Note: don't whine that you "don't know" language Y. You have to know all languages. Or learn them on the spot. It's all just algorithms and data structures - languages are less than nothing. See points 3 and 4 !

16
  • 3
    1. Agree 100%. The problem is that I am only person working on it. 2. 60-70 is the norm for me. Maybe it's time to cut back... 3. Fair enough. I like it.
    – James
    Feb 18 at 1:38
  • 12
    "The problem is that I am only person working on it" I really direct you to Footnote-3. The logic is unbeatable. REAL software - modern rock solid software which saves milllions due to slashing maintenance costs can only be done in the time it takes. The logic is irrefutable. Just do it at your own pace. What can possibly happen? They sack you? A kid like you will get a far better job with far more money that afternoon. Enjoy!
    – Fattie
    Feb 18 at 1:45
  • 27
    "the problem is that I am the only person working on it" oh jeez. You are new to this industry, aren't ya! Being the only one editing a given codebase is a godsend. Nobody screwing up what you're doing, nobody committing miles of uncommented code and complaining when you refuse to merge it, then falling behind and putting you behind because you had to do their part for them while also undoing all their mistakes...etc etc. Being in situations where you can be the only one editing a given codebase is a gift...cherish it. 99.9% of programmers out there are more hurt than help. Better off alone. Feb 18 at 4:20
  • 2
    And continuing: this sorta thing is a standard initiation for a newer programmer that actually has the potential to be that 0.1% that isn't the 99.9% that hurts more than helps. They can gripe...but they know you're the best they have, they're not gonna get rid of you. Worst case scenario is they hire "help" for you...which from your description seems like not a possibility. So just gotta power through the managerial inadequacies and get it done. Eventually the clout of being able to do that sort of thing will turn you into the goose laying golden eggs. Managers leave you be then, and $$$ Feb 18 at 5:03
  • 2
    Footnotes 1, 2, 3a and 3b are spot on. It took me probably a decade to realise them all. Don't take a decade @James. When you're given a task, be up-front about what it'll take to do it with a realistic, sustainable amount of effort, and then do it. When others moan that you didn't do it in an unrealistic manner, then recognize that moaning for what it is: moaning.
    – Player One
    Feb 18 at 10:27
8

Because of this, the company has deemed me the "best X developer" (which I find funny... because all I do is literally just write the simplest possible code whilst maintaining consistency. I also have a bit of a soft spot for unit testing and documentation) and have asked me to take over a high stakes project.

Keeping things as simple as they can be, consistent and in working order - why do you think that is evidence against you being good at this?

The high stakes project (let's call it System X) is written in programming language X and it's... bad. The project consists of a single God class consisting of >60 member functions. To top it off, each member function makes calls to other member functions and some functions are 100+ lines long.

Okay, but your boss probably doesn't understand any of what. What does it mean to a manager trying to run a company?

Your job isn't just to explain the technology. Since you're the only one on this project, your job is also to translate it to things management can work with.

It gets worse. System X synchronizes events between systems written in programming language Y, in which I am not proficient. Let's call this System Y. System Y is much more complex than System X, completely undocumented, and no one has time to "teach me" how it works.

Like this. You don't know how System Y works. Your boss wants you to fix it. So you need instruction in System Y. Now, nobody in your company has time or understands Y. But your boss wants it to work.

So this is where you talk to managers about things managers understand. "Boss, if you want this working, I need training Z, and you need to authorize the company to pay for it. Here's a link to the website for a firm that does these trainings."

4
  • That's the problem. System Y was built in the company. Without documentation. And no one has time to teach me how it works. I would teach myself considering it is written in language Y, but the codebase is 100,000 lines long and I only have a basic understanding of language Y.
    – James
    Feb 18 at 22:43
  • So unfortunately I can't just get trained about System Y following some external resource. I have to rely on people internal to the company to teach me.
    – James
    Feb 18 at 22:44
  • 9
    If no one in company "has time" to explain a critical component Y which is required for fixing X, then fixing X is not that important for the company. Hence, you are forced to take extra time to learn it yourself and the company must accept the additional risks and costs. Just explain to management that it is their choice and you will try to do your best whatever they decide. Feb 19 at 8:22
  • 1
    Yeah, the think is to explain it in terms of something management can actually act on. "If you want me to handle system Y, you need to authorize funds to train me in language Y. I will also need the following other resources..." It can be hard to explain to management "this is a difficult task". It may be easier to get them to understand that "this task is going to cost at least $XXX, do we really want it?"
    – ObscureOwl
    Feb 19 at 10:23
7

You need to communicate the seriousness of this to your manager.

Book a meeting with your manager, make it an hour long. Make sure he understands that what you want to say is important.

Before the meeting, go through the code you are maintaining and make a list of all the structural and coding problems. Be specific. Make a document that contains this list, and for each one write down why this issue is slowing down your bug fixing.

For example:

"Class HumungousController is a 'God Class', meaning it touches every part of the system. Any change to it is likely to break something else. This means any change I make to it has to be exhaustively tested and usually many other problems fixed before it can be shipped to clients.

As well as this, come up with a proposed refactoring/redesign that you would like to do to mitigate the problem. Make it something you can do in steps.

At your meeting walk your manager through the document. Make sure he comes away this this message:

The existing structure of the code is an impediment to my bug fixing. If we leave it like this then I will be fixing bugs at the speed I do now, which is very slowly. Alternatively the company can do the changes I recommend, which mean eventually we will be able to fix issues much faster, and be more responsive to customers. As a third option we can rewrite the system from scratch, making it more maintainable, and eventually replace the old system with the new one.

It's your manager's choice which one of those he chooses. But you will have given him the information he needs to make his choice, and the fact that you gave detailed, accurate information about the choices will sit well with you whichever he chooses.

3

ABC corporation is upset that I take long to fix client issues.

They are just going to have to live with it. It takes as long as it takes, especially if you need to test everything thoroughly before calling it "done".

How can I communicate to my manager that this is actually quite serious?

Your manager doesn't consider it serious enough to do anything about it. Work with that.

I'm also seriously concerned about my long term career prospects if I were to make a serious mistake this early in my career.

It won't be you who gets sued if everything goes wrong. It's the company's problem. Just go about your business as best you can. The worst case is that you have to move on to another employer.

2

Knowing the language gives you a head start on understanding the next product you work with that's written in that language.

With this in mind, it doesn't make you an expert on the next product. You'll still have to read the product (and understand it) to become an expert on it.

If your managers have difficulty understanding this, tell them that knowing (their language) doesn't give them any insight into the books they haven't read yet. But, after reading the books, they can start to imagine how the books could be better rewritten.

You must log in to answer this question.

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