Patterns are patterns, they implement themselves when you need them.
That has been my understanding. I consider that the only practical reason to review design patterns is so you can communicate the style of code to another.
After a while as you program you look through the code and see the needed meaning, shaping the code to conform to the meaning better.
Yep I know exactly what you mean. What I find kind of interesting is I would feel nervous having myself from 5 years ago in my team today.
That guy was pretty damned sharp, worked long hours, researched implemented push boundaries, and delivered some stuff I'm still proud of. But he had something to prove, he put meaning into things that didn't want or need meaning. Over engineered everything.
But a calmer/mature more strategic me says I don't need mavericks on business automation software. I'd be watching me like a hawk, because I made mistakes, big ones from time to time (my favourite was a system failure costing €50,000 in lost revenue... all my fault, I was literally told to clear my desk and was marched out the door).
You need those mavericks to push boundaries, its fun to be one, but boy its disconcerting when you have one in your team and all you need t do is deliver is a CRUD application.
I made mistakes, big ones from time to time (my favourite was a system failure costing €50,000 in lost revenue... all my fault, I was literally told to clear my desk and was marched out the door).
I wish we shared more of these tales of mistakes. It seems to me that the current software development environment involves an attitude of shame over mistakes or simple ignorance, to the point that it becomes a political battle simply to get a developer to admit fault. The only place I know that discusses mistakes would be something like the Daily WTF, where snark and condescension are the name of the game (not that I don't enjoy reading it...).
I definitely agree. That particular incident destroyed my confidence for a short while. If it was for a chain of events mainly already having another position lined up it could of had significant impact on my long term confidence.
I become a fan of agile for that reason. I found agile created "chummier" teams. I don't think it made for better project delivery, but I did find having a morning meeting made risks apparent and made people more confident to raise issues before they snow balled, and people didn't blame each other the same way. Discussion/communication is basically everything to successful delivery in my books.
I picked up a neat pseudo meeting trick I use every day now (even in big water fall projects). I go for coffee down the road. It takes like 15 minutes and the benefit well outweighs the negative.
The benefits being a casual discussion abut whats going on where people say things they probably wouldn't normally. Its best to weight till after everyone has done there morning emails, so maybe 30-60 minutes in then the gossip gets going. The amount of spite I have heard spewed about clients/vendors/colleagues you wouldn't hear otherwise is astounding. Its the casualness of the walk and cafe that lets people vent. But you have to get out of the office, you have to get away fro the structure, and away from people that may over hear the criticisms.
Also its not about a team meeting, people won't come and blurt out whats really on there mind if they think its going to get recorded and itemised. Remembering if they have read/replied to there emails before you head out. Then thats mainly whats going to be no there mind, they will bring up the problems because they are at forefront of there thinking. Its all about keeping things casual.
On the other days when things are running smoothly you get to know them more on a personal level, talk about there kids, cats, skiing, what ever. Just casual gossip and of course its team bonding. When you get to know people a little better it makes interacting with them easier, raises issues/problems etc.. isn't going to be such an assault on someone. Even just the effort of inviting someone that doesn't drink coffee goes along way.
That has been my understanding. I consider that the only practical reason to review design patterns is so you can communicate the style of code to another.
After a while as you program you look through the code and see the needed meaning, shaping the code to conform to the meaning better.