Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Just the problem statement

 
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, as your understanding of the problem grows you should be allowed to re-write the problem statement. (Or , add to the notes).
regards
 
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 5397
1
Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic