#begin
The next section of the chapter we will discuss is about knowing when to start, and stop or maybe pause for a bit. David and Andrew say you should listen to your nagging doubts. As a developer you are constantly doing things that work, or don’t. All of this contributes to your experience and wisdom. At some point your intuition will tell you that some approach will just not work properly, is not secure or the performance will suck ass. This can lead to some reluctance to implement a certain feature which is a good thing. I mean, have you ever experienced the problem where some manager type person, or maybe even a customer dictates how things should be implemented on a technical level? I bet you were reluctant to comply. I remember having a discussion with a customer who demanded us to implement some random power-up algorithm by shuffling a list and then iterating it until reaching the end, and then shuffle it again and start over. I didn’t want to do it that way because it’s a really statefull way of doing things. So I just used a system.random and kept track of the previous index to never get the same power-up twice in a row. Do you have an example of such a scenario? Leave me a comment if you do.
Good Judgment or Procrastination
Sometimes starting a new project can be daunting. Many might even prefer to put off the commitment of starting it. But how do you know if you are just procrastinating or you’re responsibly waiting for puzzle pieces to fall into place. Sometimes it might just be better to wait until some other things were cleared up, maybe by other teams, before starting. These other things might even unblock certain approaches. Imagine you would need to implement some Web-API. If this API, and the specification does not exist yet you might need to invent some DTO objects that would fit the use-cases you need to solve. However, if the API is already available it’s really easy to extract the DTO objects from the API specification and implement them. So waiting the the API to be there, or spending time with the back-end team to create the API spec is a logical first step to take, or to wait for.
David and Andrew mention that if you really do need to wait, a good technique to make some progress is to start prototyping in an area you expect might be difficult. They say that one of two things might happen, 1) you will get bored really soon which is an indication that your initial reluctance to start was just procrastination and you need to jump into real development asap. 2) you find that your prototyping provides you with some revelations about the problems you are trying to solve. This means that your initial reluctance to start was on point and it was good judgment to putting the project off for a bit.
I really like this approach. It allows you to make some progress, without much commitment. I think it also enables you to document and communicate your initial findings to you colleagues before diving into real development. So from a design perspective it will be useful too.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments