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.
Hit 2, 3, and 4 all on my first project. That went down badly.
A project existed, that I thought sucked, for storing customer details, to let techs remotely lookup things like onsite IP addresses and the like, because clients never really set aside time to document.
I thought two weeks to rebuild the frontend in Python... It took 8, and did not a damn thing more or less, was slower, less reliable and fewer techs knew Python.
I thought it was great for having 100% test coverage, but the fact of the matter was it sucked, was overtime, and pretty much a waste of developer resources.
However, it did inspire the maintainer of the better, original version to document his code, and build a test suite, because he could basically rework the one I made.
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.