1) nowadays as a .net developer you can work first on your design projects, then you scaffold than into classes and then using code first and entity framework you have you db physical schema done as well, and this is so cool.
2) we are in a world where those who work on waterfall cannot think of coding without some sort of documented design (where I believe a unified criteria is so good to have) and people that after misunderstanding agile strive to avoid any kind of documentation.
Now, on my experience it depends on what you are working on. If I need to solve a simple problem with a CRUD, I will probably start writing code. Most likely to neither write a unit test for it. If I'm working in a (for example) calculation engine, I will definitely start with a class diagram. If I need to get in place a workflow that is hard to see, I will start with a sequence diagram. To my point: Design is something you do because you need to. I find senseless to do diagrams just because. When you do it in sessions, getting the team together looking for a solution for a hard-to-solve problem it will be also fun.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Aligned with your thought. There's no silver bullet. We need to be smart enough to use it on our benefit and on leaving it aside when we have something better to use (expandable to frameworks, tools and methodologies ;) )
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.
Before standing my point, two things.
1) nowadays as a .net developer you can work first on your design projects, then you scaffold than into classes and then using code first and entity framework you have you db physical schema done as well, and this is so cool.
2) we are in a world where those who work on waterfall cannot think of coding without some sort of documented design (where I believe a unified criteria is so good to have) and people that after misunderstanding agile strive to avoid any kind of documentation.
Now, on my experience it depends on what you are working on. If I need to solve a simple problem with a CRUD, I will probably start writing code. Most likely to neither write a unit test for it. If I'm working in a (for example) calculation engine, I will definitely start with a class diagram. If I need to get in place a workflow that is hard to see, I will start with a sequence diagram. To my point: Design is something you do because you need to. I find senseless to do diagrams just because. When you do it in sessions, getting the team together looking for a solution for a hard-to-solve problem it will be also fun.
I agree that we need to use dedicated tool for particular job. In my opinion UML isn't golden hammer but it can improve my work (I hope :)).
Be the way I like your example with Code First approach in Entity Framework.
Aligned with your thought. There's no silver bullet. We need to be smart enough to use it on our benefit and on leaving it aside when we have something better to use (expandable to frameworks, tools and methodologies ;) )