If its organising you code base, I find its best to logically group things into folders and have a file per component etc. and reference them as needed. I would look at others work for inspiration if you are struggling with this.
If you are struggling to communicate where you are in your workload with others in your team/management, then you are probably trying to do too much under a single banner.
Lets say your job is creating a nav bar. How do you best communicate where you are in a larger component such as that? Break your job down into bite size chunks.
Create a styled list
Get the static styling correct
Get hover styling correct
Get hover functionality correct
Get click functionality working
Through this test what you need to. At any point you can show what you have done, what your plans are, how its been tested, how its accessible etc, how it meets your deliverables. If you are stuck, you can show the process of how you got to where you are.
Well, it's more close to the second point. To get your exemple, let say I have to create a let user navigate around a bunch of option, I fail to correctly express a "dev plan" and to identify step in that plan. More over I fail also to correctly assess risks inside that task, for exemple, the model need to change, the feature will enter in collision with an other feature etc...
Basically my boss told me that as a manager he is very frustrated that I do not achieve to say something like "for task X, I have achieve point a, b, c and I got d,e,f left to do which should take me Y hour".
So I try to structure my work-flow better to meet those expectation. But I feel a little bad equipped right now for that ^
It sounds to me like you just need more experience with estimation of tasks. Dont be bullied in to rushing something.
I like to break everything into steps and estimate how long I think each step will take. Then I double it and give that to whoever it matters to.
As a developer, especially a Jr developer. It is not your responsibility to make sure there is no feature collision etc. You should have a clearly defined deliverable signed off by the manager. It should meet many criteria before it even reaches you.
Designs for every state
States for every interaction with the product
Huge lists of testable criteria
Any technical considerations (provided by more senior devs)
Any technical risks (any areas that are connected to the area being changed)
From that list, you should be able to break down your work into steps and under promise.
If your manager is not happy, then its his responsibility to find out why and make amends to the workflow or training. If they are demanding work be done within short timeframes, then they are likely not a great manager sadly. Setting hard limits for all work, is a great way to burn out employees.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It depends what you mean by organising your work?
If its organising you code base, I find its best to logically group things into folders and have a file per component etc. and reference them as needed. I would look at others work for inspiration if you are struggling with this.
If you are struggling to communicate where you are in your workload with others in your team/management, then you are probably trying to do too much under a single banner.
Lets say your job is creating a nav bar. How do you best communicate where you are in a larger component such as that? Break your job down into bite size chunks.
Through this test what you need to. At any point you can show what you have done, what your plans are, how its been tested, how its accessible etc, how it meets your deliverables. If you are stuck, you can show the process of how you got to where you are.
Hope I covered what you are asking?
Well, it's more close to the second point. To get your exemple, let say I have to create a let user navigate around a bunch of option, I fail to correctly express a "dev plan" and to identify step in that plan. More over I fail also to correctly assess risks inside that task, for exemple, the model need to change, the feature will enter in collision with an other feature etc...
Basically my boss told me that as a manager he is very frustrated that I do not achieve to say something like "for task X, I have achieve point a, b, c and I got d,e,f left to do which should take me Y hour".
So I try to structure my work-flow better to meet those expectation. But I feel a little bad equipped right now for that ^
It sounds to me like you just need more experience with estimation of tasks. Dont be bullied in to rushing something.
I like to break everything into steps and estimate how long I think each step will take. Then I double it and give that to whoever it matters to.
As a developer, especially a Jr developer. It is not your responsibility to make sure there is no feature collision etc. You should have a clearly defined deliverable signed off by the manager. It should meet many criteria before it even reaches you.
From that list, you should be able to break down your work into steps and under promise.
If your manager is not happy, then its his responsibility to find out why and make amends to the workflow or training. If they are demanding work be done within short timeframes, then they are likely not a great manager sadly. Setting hard limits for all work, is a great way to burn out employees.