Senior developers are more productive than junior ones, or so I tell myself. Still, most employers like to hire devs 2-5 years out of college. Managers say, "These guys ae still fresh, with up-to-date skills, but they've learned how to work." But what managers think is, "These guys are cheap, and they do what they're told, because they don't have a lot of independent experience giving them ideas that conflict with my judgements."
But that's not what I would do. If I ran the world, I'd hire devs with 10+ years experience; devs who already knew what to do and could go do it without supervision. Some startups work like that. Yeah, an Old Hand costs more, maybe twice as much as raw rookies right out of school, but they are way more productive. They only have to be twice as productive (counting the managers you don't have to hire), to make them pay off.
I took a job at a company like that once. They bragged that they only hired senior folks. And indeed, the staff, taken as individuals, were bright and talented and very experienced. I was very excited, because this was just what I would do. I thought I was joining a dream team. Reality was quite a let-down.
The company founder was a guy who liked to code very fast. In fact, he'd hired this team to clean up after him. Over time the team became so outraged by the poor quality of the founder's work that they chased him away to "other opportunities". Problem was, people like to hire themselves, and the founder had hired a staff that liked to write code quickly, but didn't care to do that other stuff, like documentation, coordination, testing, etc.
One very senior C++ developer didn't trust objects. Their code looked like C, and had all the problems of C code. Another one had a very idiosyncratic coding style; they put all their method definitions in the header file. Partly this was a bad java habit. Partly they used a third-party tool for indexing the sources that worked better when the declarations and definitions were all in the same place (I think, sort of. I still don't understand). Another had a bunch of antiquated style habits they'd picked up in 1995, and couldn't imagine how their practice could possibly improve by changing their style to use modern features of C++. Naturally they each had their own indentation style, their own variable-naming conventions, and pretty much every other thing that they could do differently, they did.
They'd broken the code up into fiefdoms, so they weren't exposed to the silly habits of their peers. And they defended these fiefdoms fiercely. One of them checked in a change to my code because I'd started a one-line comment with "//", when they preferred "/* ... */". Whatever, man.
Each fiefdom had their own include files, with duplicates of the same basic stuff, that had aged differently. The code base frequently produced compile warnings (on error level 3 in Visual Studio). They didn't lint the code, or use error level 4 because it produced too many error messages, and some devs would have to change their styles to make these go away. In fact, we had a critical bug delay a release, that turned out to have printed a compiler warning. Only there were so many warnings that nobody noticed this one, or bothered to follow it down into another dev's fiefdom and fix it.
They used a funky build tool written in python, rather than build inside Visual Studio or use make. Only two of the devs knew how to fiddle the build tool. They fought with each other endlessly, changing things back and forth.
They didn't really have any documentation for their creaky old code base. When I started doing docs, it started a war. One dev thought documentation should go into a wiki. Another thought it should be static HTML web pages. One thought Word was ok. Another thought we'd be more productive in FrameMaker (which is true, but FM is expensive). One wanted docs in the source code. Another argued that no documentation could be trusted because sometimes it might be out of date, so we shouldn't even comment the code.
We bickered about whether to put the docs in the source tree, or in one of two different styles of separate file tree. I tried to suggest that the first and only really important thing we should argue about was, what aspects of the project were most important to document, and worry about how to type it later. They thought that was crazy-talk. Each used the war as justification for not documenting their code.
An Old Hand reading this may have guessed by now that the problem was management. The lead was not doing anything to make the team work together as a team. By the time I got there, it was probably too late to change them anyway.
This company was a ten-year-old startup (which is an anti-pattern itself). Their product was pretty cool, but they were having trouble breaking out into the big time. The code had a million features, and a million little bugs. They knew they needed to work on improving their robustness because the next set of customers they had their sights on were big enough to demand really solid reliability. But the siren-song of each next customer was filling up the work queue with new feature requests.
I only made it six months at that company. They thought I should go, and I agreed. The feeling I had when I left must have been like viewing the Titanic from the perspective of the last lifeboat to pull away. Only the guys aboard the Titanic knew the ship was sinking.
Teams make the company. Not individual performers, no matter how experienced, talented, or bright they are. The Dream Team of individual performers is a management anti-pattern unless they are in fact managed as a team.
