1

I was hired at an iOS position for a project, that has started 2012, which means a lot of legacy logic. The salary increase was good, and I had a good impression, that both guys working on this project are there for a very long time (7 and 4 years)

Therefore I observe the following things:

  • No comments at the source code at all.
  • Big amount of massive view controllers.
  • Business logic in App Delegate and tight coupling.
  • No tests at all.
  • Hardly any documentation in Confluence
  • No time for any refactoring at all. PM wants new features and they make spaghetti.
  • Test server environment, that works from time to time.
  • No peer code reviews.

The people from here know these issues, and they are very helpful for me. But I'm starting to think, that even if I'm very active on trying to push changes, these will happen after long battles or may not happen at all.

So should I think for leaving the ship, or I have at least to try to fill some of the holes in it?

closed as off-topic by gnat, Summer, paparazzo, Jim G., OldPadawan Nov 12 '18 at 12:50

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for advice on a specific choice, such as what job to take or what skills to learn, are difficult to answer objectively and are rarely useful for anyone else. Instead of asking which decision to make, try asking how to make the decision, or for more specific details about one element of the decision. (More information)" – gnat, Summer, paparazzo, Jim G., OldPadawan
If this question can be reworded to fit the rules in the help center, please edit the question.

12

I've said it before, I'll say it again:

Working with sub-optimal code and sub-optimal processes is, realistically, a necessary skill to develop in this industry.

It'd be fantastic if every company worked in a way where test coverage was consistently high, comments were clear, concise and relevant, everything followed a neat MVC pattern, release cycles were neat and well defined, time and effort could be spent on refactoring, code reviews were mandatory and thorough, etc.

The reality is not like that for many reasons. If you bounce around jobs looking for that "perfect" process, you're going to hop from place to place constantly because nowhere will be good enough (and that's going to be a massive red flag on the CV later down the road.)

Instead, stick with it, fight for change only when you think there's a valid, obvious business reason for doing so, and ensure that the code you contribute is of good quality and well tested. Learn to hold your standards high in such an environment, and use that as an asset for your career down the road.

  • 1
    All you say is true, and I don't think that anybody can expect something different. My problem is that I see too many pitfalls, and don't think I could handle to push constantly for improvements. – Foriger Nov 12 '18 at 10:51
  • 1
    @Foriger You have to pick your battles with some aspects, and learn to live with others. As an example, I walked into a job once where the master copy of the source code was just kept (unversioned) on an external hard drive - so I pushed reasonably hard for version control, making a clear business case for it, and pretty much left all other processes alone. While I would've loved to spend all my time trying to change a whole bunch of other stuff, that would have been fruitless and likely just made me deeply unpopular! – berry120 Nov 12 '18 at 11:05
  • 3
    While I agree with being professional means being able to work with what you have, continually working with sub-optimal systems can grind you down bit by bit and may lead to burnout that could have been avoidable if you were working under better conditions. Especially if there is no attempt at process improvement, as you know you that your frustrations will never be relieved, and that you are doomed to work the same way over and over until the end of eternity. – Peter M Nov 12 '18 at 12:01
  • @peter that's why we have to be an example. If we don't then it's our failure; if, regardless the obvious benefits we proved with our example, things don't change and we just constantly fight against entropy then...well,it's reasonable to move to a different universe. – Adriano Repetti Nov 12 '18 at 15:38
  • 1
    @PeterM I agree it's not always possible, sometimes it's just better to walk away, but we should at least try (both explaining and with the example). If nothing changes THEN it's reasonable to give up (IMHO). If you walk in a disastrous environment and you throw in the towel before a reasonable attempt then you're missing the opportunity to actively contribute to the company with your professional experience (one of the best assets we have). – Adriano Repetti Nov 12 '18 at 16:32
0

So should I think for leaving the ship, or I have at least to try to fill some of the holes in it?

Two major things you bought up which you should judge your decision on.

Firstly, it is very worrying that things are not documented in basic ways, this will make your job difficult.

Mitigated by

Secondly this company has not only been around since 2012, but has enough extra work to be able to afford to pay you. The people seem to be workable with and obviously you won't be under immediate pressure to learn everything. They'll step by step you through tasks for a while.

Many jobs are not exciting stuff, they're slogging away for money. Your decision is if you want to do that, or not. You don't need to fill any holes. You can comment your work, document stuff and show an example, but at the end of the day the onus is not on you to do more than that. You're not hired to change how things are done.

Refactoring is not always an option with live systems. Great to do, and people talk theory about long term savings, but it's just not practical sometimes. But if you start doing things properly, it may get noticed favourably and you could very well be given authority to implement changes. These things take time.

0

There are two things to ask yourself. First, can you complete your tasks and be productive with the situation you described? If you can manage, then you might just fit in well. If you think those issues will prevent you from dong your job, you might want to quit asap.

Second, do you want to put in the effort to change the company culture? This will require extra work from you, as you will have to adapt to their issues, do your job and work on improving processes and documentation; on top of this, you will need to engage other developers at a personal level to get buy-in and build a relationship. This takes time. Do you think it would be worthy it? Only you know this answer.

So, there are two components: decide whether you CAN deal with these issues, and decide whether you WANT to work on improving the situation. Think about how this experience, and what you expect to get from it, will look on your CV for your next opportunity.

Not the answer you're looking for? Browse other questions tagged or ask your own question.