The design phase is a vital part of the software development process; if you cannot design software, you cannot develop software, and shouldn't be calling yourself "software developer" ("programmer" would be more appropriate).
However, designing software is not about diagrams and flowcharts. It is about figuring out solutions to a given problem on an abstract level, and planning how to translate those into an actual software product. Diagrams and flowcharts help in communicating these solutions and plans, and sometimes they help get a clearer picture, but many software developers have only superficial knowledge of UML, if any, yet they design beautiful software (and, vv., the mere fact that you're an ace at drawing flowcharts says nothing about your ability to design good software). If you can communicate and design well, any tool will be fine; the English language alone will do if nothing else is available.
TL;DR: Yes, software developers should have and maintain design skills, and no, UML e.a. are not requirements for this (though possibly helpful).
I thought agile is about schedule only?
It is not just planning. Agile software development is more about being a evolutionary development and a time-boxed iterative delivery with adaptive planning which encourages flexible response to changes requested by product owner.
Or am I designing incorrectly (with UML) - does anyone design by pseudocode?
In my experience charts are much easier to understand from a client stand perspective. They are visually appealing and many times very colorful and easy to follow. However, it is very hard to maintain charts due to the nature of disconnect with the actual application code. Every time a change is made in the application the developer has to take the time to update all documentation including charts. However, that problem can be easily eliminated once there is a BA in the team or company, who understands client business process well and can manage the UML diagrams.
Tools like UML can make this process easier but only works well with object oriented programming. Pseudo code is much easier for technical teams. The process of creating this code greatly increases the speed of the actual programming language development phase.
There are some other alternatives that you may look as well:
- Data Flow Diagrams
- State Diagrams
- Process Flow Charts
Good references to look: Software Design Tutorials. In addition, i would personally advice to read a good blog on Pseudocode or Code? posted by Coding Horror - my favorite blog to read :)
All in all, there are some trade-offs that you need to consider.
Best Answer
Even for a system that is not designed according to the OO paradigm, you can still use UML notation to document the system, possibly extended with some Data Flow Diagrams (as I can't immediately find a corresponding diagram in UML). Diagrams worth looking into, even for non-OO systems are:
When modeling a non-OO system, you may have to be a bit flexible as to what you model as a 'class'.
For example, if you have a header file stack.h like this
with corresponding implementation, there is nothing to stop you from presenting that as a 'class' stack in your models.