Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

I had recently migrated from being a student to an IT professional and I realized that I need to bring in more clarity in my thought process.

My job requires me to ask critical questions (I do programming) and I found out that I make a lot of wrong assumptions and these assumptions can turn out to be false with even a small amount of questioning and reasoning.

And the big problem is, I am not even aware that I making those assumptions, they just seem to be correct for me as second nature.

This is affecting my productivity and performance as I have to change my work when the stuff becomes more clear and I often feel really stupid for making those assumptions and it sometimes does land me in trouble.

My Boss recommends practicing asking questions. I am not sure how to start that.

Heard that writing down your thoughts is a good way to start. Anyone have any other good ideas?

share|improve this question
    
Can you give an example of a project where you had to ask questions and make assumptions? What questions/assumptions did you ask there? –  TheIndependentAquarius Jan 10 '13 at 8:53
    
I cannot point to a particular example as my workplace encourages active questioning and all tasks required questioning and were not to be accepted as it is given out. . –  Binny Jan 11 '13 at 8:41

4 Answers 4

(I do programming) and I found out that I make a lot of wrong assumptions

  • Make Test Cases BEFORE you start coding. Study the documents pertaining to how to make test cases efficiently. Test cases will tell you what do you require and what you don't. What to do if this happens and what not to do if that happens. Look at Black Box and White Box test cases.

And the big problem is, I am not even aware that I making those assumptions, they just seem to be correct for me as second nature.

  • Making assumptions is NOT the problem, the problem is that you are making the assumptions in your head not on the paper. When you feel That's obviously correct, lets move on!, my suggestion is to immediately write down WHAT is obviously correct, and WHY. What are the possible test cases pertaining to the obviously correct thing. WRITE them down. Make a list of all your assumptions with the reasons/ifs/buts specified in detail. Send this list to your team mates/boss. Let them review it.

    If you need to edit your list according to new suggestions/assumptions, do NOT delete the old wrong assumptions. When, both, the right and the wrong assumptions will be in front of you in the written form, you'll be able to understand the thinking process.

I have to change my work when the stuff becomes more clear

  • UML is there for a reason, so are the Flow charts and the Data Flow diagrams.
share|improve this answer
1  
+1 for suggesting to externalize the assumptions into test cases (preferably automated unit tests). –  Lernkurve Jan 20 '13 at 0:27

Cognitive behavioral therapy would be my suggestion of something to consider to help change your thought processes. As an example of something to consider here, the idea of creating "Thought Journals" where you document various thoughts you had in the day and find evidence for and against the thoughts. It isn't necessarily easy to do but it can be a useful tool to have.

Something else to consider is what kind of edge cases does a scenario have. For example, if you have a form where someone is to enter a number but they put "X" in instead, what does the form do? There can be something to be said for practice being a useful point here in that I've seen enough problems that it isn't hard for me to come up with various boundary conditions or edge cases that may make people go, "Huh?" because they haven't thought of this possibility.

Periodically, it may be worth reviewing where you did and didn't ask questions. For cases where you didn't remember to ask a question, consider writing down these questions when you do find the need to ask them and see if a pattern emerges after a few weeks. It is possible that after a while, you'll see what kind of blind spots you have.


Edge cases tend to be simple to find if you've done enough examples. Take the comment functionality on this site for example. Comments less than 15 characters or more than 600 characters aren't allowed because of requirements. This means that there could be tests near those boundaries also known as edges or limits so that is how the term is applicable. For any little function you write, what kinds of erroneous input could enter would be an example of an edge case.

share|improve this answer
    
Thought Journalling seems to be a good suggestion. I did not get what you meant in the second para but the suggestion in third to seek blind spots seems useful too. Thanks. –  Binny Jan 10 '13 at 8:23

For any definition spec, a full spec includes all assumptions, otherwise an odd use case or condition may break it.

As this is not a perfect world, teams know that it is hard work to get these assumptions right, and some of the processes used to make them as complete as possible include:

  • brainstorming with team members
  • reviewing assumptions from other projects, and detailing all assumptions made on this project
  • using another team to challenge assumptions
  • interviewing end users to understand their assumptions, as they may be very different to yours

And so on. You will start to build up your own internal list of issues so you will get better at this.

share|improve this answer

I think this happens to all of us at some times. We all have to make some assumptions. If you can bounce your known assumptions off of someone that knows the ropes in your environment and "area" of development early on, I have found that helps root out half of the bad assumptions right off the bat. It usually only takes a couple minutes and as you alluded to, it can save you a lot of time if you can clarify before any time is wasted.

I find it's helpful to start any problem by getting all the information you have already together in one place (written or electronic), and ask questions to clarify what is needed is exactly what you are planning to do. Initial conversations clarifying requirements and what is expected from your client/boss/end users also helps you to clarify what you know and what you don't. It takes time to learn what questions need to be asked, and that's a learning curve in most vocations. Knowing what to ask, and of who, is a valuable skill we can all benefit from.

Also, as soon as an issue surfaces, challenge your assumptions. If none are apparent, you may need to debug things line by line to identify where things start to go wrong. With that information, you can then start diagnosing/fixing or getting another set of eyeballs on the problem.

Pay attention to types of questions others ask you to help narrow down the problem. I am lucky enough to work with some people who model good question asking. If I approach them with a problem, the first thing they do is ask questions to help narrow down the problem. Generally they will start with simple questions to rule out obvious issues... "Are you on the right server?" "Are you logged in as the correct user?" ... progressing to more specific questions along the lines of "Did you try it the way it works over here?". "Did you use VisDif to compare the two files, to make sure those are the only differences between code you know works and the code that isn't?" It might sound silly, but the HelpDesk question "Is it plugged in?" is asked for a reason. I would guess that 90% of problems are something simple that has been overlooked.

I believe all of the above is helpful when looking at how to ask better questions based on your known assumptions. As far as the assumptions you are "not aware of", I would recommend you do some self-reflection and consider the kinds of biases that you may be more prone to have, and make an effort to consciously consider if any of these might be in play. This may or may not guide the questions you plan to ask.

Finally, plan what you ask if possible. Gather known information, consider what you need to know, and write questions that will help you gather the information you need. Consider who the best person to ask the question of is, and ask concisely to respect the time of others. If you want to practice asking better questions, it might be a good idea to plan some questions about a piece of work, run those questions by others (ex- your boss/senior developers) and ask them if there is anything else they would be asking or anything they would ask differently.

Disclaimer: Being fairly self-aware, I know I have to work on some of the above myself. We all make mistakes and assumptions, but the key is to learn from past mistakes. If you made an assumption that makes you feel "silly", console yourself and others by making sure those aware of your mistake know that you won't be making that same error again... and do your best not make that same mistake again.

share|improve this answer
    
Knowing what to ask is definitely the biggest hurdle for me but I guess that requires familiarity and experience. As for this trait happening to all people, I feel that I am more at prone than others around me as my colleagues and friends have been pointing it out. The real issue is that I am not aware that I am making an assumption in the first place and take it to be the truth almost as a second nature. –  Binny Jan 10 '13 at 8:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.