I'm a junior engineer, but I've worked at two companies now. In both cases I've found that my colleagues and I are assigned tasks with no thought put into the design before being told to do it.
Typically I spend about 90% of my time writing down on paper how I'm going to do the task, then the code sort of writes itself in maybe a day, sometimes two if I run into difficulties with an API.
Is there something strange about this picture? Is the design supposed to be the work? I don't really begrudge it, I quite like the designing of things.
But it seems to me it would be more productive to together as a team determine the design of everything to be done, and then everyone can go away and do it pretty quickly, this would put everyone on the wavelength, and so there would be less instances of interfaces not being as you'd like. I feel that once the design is done, the coding is essentially a series of 'write a function which takes in X and does Y', which anyone can easily do except perhaps in the case of some complex algorithm being required.
I am thinking of asking my team if we could try designing things up front, before assigning the work. But I am not sure if they will be up for this, or if it's a ridiculous idea and that's why I've not seen anyone do it.
Best Answer
If you are assigned a task that has no design done for you then doing the design is part of your task.
This is not unusual. Design may have been done at some level but now the task needs it's own design.
Now please don’t take this as license to spend weeks alone doodling UML. You should create enough design so that you can see and communicate your plan. Nothing more.
You should also be prepared for the plan to fall apart. When you code and test you learn. Don’t rob yourself of that time to learn by making perfect diagrams no one asked for.
Done well, a design ensures you're pointed in the right direction before you put tons of effort into something no one wants. It's a check on how well you understood your task. Don't defeat this by putting too much effort into the design. Do just enough to show your thinking.
You know the design process is working when you’re discovering mistakes, disproving assumptions, and discovering work. If all you’re doing is making pretty pictures then it’s time to move on.
A great way to do that is to show your design to the team. Communicate well and they’ll help you find mistakes, bad assumptions, and hidden work. Listen, learn, and when needed, try again. It’s like making popcorn. When the popping stops it’s time to move on.
Presenting a design can involve the whole team but devising one is usually one or two people working on some small bit of territory that’s been carved out for them. Be sure to learn how to communicate with the other territories and you’ll find you don’t need the whole team for every detail.
Design is important regardless of the task or the teams development methodology. Even in agile. Even in chaos. It may be a screen mockup. It may be pseudo code. It may be stating your task in your own words. But, like every other development step, it must be useful, or it’s a waste of time.