69

I was hired by an investor to solely work on an angular/Firebase CRM/ERP system. The project was built by an unknown number of people before me and it took 7 years to develop the system from scratch.

When this investor offered me the job, I was tricked into thinking that I'd get some documentation about the structure of the system or at least some good guidelines from former developers on how to dig into the code, which never happened.

I had to learn the code through developing using patch solutions while getting complaints and being yelled at that I'm too slow. I studied the system in my free time in order to get a grip on the developing process.

Now that I have been working for him for an year, I learned maybe 65% of the code, yet some of the assignments are still hard for me because of the learning curve and take too much time, way behind deadlines, so the boss has to cut them. I tell him that I need time to learn the code but he thinks I should learn the code after work hours and that I'm not a good programmer. Sometimes the lack of knowledge about the code forces me to put patches, which I don't want to.

I feel that the conditions for me to develop in are bad. I love programming but honestly, I'm getting yelled all the time, I didn't get initial support, and salary is way too low, so I don't really want to spend my after work hours studying it.

Who's right, me or the investor who hired me? How should I handle my boss? Did he put me in an unfair position?

11 Answers11

159

I feel that the conditions for me to develop are bad, I love programming but honestly, I'm getting yelled all the time, I didn't get no initial support and salary is way too low, so I don't really want to spend my after work hours studying it.

Major RED FLAGS right there! This is a toxic environment and you need to get out ASAP. Get your resume/CV in order and start looking for a new position at a real company that treats their software developers like human beings.

For me the "getting yelled" part is over the top! That's unprofessional to say the least and abusive for sure.

jwh20
  • 8,723
  • 6
  • 21
  • 26
  • 9
    Jwh20 you totally right, I also think it's not normal to learn milion lines of code in one month and even in a year – מיכאל ברגינסקי Sep 16 '21 at 11:22
  • 11
    @מיכאלברגינסקי That is definitely unreasonable. Any good tech company knows that it will take a long time before you're fully productive, and even longer before you understand the full code base – Kevin Sep 16 '21 at 19:25
  • 31
    TBH some people use the phrase "getting yelled at" to mean any sort of disapproving feedback even when there is no actual 'yelling', but I don't disagree with the sentiment. If they don't appreciate your work, go elsewhere. – rtaft Sep 17 '21 at 13:48
  • 10
    @מיכאלברגינסקי in my company, we usually expect for an employee to get full-speed with the code in 8 to 12 months. One month is... not reasonable. At all. – T. Sar Sep 17 '21 at 16:56
  • 4
    @T.Sar Indeed. Most engineering jobs, whether it's software, hardware or mechanical, take 6 months minimum before someone is up-to-speed. More if they're junior. – Mast Sep 17 '21 at 19:55
  • getting yelled at for any reason is unacceptable imo in an office environment but in military its ok – Lightsout Sep 19 '21 at 00:12
  • +1 Get out! I did just this earlier in the year. Started a new job and found there was no docs, tests, anything. I didn't last 2 weeks there. Now I'm at a better job making more money. – Brady Dean Sep 19 '21 at 00:43
51

Sorry, I'm going to be a little rough at first.

I was tricked to think that I'll get some documentation about the structure of the system

Then you should really improve your interviewing skills. You can only be tricked if you let them. Learn how to ask the right questions.

Who's right, me or the investor who hired me?

Doesn't matter

What's your point of view on the situation?

Doesn't matter. Why would you think that the opinions of random strangers on the internet is useful?

Did he put me in an unfair possition?

Doesn't matter

I was put in a complicated situation

You put yourself in a complicated situation by accepting this offer without proper researching the job first.

How should I handle my boss?

That's the first ACTIONABLE question you have asked. Sorry for harping on you, but you need to get out of the mode of "bad things are happening to me, please have pity" and into "I'm in charge of my life and my career and it's MY responsibility to fix it".

Things to do:

  1. Start looking for another job right now. Fire up your network, polish your resume, start putting feelers out, get active on job boards, etc.
  2. Figure out what YOU did wrong during the interview process. You don't want another toxic job again, so analyze what you need to do to avoid this happening again. Example: if you want to know if the documentation is real or not, ask "What documentation system to you use" or "Can I see some doc examples, so I can assess how quick I can become effective in the role". Learn how to do research on roles and companies.
  3. Ignore your boss and yelling until you have an offer in hand. Since you are underpaid and critical they are unlikely to fire you.
  4. Refuse to do any in your spare time. The company has little leverage to force you to do anything.
Hilmar
  • 120,104
  • 36
  • 233
  • 374
  • You are right, I was blind, I wanted to take the job in all cost, but I thought I'll had my back covered. I posted this because I also wanted to know if it's possible to not be able to full stack a CRM after an year, like am I wrong professionally. – מיכאל ברגינסקי Sep 16 '21 at 15:13
  • 89
    “You can only be tricked if you let them” — how else would you describe being lied to in an interview?  And how would you protect against that? – gidds Sep 16 '21 at 17:00
  • 124
    Lumping the blame on the OP for not asking the right interview questions? Turn it up. No matter what questions you ask, you can get lied to, and they can rightfully refuse to show you documentation when you're not employed. Not every company has a glassdoor review, sometimes it's downright impossible to know what it's going to be like on the ground. Not sure what your problem is, but there is no issue with the OP giving us context to the question either, as some of it may be important. – Gregory Currie Sep 16 '21 at 17:04
  • 6
    Yes, you can get lied to. But in most cases you can ask good questions to figure out how honest and ethical an employer is. In 95%+ of all cases asking a follow up question about specifics and details will tell you if they know what they are talking about or just blowing hot air. Most candidates want to "please" the interviewer and are reluctant to ask more difficult or nuanced questions. That's a mistake. – Hilmar Sep 16 '21 at 17:29
  • 47
    @Hilmar Can I suggest finding a different way to talk about that than victim blaming? “You can only get tricked if you let them” doesn't even make sense to say—nobody lets themselves get tricked, it's part of being tricked. – doppelgreener Sep 17 '21 at 11:01
  • 4
    @doppelgreener can I suggest that the world-view that frames this answer as victim blaming while not untrue is perhaps less useful to the OP's future than the one that promotes personal agency? This answer is much harsher in tone than the one I would have written, but hits a lot of the same notes. Yes OP, you were right to sanity-check this, you're being taken advantage of and that's wrong, now get out there and think about how you're going to not make the same mistakes next time. – Jared Smith Sep 17 '21 at 11:19
  • 24
    @JaredSmith I'm suggesting Hilmar reframe how they promote personal agency. Currently the answer appears to be solely blaming the OP for their victimhood on account of an inadequate response, which is an unhelpful way to frame personal agency, and does little to describe what an adequate response would be. I'm requesting Hilmar focus on providing more detailed guidance on what the querent can do to protect themselves and without the unnecessary victim blaming. – doppelgreener Sep 17 '21 at 11:33
  • 1
    @doppelgreener ok, that's a harsher reading of this answer than I gave it, but I certainly don't disagree that it could stand to be more... diplomatic. – Jared Smith Sep 17 '21 at 12:55
  • 5
    Some good advice but is the tone really necessary? As you write yourself, who's right and whether that's fair doesn't and shouldn't matter but then you go out of your way to apportion blame. Why do you act as if your opinion as a random stranger on the internet is useful? – Relaxed Sep 17 '21 at 13:26
  • 1
    @gidds have you ever seen a legacy system with good internal documentation? :) I would focus on meet your peers and if there are none it’s a major warning sign for such a big task – eckes Sep 17 '21 at 17:27
  • 10
    "Doesn't matter. Why would you think that the opinions of random strangers on the internet is useful?".... They would be useful by considering different approaches on the conflict. Or we could just close the Workplace. – kauedg Sep 17 '21 at 17:27
  • 8
    "Why would you think that the opinions of random strangers on the internet is useful?" Ummm... if you think your opinion is useless then why do you keep offering it? – JeffC Sep 17 '21 at 21:05
  • 2
    @eckes Yes, I have seen some systems with good internal documentation!  — Admittedly, that was mostly because I wrote it… :-/ – gidds Sep 17 '21 at 21:53
  • I don't think this can be easily prevented in an interview. An extremely honest boss would say "here is the situation and here is what we need", a dishonest boss would paint the role as something a lot more glamorous than it actually is, and there is nothing you can ask to get them to break that. They do it for a living (maintaining that grandiose image for their boss) and they are very good at it. Even if technical people are in the interview, they can get leaned on by management to say nice things. By the way, I've never known an extremely honest boss. – jrh Sep 18 '21 at 19:58
  • 1
    None of the "rough" bits in this answer are useful or of any value, and they're insulting to the OP. Perhaps YOU had a bad day @Hilmar? – teego1967 Sep 19 '21 at 10:04
  • 1
    Keep in mind that once you lose credibility, the rest of your answer does as well. The first "rough" point that's not 100% correct indicates that your judgment may be suspect. I used to find it very hard to take advice or criticism from people that exaggerated or dramatized. Let's hope the OP doesn't have that issue. – piojo Sep 19 '21 at 14:36
  • 1
    “Why would you think that the opinions of random strangers on the internet is useful?”—because this is not Math.SE. Every answer on this SE is an opinion. Also, the members here aren't a random sample of the Internet users, there is Facebook for that. If your opinion is that you collected 72K points by giving the only possible correct and complete answer to every single question that you've answered, I don't share it. I also noticed that the correlation between one's points wealth and the quality of their answers changes sign from + to ‐ on SO at ≈10Kpts. WS.SE must have such a cusp, too. – kkm -still wary of SE promises Sep 19 '21 at 18:21
  • It's a shame the phrasing is non-uplifting as taking agency can be very uplifting. It shifts the perceived causes of negative outcomes from things that are outside your control to things that are within your control. Practically, many factors are still out of your control, you likely aren't personally responsible for most negative outcomes you receive. Yet, it helps you address your situation without shifting responsibility to others, and if persistently applied over time seems to produce better outcomes than treating every endeavor as doomed to fail by forces beyond you from the start. – Bruno Sep 25 '21 at 05:04
28

They have more of a problem than you do. They need you, badly. But they are making it look like you need them more, to keep you docile.

In reality, you have a huge disadvantage - you don't yet have experience and seasoned skill, in being direct, honest, assertive, and setting+holding boundaries. So they walk all over you, and then tell you its all your fault or your failure.

They take advantage of you, totally, then make you feel you have to thank them for spitting on you.

If you complain or say you'll leave, they are likely to play games to make you scared and submissive again. Blame, anger, guilt,threats. All the things they know will work. Will terrify and scare you back into "behaving" as they wish. Then spit on you and expect thanks for it, again. You need to learn to have and set and hold boundaries, to handle that.

That is the problem you have right now. This problem will follow you in your professional as well as private life, until you learn to handle it.

That question, how to do boundaries, is a totally different question. You should ask it as well, possibly on "interpersonal relationships stack exchange".

Ive been in your exact situation, and didnt know that. If I had known it, i wouldnt have known how to handle it. Experience takes time and, well..... experience... to get.

Stilez
  • 5,927
  • 1
  • 15
  • 25
12

When this investor offered me the job, I was tricked to think that I'll get some documentation about the structure of the system or at least some good guidelines from former developer on how to dig into the code, which never happened.

Ok.. it's not great that you were told you'd get some documentation etc that never materialized. However it's not exactly unusual to get negligible handover on something and have to figure it out.

so, i had to learn the code through developing using patch solutions while getting complaints and being yelled that I'm too slow. I studied the system in my free time in order to get a grip on the developing process.

Expecting you to spend your free time on it is out of order IMO, free time is yours not your employer's.

Now that I have been working for him for an year, I learned maybe 65% of the code, yet some of the assignments are still hard for me because of the learning curve and take too much time, way behind deadlines, so the boss has to cut them. I tell him that I need time to learn the code but he thinks I should learn the code after work hours and that I'm not a good programmer. Sometimes the lack of knowledge about the code forces me to put patches, which I don't want to.

As I said expecting you to work after hours to learn it is out of order, however it's been over a year, how long do you really want to ride that "learning curve" excuse? Three months sure, maybe six for a particularly large or complex code base but over a year? It's a CRM system not the space shuttle! So do I understand your boss being frustrated, I would be too, but that does not justify yelling at you, belittling you or demanding you give up your free time.

Who's right, me or the investor who hired me? What's your point of view on the situation? How should I handle my boss? Did he put me in an unfair possition?

He didn't put you in an unfair position initially and even if he's got a point that you are behind the learning curve he's handling the issue completely wrong and treating you unfairly.

From the sounds of it this job isn't paying particularly well so I'm not seeing many reasons to stay so I don't see much point in trying to reason with them, I'd just polish the old resume and find somewhere else, life's too short.

If for whatever reason you feel the need to stay (and I don't recommend it) then shift tack - you don't "need time to learn the codebase", your experience over the last year or more has taught you that things take longer than initially expected to do and whenever possible this should be taken into account when deadlines are being set.

motosubatsu
  • 107,822
  • 51
  • 290
  • 367
  • 1
    Well I'm trying to do my best, but the system is just too big and complicated, I'm learning it through implementation, so I can't give a good time estimation and there are things i can't do or get stuck at, I'm working on it all by myself – מיכאל ברגינסקי Sep 16 '21 at 11:32
  • 19
    Depending on the size of the codebase, a year could be 11 months too slow to understand it or 5 years too little. I've worked on codebases that are really only deeply understood by 1 person out of 100 devs. The others know their areas, but few people know how everything interconnects. Don't be too harsh on yourself, your boss is out of line. – Robin Clower Sep 16 '21 at 12:05
  • I disagree; It sounds like the author isn’t up for the task; it’s been a year, being “new” or “I am still learning the system” are no longer valid explanations for not getting the job done. We are only getting one side of the story. – Donald Sep 16 '21 at 13:03
  • 14
    @Donald It really depends on how big and complex the system is and what the new tasks are. I spent 7 years at my last company and the project was so big that there were significant areas of the codebase that I never actually saw. If I had to work on that without any help from developers with experience in the code, it would be very challenging to add significant features even a year later. As a contrast to that, in my current job I think I had touched every file in the system by the time I hit 3 months at the company. – 17 of 26 Sep 16 '21 at 14:16
  • Well, most of the problems are in client side, it's like a spider web of event emitters between hundreds of components and services, also need to follow hundreds of observables and recursive functions which has promises and observables within them, long code. I'm a b.sc in software engineering and I find this task very hard – מיכאל ברגינסקי Sep 16 '21 at 15:10
  • I'm really trying that hard and sometimes I just drowning in the codebase – מיכאל ברגינסקי Sep 16 '21 at 15:26
  • @מיכאלברגינסקי - My point was to highlight the possibility you are simply over your head. You indicated you have 5 years worth of experience previous to this position. You were likely mislead what skillsets would be required. After a year, you shouldn't be giving the excuse you still need to learn the codebase, you have way too many years to require that long to learn it. The time to have asked to improve your skillset was when you started but it's better to ask then be let go. – Donald Sep 16 '21 at 18:06
  • 1
    This is a custom codebase, but I should add that it's not uncommon for large CRM/ERP and such codebases developed and maintained by large corporations with a wide base of customers to be woefully lacking in technical documentation. This keeps the consultants in business. –  Sep 16 '21 at 18:20
  • One place I worked for 2 years at asked me how much I really understood of the codebase. After I gave them my answer, they said that if I had answered over 15% they would have thought I was lying, and that's because of the hundreds of client pages and the +250k lines of code, not because I'm a bad dev, stupid, or they disliked me. Learning curves last as long as they need to. Putting a false end date on them "because you should already know that" even though you haven't touched that area for maintenance or new functionality, is just plain unprofessional. – computercarguy Sep 16 '21 at 22:33
  • Complexity and organization is really more important than size. There are large systems that were developed with at least some overarching architecture where you might not be sure of the details of every part (or even know what some pages do!) but you can be pretty confident in making changes if someone points at the screen and says "I need this button to do x". Then there are systems that were written following every rule in the "How to Write Unmaintainable Code" style manual (actually exists, one copy is here: https://github.com/Droogans/unmaintainable-code . – user3067860 Sep 17 '21 at 01:58
  • @Donald I think the problem is we just don't have enough info to say whether A) the task is reasonable but OP is over their head; or B) the task is utterly unreasonable for anybody to do by themselves. There are many codebases that aren't reasonable for a single developer to maintain. The fact that the codebase was developed over 7 years to me hints at this being B not A. After 7 years of dev with multiple devs, in my experience, most codebases reach the "big ball of mud" stage: http://www.laputan.org/mud/ – bob Sep 17 '21 at 13:10
  • I think it's worth adding that a terribly designed codebase might take an infinite time to learn. I've worked on codebases like that, where everything is a multilayered circular nightmare that only ends up being more confusing the more you look at it. Mostly my response has been to draw a diagram of the main system call structures and use that to strongly suggest rewriting from scratch. Otherwise I'd leave. – Ben McIntyre Sep 18 '21 at 01:00
  • This is the best answer. It's true that poor hand-offs with ZERO help or documentation are very common. There certainly are strategies for dealing with that, but it's a very large topic by itself. The hostility is more concerning here for the OP, in my opinion. – teego1967 Sep 19 '21 at 10:09
8

There is a lot going on here.

Let's start with leaning code on your own.

No. Don't do this. Learning their code base does exactly zero for you and does everything for the company. What a good company would do is pay you to research the code AND build a documentation set for it. This company wants you to work on an undocumented system like a seasoned pro. That is never going to work.

Now let's talk about what you need to do.

Talk to your boss. Tell them that it is unreasonable for them to expect you to learn their system, especially when you were told that documentation exists. Point out that no one can manage code without documentation. That said, be ready to leave if this is a problem with them, they don't seem to have a firm grip on reality.

If you are unhappy with a job you should look at leaving. Ask yourself if the pain of staying is worth it. How are you paid versus the work you are doing? What are your chances of advancement? Is work available elsewhere?

If you have decided to leave, you can then talk with candor to your boss. "I'm not okay with being yelled at about things beyond my control (their bad code base)." "If you want me to learn the code you have to pay me to do it." These are reasonable requests, but in an unreasonable environment you may have to be ready to leave to make them.

Tiger Guy
  • 10,611
  • 22
  • 37
  • Looking at comments under other answers, the boss and investor are the same, so it seems as if the OP has already followed some of your advice. Telling the boss about not being ok with the yelling and working without pay is definitely something they should do, as well as looking for a new job. – computercarguy Sep 16 '21 at 22:36
  • "Point out that no one can manage code without documentation." ... trap here. Doing this is not impossible, but usually impractical to the point of being uneconomical. That difference still can be used against you. "No one can" arguments backfire very harshly if someone can. And "no one can" still can end up with them giving the job to no one, since no one can do it. – rackandboneman Sep 18 '21 at 17:45
5

The Manager is an Investor is Always a Red Flag

I've seen this problem several times, both in companies I've worked for and in many of our client's companies. Investors, in general, are the worst possible people to put in management positions:

  1. They often do not understand the job being done.
  2. They often do not not have experience managing others in a context where thier own performance is under review.
  3. They only get paid if the company is profitable.
  4. Unlike owners, they do not feel the personal connection to the company that comes with building something up out of thier own interests and passion.

A manager hired to do a job gets paid to do "management". This means writing schedules, allocating resources, maintaining a productive work environment, enforcing quality controls, managing both employee and client relationships, knowing what laws and regulations apply, and understanding the work well enough to make realistic predictions about the scope of work being done so that attainable goals can be set. These are the things that actually matter when you are a manager, and a normal manager who does these things gets paid whether the company reports a profit or a loss any given payroll. Getting paid either way keeps a manager focused on doing HIS job right which is good for both the long term wellness of the company and the staff.

Investors on the other hand have thier paychecks tied up in the the profit/lose of a company. Getting yelled at by Manager Investors is almost inevitable because every setback costs them thier money, and money is the whole reason they are there. If you say something should take about 200 hours, and it takes 250 hours, he does not see that as "about right", but as 50 hours of labor you you stole from his bank account. Even if the project was still profitable, this can feel like a lose to an investor if his profits do not meet his projections. If you put yourself in his shoes, it's like if I told you I will pay you 2000$ for something, but then only give you 1000$ for. Following up by saying, "Well you still made a profit" will not make you feel less cheated.

The problem, is that Manager Investors get emotionally invested in the profits instead of the work. This makes investors very unstable people to put into positions of power in the company because it makes them reactionary. They feel the pinch of every missed dead-line, every sale that falls through, and every minor setback. It makes them very quick to implement experimental policies, or drop successful policies on a dime to because they panic about the 1 time something did not go well. It makes them the people most likely fire thier senior staff because they are "over-paid" without understanding that they have irreplaceable skills. It makes them the most likely ones to institute illegal business practices (like asking hourly workers to do unpaid work). It makes them the ones most likely to push for windfalls over the long-term survival of the company ... the list of problems goes on and on, but it all boils down to human nature. You can't do a job well if you are only interested in the end result.

How to Address Manager Investors in the Work Environment

Believe it or not, most Manager Investors actually are good people, thier circumstances just make them difficult people to work with. Below are some tips for how to better manage this relationship if you choose to continue working there:

Before you do anything else, you should clarify what he means by free time. This whole problem could be blown out of proportion if he just means your free-time during normal working hours that you don't have anything else to do. My boss frequently tells me to do things in my free time meaning next time I don't have anything important to work on.

If he does mean after hours, remember that investors don't need any formal background to get "hired", your boss is probably just ignorant of what he can/should ask of you. So, when he asks you to work in your spare time, and you are hourly, just cite labor law. Most countries do not allow hourly employers to ask you to do this. For example, if you live in the USA, you could say something like, "I can not do that for you. Under The Fair Labor Standards Act you'd still have to pay me for any work you permit me to do outside of normal working hours." Note how this is different than saying "You can not ask me to do that." When you say "I can not do that for you" it comes off as less confrontational and more like you are doing him a service by letting him know that you can not fulfill his request. If you are salary, you should look at the paperwork you signed when you were hired. There is a decent chance that it says something about your scope of employment like what your job entails, regular business hours, OT policies, etc. that you can cite.

As for the relationship part of the problem, is sounds like you are a developer, and he is not. Development is not a production line, but he wants it to be. Your work is never A+B=C but rather A+B±C=D. When developers talk to each other we tend to say "This will take about 200 hours" and we understand that your really mean, "this could take 100 hours... or 300.. I'll know when I get there". You can not tell a non-developer such a vague range because they don't understand how much uncertainty there is when working with other people's code. But, you are also in control because only you know how long a thing will take. There are two things you need to learn when quoting development. You should never give an estimate until you've had a chance to write down and review the scope 1 item at a time, and 2 you should always give normal people the maximum time a thing should take, not the average. Whenever I write a quote, I tend to write out each step in exact detail for myself, and estimate each part INCLUDING TIME TO REVIEW EXISTING CODE. Then I add up all the steps and add 50% to the total to cover unexpected setbacks. For smaller projects I may even add 100% since a single curveball can dramatically change the scope. So when your boss asks you in person how long a thing should take, unless your kneejerk though is less than 10 hours, the right answer is "I will let you know once I've had a chance to work it out". Then when you do work it out, tell him "It should take no more than 300 hours". Using the phrase "no more than" is important. He does not need to know that it might be a 100 hour job. The important thing is that it gives him a productions line answer of what to budget for: that is what he needs to feel comfortable with. Either he feels comfortable moving forward with that number or he does not, it's not your job to worry about how much he is willing to spend.

When he asks "Why will it take so long?", you have been answering wrong. This is true of all manager types, not just Manager Investors. When he asks this, it is because he is trying to figure out his budget, not your level of competence per say. The mistake you've made so far is making it sound like it SHOULD take less time... just not when you do it. Instead your answers to this question should be about the features that are being requested, not your ability to make it happen. So, if he asks for 3 features, the right answer would sound more like "Feature #2 is more complex than it sounds." In your head, Feature #2 may be the part of the code that you believe will take the most research, but that does not matter. Code review is part of the development process. In the end, all your manager needs to do is decide if it's worth it to him to invest in how long it will take. What you don't want him wondering about is if YOU are worth investing in.

Nosajimiki
  • 1,789
  • 1
  • 8
  • 12
  • The problem is that, he asks me how much time it would take and I have no idea, because I don't know the code, he asks me to check it, when I check it if it's easy I already can do it on the fly but if it's hard then I need to learn the codebase, but I can't just say "it's gonna take me 30 hours to learn the codebase" because I dont know how much time it will take me to learn – מיכאל ברגינסקי Sep 18 '21 at 07:19
  • Well in my country employers exploit this as "globally paid", which means they don't pay per hour, yet, if you getting sick they consider the day as hourly paid, which means that they don't pay for the first day off – מיכאל ברגינסקי Sep 18 '21 at 07:25
  • Counterexamples to this exist. But examples exist too. – rackandboneman Sep 18 '21 at 17:48
  • @מיכאלברגינסקי This is normal. Developers at other companies that work with old code simply have to work within very large margins. At my own company, it took me about 3 years to get good at predicting how long working on my company's old stuff would take, and that involved learning every developer's name and programming style who came before me. In reality, it is a waste to spend time "learning the base code". Either it is consistent enough that you would have noticed common patterns by now, or it is so variant than doing this will not be helpful. – Nosajimiki Sep 18 '21 at 22:25
  • We had a prior developer who's code was so unintuitive that I only quote rebuilding it. – Nosajimiki Sep 18 '21 at 22:28
2

You are asking if your boss is abusive -- it certainly seems so, though obviously we only have your perspective, and I agree with the answer that says that it is a bit disappointing that you are still "riding the learning curve" after a year. You should not learn the code on your own time. It is called "your own time" because it is your own.

I agree with the other answers, you probably need to get a new job. The skill set you describe is quite desirable and you should not have a problem finding it.

Once you have secured your new job I would tell your boss, politely, that you are quitting, but also offer to sell him some of your free time in which you would document what you have learned of the code to make it easier for the next person. I would charge him three times your current hourly rate to do this, and I would get it in progressive, weekly payments where he pays you for what you deliver. The worst he can say is no.

As the first response said, it is time to stop whining and take charge of your life. You aren't a cashier at a grocery store with limited options (no disrespect to people who do that job, all work is honorable, but that job does have limited power.) You have a highly valuable skillset. You have a lot of power. So stop whining, find a new job, and take charge of your life.

Fraser Orr
  • 151
  • 2
1

Your boss may be of a type who just wants to complete things for time-being and not considering future scope. You have put enough of your energy in understanding the code base. That's great. Having a boss is not a fair thing, having a leader who inspires and work with you will give you more energy.

My advice for you is " Be bold and try to stop calling him as a boss, also stick to your ground, you will definitely find a peaceful solution coming your way. Continue learning and shine better. "

Thank you. All the Best.

Blossom
  • 11
  • 1
1

The situation you describe is typical in software world. You should start looking for another job if you are unhappy and use this as learning experience to not get into such a situation again.

First of all, as a general rule of thumb, expect every codebase you ever encounter to have poor documentation or no documentation. Expect to be expected to learn such codebases on the job. However, the actual problem you face at your current job is this: you say "because of the learning curve" you are "way behind deadlines". I assume the deadlines are external and you have little or no input into them.

Understand that all software jobs are about hitting dates. Dates are the main thing. However, in functioning software companies, it is software engineers who tell management what dates are reasonable based on their technical expertise. If the dates you are missing are coming from you then you need to get better at estimating. When you estimate factor learning the codebase into the estimate. If the dates are coming completely external to you and your input then there is your problem; this is a software company anti-pattern. Tell your boss as much. As others have said start looking for a new job and next time you interview ask about the software engineering methodology the company uses, ask about who scopes the work and who estimates how long things will take, etc.

jwezorek
  • 111
  • 3
  • For a software developer, writing good software is essential, being good at estimating (especially as a young, impressionable person, under pressure from a manager who wants low numbers) is not. At that point a good manager will listen to the estimate, and draw his own conclusions about how long things take. Like "the last three tasks, the employee took exactly three times longer than predicted. He predicted the fourth task will take two weeks, so I'll expect six weeks". – gnasher729 Sep 18 '21 at 11:25
0

If you like programming as an art to itself and like your job and the code you are working on, there is technically nothing wrong about learning the codebase on your free time.

However, this should be your decision, not your boss's. Your boss has no authority over what you do outside work time.

If your boss is actually seriously suggesting this to you, you should just state your opinion straight.

user53739
  • 19
  • 2
  • I prefer working on my personal projects honestly. Plus the salary way too low – מיכאל ברגינסקי Sep 17 '21 at 05:23
  • 3
    I disagree with the first part. If you enjoy programming (and not burnt out), it's probably better to explore things that are not work. Different languages, different projects. The problem with working on work is that you build expectations, in addition, you get a much narrower understanding of your craft. – Gregory Currie Sep 17 '21 at 16:06
  • In the USA at least, he is legally required to pay you for any work he PERMITS you to do after hours. So even if this work is optional, the employer would be required to pay you for it (and in many cases, have to pay you overtime for it as well). – Nosajimiki Sep 17 '21 at 17:10
  • @Nosajimiki, unfortunately, that isn't necessarily the case. If you are an exempt salary employee, you can be required to work without any overtime pay. This got put into place because IT work is considered "essential" (in a different way than essential workers during covid) in the fact that if a website, servers, or other computers are down, they severely impact the business and are required to be fixed so the business can continue running, so the employees are required to work even if not getting paid more. It's BS & needs to change. Hopefully the OP is a contractor and not subject to this. – computercarguy Sep 17 '21 at 17:38
  • @computercarguy Contracts of employment also matter. If he is an hourly employee and his contract of employment has an established hourly rate and terms of OT, then they have to honor all hours they permit him to work at that rate, not just the mandatory ones. Salary employees are a bit different. They are paid a fixed rate regardless of hours worked unless thier hours would violate minimum wage laws. The exempt status of IT workers rarely comes into play because they tend to make so much more than minimum wage anyway. – Nosajimiki Sep 17 '21 at 18:06
  • That said, salary employees have a different set of protections. They are required to agree to a clear scope of duties before you hire them. Since they told him the code was well documented when he was hired, this is outside of the scope of his salary. You can't ask a salary employee to do what is not his/her job. – Nosajimiki Sep 17 '21 at 18:09
  • @Nosajimiki, sure, the agreement for employment has to be considered, but in the US, not many people work with a contract when a direct employee. And even salary employees get overtime, just not the exempt ones, which is why they have the special status of exempt. The exempt status rarely comes into play because employees don't understand it and don't speak out against it, and their wage shouldn't have anything to do with if they get paid OT or not. – computercarguy Sep 17 '21 at 18:10
  • And the bit about "agreed to work" without a contract is a myth. Most jobs have a line about "and other duties as assigned" built into them, so the boss can tell them to do just about anything and make them do it, within certain restrictions. – computercarguy Sep 17 '21 at 18:11
  • @computercarguy wage matters because exempt status is about a company needing to meet minimum wage laws. A non-exempt employee must be paid at least min-wage for 1st 40 hrs and 1.5 times that for hours over. An exempt employee can be paid min-wage for hours over 40, but if you already make 1.5 times min wage, the law does nothing to protect you because you will always hit min wage requirements. But if an employer agrees to pay an exempt employee OT, he is required to pay it because those are the terms of employment. – Nosajimiki Sep 17 '21 at 18:15
  • Yes, you do have to be very careful about agreeing to "and other duties as assigned" if you are salary. – Nosajimiki Sep 17 '21 at 18:18
  • @Nosajimiki, exempt salary workers must meet a minimum salary, not min-wage, to be considered exempt. The definition of exempt salary specifically means they are exempt from OT pay. https://www.dol.gov/agencies/whd/fact-sheets/17g-overtime-salary There's also no restrictions on job title or duties, just general functions of the job and primary duties, not "other duties as assigned". https://www.dol.gov/agencies/whd/fact-sheets/17e-overtime-computer – computercarguy Sep 17 '21 at 18:32
  • 1
    @computercarguy Hmm, I never realized how exploitable that law is. While it in most cases ensures that a tech makes way over minimum wage, a salary tech who averages > 75hr/wk could actually make less than minimum wage... not that I know any techs that would put up with so many hours, but I can see how on a smaller scale this law would incentivize companies to who can't afford 17.1/hr for tech work to just hire fewer techs for more hours. – Nosajimiki Sep 17 '21 at 20:08
  • @Nosajimiki, yes, it's actually a pretty big, if invisible, problem. I worked at one firm that was paying me $40k as an exempt software developer and threatened to implement 12 hr days 7days a week to "catch up" on "missing" work, since we didn't live up to their unrealistic expectations and failure as management. Many companies use "exempt salary" as an hourly worker that doesn't get OT, and they keep their employees ignorant to what it really means. I wish IT unions were more common because of this, but many IT companies specifically prevent unions for emerging. – computercarguy Sep 17 '21 at 20:15
  • @computercarguy You can be made to work longer for business reasons. Not employing enough people to do the work is not a business reason. And 84 hours a week is idiotic. You will do less work in 84 hours than an 40 after the second week. The only time this is acceptable is if there is an absolute deadline that must be achieved, and after say two weeks of 84 hours the company gives you two weeks of paid holiday. – gnasher729 Sep 18 '21 at 11:30
  • Agreeing to do that, though, should come with a quid pro quo. Be it power or money. – rackandboneman Sep 18 '21 at 17:49
0

You only learn in your free time if it is beneficial for you. Say a new programming language that will hugely improve your chances on the job market, you might consider learning on your own time. But if the company profits from it as well, you would negotiate to get something out of it from the company.

Learning about their software is totally useless for you in your next job. And it's not something that can be expected from anyone. So that has to be paid for by the company.

gnasher729
  • 169,032
  • 78
  • 316
  • 508