Over a million developers have joined DZone.

Improvement as a Developer

DZone's Guide to

Improvement as a Developer

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I was doing some thinking about areas where I’m lacking as a developer. There are many, but I’ll list a few here.

Testing Improvements

I think I’ve come a long way in the last few years in the area of testing. I’m disciplined about testing now and don’t write code without writing unit tests at the same time. If I’m modifying existing code without any tests I spend the time to write tests first, even if this takes longer than making the change. That said, my tests still need work.

Most of my tests hit the positive cases. I achieve good coverage and verify most features of the code but only really in the positive cases. I need to write most negative test cases.

I write unit tests which occasionally end up more like functional/integration tests. I don’t always set out to write good, complete functional tests. Most of the bugs I find after a release would be found with good functional tests written at a higher level than my unit tests, verifying the interaction between classes. My unit tests do catch a whole class of bugs that used to slip through before I started writing them, but going a level up as well would catch more (and would also be a good source of documentation).

I have a habit of testing for performance only when it’s too late. If I’m writing code that I know will be performance critical I’ll profile. It’s the code I had no idea would be a bottleneck that ends up being the problem. This ties back to having better functional tests. These would make it possible to profile more realistic chunks of code. Profiling a unit test usually doesn’t help discover the real bottlenecks.

Like performance testing, multi-threaded testing is something I need to be more proactive about. This biggest problem is it’s hard to do. You really can’t write a test to prove code operates correctly in the presence of multiple threads. If your test does uncover a problem, great. If it doesn’t it might just mean you haven’t looked hard enough. My defense against multi-threading issues is to be extremely careful when writing the code in the first place. I carefully double check the code to make sure everything is properly synchronized and thread-to-thread communication is safe. Static analysis tools like Findbugs also help. Adding good multi-threaded testing would be another safeguard.

While I avoid copy and paste and code duplication in my code as much as possible, it tends to end up in my tests more than I would like it to. If I want to make a second test like the first I try to extract methods out of the first as much as possible to make the test small. Then I clone the first test and modify it to make it test the new condition. This does lead to some duplication. It’s usually something I can live with but I’d like to be more disciplined about avoiding it.

Project Issues

I find that I get distracted more frequently when I hit a tough part of a project. I bring up the code and start working on it, then find myself reading my news reader or trying to fix some unimportant issue with my machine (maybe getting sound working in Flash). I also get distracted like this when the requirements of what I’m working on are not yet well defined. I don’t know which way to start moving forward and so I just end up sitting still.

The last 10% is always the toughest in any project. Even when the code is out the door it’s not really complete. There are always a handful of small but difficult issues that need addressing. Too often I find myself relieved to have made the release and start working on something new instead of pushing to get that last 10% completed.


If I could choose one area where I would most like to improve it would be writing. I consider myself an average writer but I would like to work to become a good writer. Trying to write more is one way I’m working on this but it seems like something you’re either born with or you’re not.

I’m not good at delegating. My first instinct when I see an interesting problem is to solve it myself. When I see a boring or tedious problem I want someone else to do it, but I usually end up deciding it would take me longer to explain the issue than to do the work and end up doing it myself. I would like to be more selective about the work I do myself.

Making improvements

I could list ten things here I’d like to do to address the weaknesses listed above but that’s kind of like making a new years resolution. I’m going to start by trying harder to avoid distraction and go from there

From http://dmy999.com

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}