Just the problem statement

[Tina Desai]

Few days prior one of my senior said that we should be able to take the problem statement and should be able to solve the problem on our own. Having been in the project for 5 months now this can be a somewhat valid expectation. I however have got a tendency to cross check things and also I do not start solving the problem till I understand what the problem is actually. At times it takes a little longer than they expect me to understand the problems logged as one liners. What efforts should I put in to solve this?
Thanks and Regards,
Tina

[HS Thomas]

it takes a little longer than they expect me to understand the problems logged as one liners

Problems should also have their complexity or degree of difficulty logged.
Usually,it is a number.
1 = easy, 2 = medium , 3 = hard.
Accordingly time should be allocated to solve the problem and steps taken to ensure it doesn't happen again.(This could involve several members of the team depending on the problem).
regards

[HS Thomas]

Also, as your understanding of the problem grows you should be allowed to re-write the problem statement. (Or , add to the notes).
regards

[Greg Neef]

I have seen a hundred problem statements and they are by and large worthless. There is a reason you develop use cases and a user oriented design and do so with interaction with the users. The 'senior' who told you this is no senior developer in my opinion.

[R K Singh]

Originally posted by Tina Desai:
I do not start solving the problem till I understand what the problem is actually.

And never start in future also.
Its a good practise, the only thing I can say right now, use your resources while understanding the problem like asking questions to your colleagues and best will be asking question to your senior, he must know full project in detail and should be able to answer your all questions and he should not annoy on repeat question.
If you dont understand the problem well then you will endup with lot of repeat work.

[Tina Desai]

Im a believer in discussions. It brings out something that was "assumed".
Not that I discuss things for the level 1 probs also but I do tend to take a second opinion sort of on the appraoch Im following if I feel it is not a trivial code that Im touching.
In what time a new comer is expected to be on his own. Sooner the better we know but any practical stats anyone has?
Also, tomorrow when Im a senior, do I do things without discussion, just coz Im senior?
Tina

[Mark Herschberg]

I must admit that I do not fully understand the matter. I'm not sure what these problem statements are or how they differ by level. Nevertheless, here is some general advice.
One of the biggest problems on software projects is a miscommunication of the specs. When in doubt, confirm.
If you can, always try to find the information out on your own before checking with others. When I give the internship kickoff talk at an MIT program, I always advise the students not to do "negative work." By that I mean, if the intern sucks an hour a day from a developer by asking questions, and that intern does produce as much value in the other 7 hours as the developer would have in one, then the intern did negative work. I'm not claiming that you are doing negative work, simply that many interns and junior engineers turn to a co-worker instead of looking it up directly (I'm still guilty of this myself sometimes). See if you can answer it on your own first, if possible, then check with someone else.

Originally posted by Tina Desai:

Also, tomorrow when Im a senior, do I do things without discussion, just coz Im senior?

Never do things just because of some title or rank, do things because they make sense. If you still have questions, ask them. If it's not part of the company culture, maybe you can change the culture for the better.
Good luck.
--Mark