It moves extremely fast. HTML, CSS, and JS are living standards now, updated every year. Browsers are updated constantly. Frameworks, tools, methodologies, etc can all go from hot to not in a year, easily. So, the platform, the environment, the tools, the languages, and frameworks, and the trends all change constantly. It's a never ending fight to keep up. You could write a new project every 6 months using a completely different stack.

Well my experiences can't really be extrapolated to everywhere. I have worked mostly inside corporations and some contract jobs but it is surprising to me how many female programmers I have worked with. My area is not a huge city like New York or LA so it's really a bit of an anomaly to have the experiences I have had with female programmers. I can only think of two or three I would put on a list of outstanding coders but that's more than most people could probably have on their list. The best one was very code intuitive and code learn new things very quickly. I think she went into management after I moved on to another job so it was a terrible loss of good in the trenches talent. Though she was the best female, it is like comparing men and women tennis players. The top woman player is ranked far below the majority of male players. There is a big gap between her programming talent and the guy above her. The top guy on my list, who exceeds me by a sizable measure to be honest, is a freakin' programming god. He is 100% self taught and can master damn near any programming technology in incredibly short time periods. I've never met anyone else like him or even close to his abilities so he's a true stand out.

Mostly it's a lot of little things like not breaking down complex tasks into smaller more logical operations, failing to recognize that they are writing the same code in multiple places instead of writing one function/method for it, horrible variable names and writing really convoluted code that takes too much time for another programmer to decipher. Other issues include relying heavily on error handling (try/catch/finally) when they could have avoided needing error trapping by refactoring things so most errors could be avoided in the first place and wanting to include huge frameworks/libraries to do things that could be accomplished with a few lines of builti-in code. Debugging skills are often lacking since they know the basics but not the real world practices so they tend to spend too much time stepping through non-issues before they get to the location of the real problem. If they are having to create any relational databases, most of them have very poor db skills out of college and make some horrible database designs that repeat data, use mutable data as keys or size data types too small for the range of data that will eventually be stored (e.g. a numeric column sized as an int where the data will exceed int's capacity in the future). Every just out of school coder will bring their own set of strange and problematic practices or styles. Many of them will no make comments in their code or will haphazardly add methods, classes or structures when a little more thinking would show them they are unneeded. I try to help them adopt a clean and logical coding style that focuses on maintainability rather than complexity or fanciness. If I end up helping one of these newbs sort out their own code from six months ago because they don't remember why they wrote it that way, then I use that as a teaching moment to stress the importance of leaving yourself a guide in the code through simpler more atomic coding and comments to explain the reasoning behind the why and how. After a year or so they usually correct their habits and write better code because they are thinking more about the process rather than simply writing code. That's the hardest part to teach. So many young upstarts just want to starting writing code before they've thought about the requirements or the process. They struggle through code reviews and testing because of that so I try to help them not be demoralized by a bad code walk through so they will learn more rather than simply mope or complain that they were reviewed harshly. It's a mixed bag and I've run into all kinds of things with young programmers. Some have the potential to move on to great things with a little help up front but others never mature much. It's a function of their motivation to learn and a willingness to understand that it takes time to get there. I always love it when one of my protege programmers has their eureka moment and realizes that they've advanced to the next level because they just discovered on their own that the things I taught them really do pay off down the road. That's usually when I tell them it's time for them to start thinking more like a mentor than a student so they can continue the cycle.