One question that comes up quite often is if you should always use async/await or not. Sadly enough the answer is not simple because there is a trade-off between performance and ease of understanding exceptions.
Yet another estimation rant
Lately I've been discussing estimation a lot with both colleagues and friends so I guess it is time to go at it again. As I've mentioned several times before; I'm not a believer in estimates. The process of estimating is good in order to understand and break down complex problems but the estimate itself as limited (if any) value in my opinion.
Don't let your constructor create the world around it
I recently listened to a developer podcast about the async/await feature in .Net. And I was terrified when the host asked about using those key words in the constructor.
Posted by cellfish at 05:23 No comments:
I try to live by the motto; starting the debugger is a failure when it comes to code I write. That means that through logging and just reading the code it should be possible to figure out what is going on in my code. However quite often I have to work with code I did not write and then some advanced breakpoint tricks come in handy.
Posted by cellfish at 05:04 1 comment:
Proper collection implementation in .net
Most people I've worked with that needed a collection of some sort have implemented the collection by inheriting from one of the standard collection classes. This is however typically not the right thing to do since you expose more functionality than you really want in many cases.
Why refactoring user stories is a bad idea
There is this old article that I wanted to discuss for a while and now is the time. If you'd rather say technical dept user story instead of refactoring that is ok. The logic applies to both.
What fire and forget really means
From time to time people implement something that they want to use in a fire-and-forget fashion. Typically it is some non-critical service you want to notify. Sadly most people get this wrong since they don't understand what fire-and-forget means and instead fire blindly.
Xbox Live History - Part 2
The excellent first part of Xbox history has been followed up with a second part.
Bleeding HTTP status codes
Developing web services there is an anti-pattern that I often see slip through the cracks and that is when HTTP constructs bleed through abstraction layers.
Should bugs be user stories
One topic that seems to come up regularly when teams try to be adopt agile is how to deal with bugs. Since these teams typically give Scrum a try they feel the urge to get as many story points as possible so it is natural to wanting to give these bugs story points so you get some credit for them. IMHO that is a huge mistake.
Posted by cellfish at 06:03 No comments:
Subscribe to: Posts (Atom)