Should I resign if I felt depress with messy code ?

[Lee Kian Giap]

I landed a new job which have messy code (i.e Swing and EJB < 3.0) , that made me feel freaking hate to open the IDE everyday, manual code merging ... etc. ... Should I resign if I feel depress with all these legacy and messy code ?

[Joe San]

Often times even I used to get into such situations. But I make it interesting by trying to fit in new technologies into the existing one. For example, why not try to migrate to EJB 3 and you'll realize that it gets interesting.

[Lee Kian Giap]

Hi Joe Harry,

Thanks for reply ! I will do that if it is a one man show project.

[Hussein Baghdadi]

We all like to work with the latest cool technologies but real world jobs are a little different.
Try to drive the change (smartly, don't force your opinion).
Manual code merging?
Introduce Git or Subversion to your team, sell them the benefits of SCM and how it is going to change their lives for better.
Legacy code?
Legacy code is untested code, embrace unit testing and spread the spark.
Look for an idle computer here and there and install Jenkins.
Schedule a bugs festival or code review weekly.
What I want to say is try to make your job fun.

You shouldn't leave your job because some one told you to do so, you are the only one to decide.

[Deepak Bala]

You shouldn't leave your job because some one told you to do so, you are the only one to decide.

Agree.

That said be wary that folks dont like turning stones with a gazillion insects under them. I recall trying to change a codebase to fit standards and was left with half the code base in bad shape while the rest of it was good. No time to complete the job. The inconsistency can actually work against the next programmer trying to make a code change. If the entire JSP is written using document.writeln() for example (true story), it is better off to leave it that way.

Your time can be better spent elsewhere if code is written so badly that re-factoring it will take more time than writing it from scratch

[Lee Kian Giap]

Thanks a lot for all the replies ~

I have floundering for 2 weeks on this, now getting better and settle down the repelling feeling.

Your time can be better spent elsewhere if code is written so badly that re-factoring it will take more time than writing it from scratch

I agree with that, experienced this situation in my past job where the whole system is written using JSP and some plain class, all using GET, all page navigation is Redirect even though it doesn't need user interaction, causes problems such as security and also not able to reproduce bug raised. I have try to introduce the good practice by slowly extracting code to Servlet, explaining and showing some sample, etc. End up all I get is resist from most of the colleague (only few have the same thought with me, those who resist normally is on functional and high position). Well, so sometimes I should just close one eye and move forward though it breaks my principles ... for me is Principle vs Salary ... for company is Profit vs Cost ...

We all like to work with the latest cool technologies but real world jobs are a little different.
Try to drive the change (smartly, don't force your opinion).
Manual code merging?
Introduce Git or Subversion to your team, sell them the benefits of SCM and how it is going to change their lives for better.
Legacy code?
Legacy code is untested code, embrace unit testing and spread the spark.
Look for an idle computer here and there and install Jenkins.
Schedule a bugs festival or code review weekly.
What I want to say is try to make your job fun.

Git/Subversion ~ I have practical experience on this, but need time to understand the whole process of the current SCM
Unit Testing ~ Legacy code is actually tested code, Unit Testing + System Integration Testing + User Acceptance Testing + etc. just that they are manual testing. For automation testing (e.g. using JUnit or TestNG), is good to have, it help when any code need to be re-factored, it help when bugs introduced, it help where it is an evidence of test result that can be showed to client ... well, 2 practice for these, TDD or DDT? I prefer DDT.
Jenkins ~ Thanks for introduce this tool to me, never tried this before, will embark on it.

Actually, not because of latest, but somehow can say it is cool, in the way that those COOL framework reduce the workload, improve productivity, improve maintainability, improve changeability ... and etc. which I can't list it all out here. Well, at least, for legacy code, I need documentation for some specific design, on how to use it, on why it is design in that way, on what the benefit it bring (e.g. self-build Swing GUI classes which have a diagonal kind of type hierarchy implementation) ... at least it is not there just because of ex-programmer trying to show off the so called "Java" skills ...

By the way, at the mean time, I am trying to draw out the UML Sequence Diagram and Class Diagram, so that I can clearly see the architect of the legacy code, and I can clearly know how the object talk to each other. Well, is a new challenge for me, started to read this book, titled "Working Effectively with Legacy Code".

[Rajan Chinna]

John Todd wrote:We all like to work with the latest cool technologies but real world jobs are a little different.
Try to drive the change (smartly, don't force your opinion).
Manual code merging?
Introduce Git or Subversion to your team, sell them the benefits of SCM and how it is going to change their lives for better.
Legacy code?
Legacy code is untested code, embrace unit testing and spread the spark.
Look for an idle computer here and there and install Jenkins.
Schedule a bugs festival or code review weekly.
What I want to say is try to make your job fun.

You shouldn't leave your job because some one told you to do so, you are the only one to decide.

In my current job I do bug fixings almost every day, wondering what do you do in bug festival ?

[Hussein Baghdadi]

If the project your team is working on is crying due many bugs and unresolved issue, you suspend development and announce a festival !
A whole day to solve the issues and eliminate bugs. Don't forget the Pizza, it makes wonders.

[Henry Wong]

First, as a person who sees lots of client code over a few decades, I am willing to bet that this "messy code" is nowhere near as bad as I have seen. Second, as a person who worked with tight deadlines (and with inappropriate libraries and frameworks), I can state it is very easy to write "throwaway" code that doesn't get throw away.

Having said that, I can state that I have never hated to work with code (no matter how bad it was). And certainly never to the point of wanting to resign. Hopefully, your wanting to resign is an exaggeration here. Working at a job that you hate is not good for the health.

Henry

[Lee Kian Giap]

Henry Wong wrote:
First, as a person who sees lots of client code over a few decades, I am willing to bet that this "messy code" is nowhere near as bad as I have seen. Second, as a person who worked with tight deadlines (and with inappropriate libraries and frameworks), I can state it is very easy to write "throwaway" code that doesn't get throw away.

Having said that, I can state that I have never hated to work with code (no matter how bad it was). And certainly never to the point of wanting to resign. Hopefully, your wanting to resign is an exaggeration here. Working at a job that you hate is not good for the health.

Henry

Thanks for your reply, well, you may claim it as exaggeration.

By the way, you can share some experience on how bad is the "messy code" you encounter ?
Some example that I can think of ... as follow
1) inappropriate design and without frameworks (e.g. legacy JSP/Servlet code which have Request handle by multiple controller ? this can be improved by using Front Controller as a Gateway to handle all incoming Request)
2) a java file that have >30k of line ? or even >50k of line ? (how do you handle this ? separate it out into different class or file ? testing team won't do the test if this is not part of Change Request ... is your fault as busybody to touch other ppl's code which is work although is terribly unreadable)
3) terribly indent code (e.g. open if statement 3 tab indent , with the closing curly brace 1 tab indent ... you can use eclipse auto code styling to do that ? manual code merge team will blame you for causing a lot of merging conflict when the environment is not using those SCM tools)

on top of the above example , even you don't allow to change it, you still able to trace it slowly and work on it ... yes, this is right, but you have to know the man days allowed by ppl who not involve in coding doesn't know that the code get messy and messy day by day ... when productivity drop with the same estimated man day allowed ... there comes the stress ... kpi performance assessment drop ... causes career advancement ... and all the chain reaction

one day , after you stay there for few years (ok, unless you tell me you stay in the same company for >10 yrs or whole life, which I will if I landed the job that I can accept its weaknesses and cherish its strengths) ... what are you going to tell in the next interview ? Can you provide me some example ?

[chris webster]

Maybe you need to accept that there are some things you cannot fix. At least not without the support of your company to do the job properly.

Every large non-trivial system is a legacy system from the day it's delivered, and it's usually full of stuff people would like to change now they know what the customer really wanted but which they never had/will never have time to fix properly. We all try to do the best job we can, but sometimes external factors mean you have to deliver stuff that you'd prefer to have done differently.

Of course, your system sounds exceptionally bad, but if the people who own the system and pay your wages won't accept that it's a problem, then there's not much you can do about it. Just try to do the best job you can within the parameters of what's possible. Fix the broken windows that you come across in the course of your own work where you can, but be careful not to impact other parts of the system, and don't spend too much time fixing stuff that nobody else thinks is broken in the first place.

For example, code layout is one of those annoying but non-functional issues where it is probably better to leave it alone: you could easily end up accidentally creating real bugs if the merge process is as unreliable as everything else on your project!

And be careful of becoming a crusader on this issue: the people who created, authorised, paid for and lived with this mess may still be around, and they might not be happy to have you pointing out their mistakes. When you're ready, look for a new job if necessary, but make sure you can put a positive spin on your reasons for leaving, and don't expect anywhere else to be perfect either!

[Henry Wong]

Lee Kian Giap wrote:
By the way, you can share some experience on how bad is the "messy code" you encounter ?

Here are a few that I can think of....

1. About fifteen years ago, I worked with a company that felt that they can write a better database -- so wrote one. Back then, they had an internal database that was (arguably) better than all the DB vendors on the market. Today, I was told that their DB is no better than a free open source DB except that they have tons and tons of non-SQL code that they have to deal with. I never saw their proprietary programming language, so can't comment on it.

2. About ten years ago, I worked with a group that liked a certain programming language, but had to work with C -- so wrote a compiler (using the C processor). Imagine C code that looked like a completely different programming language.

3. Also about ten years ago, I worked with a team that wrote wrapper code for everything -- I believe the original intent was to protect them from library changes. IMHO, it is debatable if this is a good idea, as libraries are more than just naming the functions. Different packages API are coded differently. Anyway, included in the wrappers were the OS library (and the C library) -- imagine having to use the wrappers even for basic operations like open(), close(), or printf().

Henry

[Matthew Brown]

A current system I maintain (written in C) has some functions which are more than 6000 lines long. Fortunately we're finally getting the chance to rewrite it .

[Lee Kian Giap]

Demotivated ... now ... the only way to keep myself progress is to avoid adding additional emotion and feeling into the code ... the only way to keep myself progress is to think about the salary that will be awarded end of each month

dragging my life and wasting my time

[Henry Wong]

Lee Kian Giap wrote:Demotivated ... now ... the only way to keep myself progress is to avoid adding additional emotion and feeling into the code ... the only way to keep myself progress is to think about the salary that will be awarded end of each month

dragging my life and wasting my time

Based on your other topic...

https://coderanch.com/t/534156/Jobs/careers/Not-sure-want-after-years

It looks like you decided to leave IT, and move onto business. Based on this topic, I am thinking that you made the right decision.

Good luck at your new endeavor,
Henry

[Lee Kian Giap]

Thanks for your wishes.

But I have no idea to carry out the transition. Is it that difficult for a Developer to transit to other career ?

[Henry Wong]

Lee Kian Giap wrote:But I have no idea to carry out the transition. Is it that difficult for a Developer to transit to other career ?

If you have any contacts -- such as if you are a IT consultant to a business -- maybe you can get help with getting into a training program or an internship. Other options, maybe some of your experience can be used to help you.

Besides that, there isn't much more. You are basically moving from one field into another field. There may not be much experience that can be transferred -- and you may be starting from stratch.


I do have a piece of advice though... when making a transition, make sure it is because you want to enter the new field, and not because you want to exit the old one. Or there is a chance that you can equally hate your new career too.

Henry

[Seetharaman Venkatasamy]

Ask for a project change, if your company has multiple projects!

[Lee Kian Giap]

Resigned from the job ... too many years of throw away codes ... and don't have a change encouragement environment

[Lee Kian Giap]

Now started to create a checklist of what I can accept and what I can't for my next job search, and reading this book "Land the Tech Job You Love" ... learn from mistake

[Sachin Dere]

Lee Kian Giap wrote:Now started to create a checklist of what I can accept and what I can't for my next job search, and reading this book "Land the Tech Job You Love" ... learn from mistake

I think you did the right thing. Can you pm me the Company Name so that i can avoid it? i work in Singapore too

[Lee Kian Giap]

Sorry, I can't do that ... may improve interview skills to ask and make sure you get what you want.