What practical steps do you take to ensure you are thorough? [duplicate]

Question

Bit of Context

I'm not sure if this is fitting to the programmers.stackexchange area, but I'm not going to post it in SO. Any problem with ambiguity and I'll happily remove it.

If I had to talk openly about my skills and how I sit in a company, I'd say I'm mid-level and about a solid year or two's worth of work away from shooting for a senior position. I'm a C# developer with a strong(ish) background and have a pro-active attitude but my downfall, however, seems to be how thorough I am, and it needs improving fast.

I've had code reviews lately, and it's brought it to my attention that I leave careless holes in what I code before I'm happy to push it over to peers for review. The kind of holes that are embarrassing to hear about, it's not stuff that's outside of the realm of what I already know and are very aware shouldn't be there. For example, I had multiple controller actions today with missing [HttpPost] attributes - something I'm well aware should be there, but were not.

Question:

What approach do you take (or what do you incorporate into your approach) to coding tasks that help avoid carelessness and ensure you're doing a thorough job?

I'm looking for some tangible measures I can put in place today to help. Do you write out what you want to do in plain text or pseudo code first? Do you break your tasks down into much more smaller tasks first with your own set of low-level requirements? Do you write myself a mini tech-spec first? Do you use unit tests to a level that's granular enough to help defend against silly mistakes?

I'm not convinced this problem is entirely down to mind set, I'm convinced my approach is off somehow, and I can't see me tackling the next level without cracking this first.

Answer 1

Do 1 thing at a time and progress to the 2nd thing only after you're done with the first. You missed those [httpPost] bits because you didn't write a controller, and all its associated code, you went straight to the next one before you'd completed the first.

We all do it to some extent, and its generally caused by coding away oblivious to what your code is going to do in action.

the other aspect is testing, did your controller method even work? If not, why not! Coding isn't about writing code. Its part documentation, analysis, coding and testing. If you miss any of those steps out then you're just an amateur bashing away at the keyboard.

You don't have to do a lot for these things, but you do have do do them. Documentation can be just adding the right comments, analysis can be a simple walk through in your head before you start, testing can be just running through the final code in the debugger. You can do these things more thoroughly if you like and have the time, but you have to do them in order to create good product.

Answer 2

What approach do you take (or what do you incorporate into your approach) to coding tasks that help avoid carelessness and ensure you're doing a thorough job?

I by and large don't - it's a waste of time.

Missing attributes is a 30 second fix and will be easily caught by testers/integration tests/UAT/whatever. In my current position (and others I've held), that sort of error is easily correctable and has little impact on business. I'm not writing code for the space program. So I'm not going to implement say... a 30 minute process to catch a 30 second fix.

Do you write out what you want to do in plain text or pseudo code first?

Rarely. The only reason I write it out is so that I can run the plan by others to make sure I'm not overlooking big things.

Do you break your tasks down into much more smaller tasks first with your own set of low-level requirements?

It depends on what you mean. In many jobs, I will break user stories (1-2 week work) into tasks (0-2 day work). That though won't help me catch overlooked attributes.

Do you use unit tests to a level that's granular enough to help defend against silly mistakes?

Absolutely. Because the unit tests generally catch those sorts of silly mistakes. Code coverage tools can help me see what things are (probably) tested sufficiently and what parts might need more eyeballs. Unit tests should be about 5 lines of code, and should have only one reason to fail. The real world sometimes prevents that, but yes, they should be that granular.

That wouldn't help for attributes on your controller, which is why unit tests are but one part of a layered testing approach.

Mostly though, it seems as though you're worrying about trivialities. Remember the old idiom - "Perfect is the enemy of good".

Answer 3

Lots of good answers already, so I won't duplicate them. However, one other process I've found useful is performing a self review of your code before yours send it out.

This is a really simple thing to do and it will make you team mates lives reviewing your code a lot easier. All you do is look at your diff before you send it out and do a quick code review yourself. If you send notes to your colleagues explaining the change this is the time to write those as well. I find that going through the review with a view of making it accessible to my team mates helps me spot things that could be clearer, or cleanup steps I've missed. Also it saves your teammates time in the review as they find less stuff to fix.

Answer 4

One approach I have been taking that has been very helpful is:

starting out with acceptance test without implementing it to give the context of what needs to be worked on and then diving into building the structure.

Once there is some structure (i.e. I have classes, interfaces, some unimplemented methods) I go ahead and start writing unit tests for whatever makes sense. Try not forcing unit test or you'll end up testing things you don't need.

I don't think this is pure TDD because I am not writing all of my tests first. Instead, I am writing one or two high-level tests to see the structure in my mind more clearly and then I go ahead and implement it. There are a few reasons why this is helpful and why it can keep you away from making silly mistakes.

1) You see the big picture first in your implementation. Even if you haven't implemented the acceptance test you already see your inputs and required outputs. This gives a whole lot of context and how you should be moving forward. Hence clear vision, which will help you be more thorough.

2) You are following TDD (even though not fully) which keeps your code testable at all times and therefore with a higher probability of being decoupled. This is just good design.

3) When you understand the context of what is being worked on your mind is more comfortable thinking about the low-level details, allowing you to reduce the amount of silly mistakes you could have made otherwise.