The 4 classic mistakes of programmers in their first "real" job (all made by myself, too, of course):
1) Spending a lot of time building something yourself, where you could have just used an existing library. Example: Writing XML parsing code using the plain DOM in every single DTO class, rather than using a mapper library.
2) Starting a huge refactoring or rewrite of existing code, for no other reason than you think you know better, while being too new to the project to realize where the real problems or reasons lie.
3) Over-engineering. Typically in building a flexible, powerful framework, where a simple hardcoded implementation would have been sufficient. Example: PO asks for a page with statistics about how often X has happened per month. Built a framework for displaying any kind of statistics simply by supplying a where-clause. Was never used for anything but the original request.
4) Giving unrealistic time estimates by assuming the best case for everything. For any kind of complexity in the requirements, there's always something that does not work out as expected, so plan for it. Also, in most cases it's better to give an estimate that is a little longer, but realistically and reliably achievable.
1) Spending a lot of time building something yourself, where you could have just used an existing library. Example: Writing XML parsing code using the plain DOM in every single DTO class, rather than using a mapper library.
2) Starting a huge refactoring or rewrite of existing code, for no other reason than you think you know better, while being too new to the project to realize where the real problems or reasons lie.
3) Over-engineering. Typically in building a flexible, powerful framework, where a simple hardcoded implementation would have been sufficient. Example: PO asks for a page with statistics about how often X has happened per month. Built a framework for displaying any kind of statistics simply by supplying a where-clause. Was never used for anything but the original request.
4) Giving unrealistic time estimates by assuming the best case for everything. For any kind of complexity in the requirements, there's always something that does not work out as expected, so plan for it. Also, in most cases it's better to give an estimate that is a little longer, but realistically and reliably achievable.