How can I be more productive at work? (additional context inside)

Question

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?

Answer 1

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.

Answer 2

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.

[added]

Go read Michael Feather's Working Effectively with Legacy Code

Answer 3

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.

Answer 4

Looks like I slightly late, but I'm sure, good answer for good question, will not late :)

So, you have large chunk of code, and you have to maintain this code (fix bugs) and you have to enhance this code (add new features), and this code is not well written.

First, I prefer to think, this is some sort of challenge, and this point change all things - troubles become tests, how much I strong and creative, in this war against complexity.

Second, I use best techniques and skills to solve my task:

• Sure I'm strong in algorithms and data structures (Knuth).
• Strategically, I use best techniques and technologies to manage complexity - by dividing project to loosely coupled parts (OOP patterns, lambda, good concurrency templates, administrative privileges - mean the best if all functions will be done by separate non-administrative login)
• Tactically, I create documentation of project (maps, diagrams, even just serviette style). Then I use TDD/BDD, first to create/check my understanding of structure of project and second to tightly bind parts of code to my map of project, and than I constantly spend significant working time to refactor or even rewrite code, so code will become modular and structured.
• And don't forget to take some rest - talk/walk with girls, view cinema, football, etc ;)

Answer 5

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%.