I work at a larger startup with a maturing codebase. I've only worked here a few months. I have few issues to work on currently because we are near a release. I don't have many assigned issues / bugs compared to other developers who are polishing new features, and adding regress tests. I am not really sure what to work on, but I know there is plenty to do. It is tough to find motivation as well since the work tends to be more tedious (QA).

I inherited part of the product that was poorly written- a C++ developers first foray into HTML / JS, and its my main focus here. I know all code has its issues but this code genuinely needs a rewrite (it's about 20,000 lines of javascript, lots of copy and pasted code, poor naming & magic numbers [var obj = ev.Items;, doGetStuff(), meths[method][6], etc], mostly static methods with no object reuse, no separation of UI and business logic) The UI is really bad as well, I could go on with more examples but I just want to stress the code is objectively bad, not just messy or needing slight refactoring. However, because we are near a release and the code is somewhat stable at this point, nothing should be changed that may impact the release. Ideally they just want the code to have more unit tests, testing, documentation, etc.

Since it's mostly javascript that's tightly coupled to ASP.NET code behind pages, it's is extremely difficult to unit test. In addition, there's no spec so it's hard to know if the code is even working right (there are very complex business rules.) So I'm not sure how valuable unit tests would be even if I got them up and running, which would be difficult itself.

What would look best for me to work on, so that I could seem more like a go-getter, self starter that actually does useful things in this situation? I worry that I will look lazy if I'm not actively producing anything- whether it be code, documentation, or tests. I could try to optimize, bug-fix it without breaking anything- which is risky and doesn't provide much benefit, or test the code more manually (which is probably the best thing to do, but doesn't really give me any recognition from my peers and is unfortunately very boring.) I would like to rework some of the UI and refactor but I can't do that close to a release. I'm really struggling to figure out what is the best thing to do to seem positive and hard working, and to find motivation. Any ideas on how I can be more productive?

yea i should probably rephrase that. i generally will figure out what small bit i can rewrite / refactor, complete that, get it working again, and then repeat that over and over until it's all cleaned up
–
ShawnMay 24 '11 at 20:14

what does your boss measure when deciding how "productive" you are?
–
user1249May 24 '11 at 20:24

i havent worked here that long, and i dont have too much direct supervision. im guessing it will just be based off what my project leads / coworkers think of me, and how much stuff i've broken. they seem to generally like me though.
–
ShawnMay 24 '11 at 21:03

4 Answers
4

If you want to go big, (ask to) branch your part of the project and work on cleaning it up. Once the release date comes and goes, merge it back into the main branch. This keeps the release version static and lets you work on what's needed.

Otherwise, doc and test it like they want. As you're going through it, make note of what all you're going to want to fix in the next version. Yeah, it's not exactly glorious, but you're new, so it would do you good to go over the code some more.

+1: Branching is the standard way to let developers work on new or potentially-destabilizing code while allowing the release codeline to remain stable.
–
Bob MurphyMay 24 '11 at 20:53

4

+1: The easiest way to make your coworkers hate you is to, as a new guy, come in and tell them that it's all wrong. Mostly people know this. The wrong has come about as the project has evolved into its current form, and most of them will have their eye on things that they KNOW need to be changed. Rubbing their noses in it will not be productive.
–
SatanicpuppyMay 24 '11 at 21:40

Figure out a way to automatically test this stuff. That will be the most valuable in the long run (is there a long run?). Then start building tests. If the code is too tightly coupled to be testable, work on decoupling some of it so you can test it. The best thing you can do right now is come up with a process for dealing with the mess, and then start applying the process.

I think that the best thing to do would be to make your manager or coworkers aware of how the code is tightly coupled and tedious to work with. They might already be aware of this which might be why they gave it to the new guy...

If you can come up with a plan to refactor bits and make improvements here and there, run it past your manager briefly to see what they think. That way at least they know what you want to do and why you want to do it. Plus you won't look like you're wasting time all day if there is little visible progress.

Just make sure you're not coming off as whining or bashing on the previous developer since that might not go over so well.

I find one thing people forget is the cost of having lots of features. Each line of code adds weight to the project, making it less agile and harder to maintain. Maybe you could go through it with a project manager feature by feature, ranking each feature by importance and then figuring what you can cut out. If you could cut the code size down by 50% I bet you would decrease the time till release by a lot more than 50%.