The dotcom bubble brought us so many bad colleagues. A friend of mine once told me: In 97 he moved from France to the Valley. He basically spoke no English, and was immediately offered several positions as team lead. He couldn't understand their questions and he couldn't articulate answers. It didn't matter; they offered him the job based on his resume and his ability to draw UML diagrams.
There are more interesting stories that may or may not be true, but my friend's experience best summarizes the time for me. If you had a good looking resume (true or not) and you showed any sign of knowledge, you were hired.
Even after the bubble burst, technologists have enjoyed almost constant demand. In 1999 (when I took my first programming job) I was only making ~$20,000 a year. By 2001 I was making ~$45,000, and ~$60,000 in 2003. During the "tough" years I was enjoying ~20% raises annually. I was very junior in those days, but the average programmer was so bad that I looked like a natural team lead.
My salary history is only anecdotal evidence, but I've heard similar stories from other friends enough times to be entirely comfortable with the assertion that any decent programmer was rarely out of work and was often overpaid.
Not everyone was making bad decisions in those days. My two favorite managers from those days didn't even want to hire me. They had candidates ahead of me, but those candidates were getting even more ridiculous offers elsewhere. I took the jobs the better candidates didn't want and worked my way up. I was junior, but I had desire and ability. Those managers wanted the best, but they had to settle for what I was bringing to the table. If I was junior and commanding decent salaries, imagine what the good guys were getting paid.
Luckily, everywhere I went there were a few people who were senior, smart, and willing to help out an aspiring team member. They were the team members who took all the hard work and always delivered early. The Hero Coders of those days.
There were definitely smart managers and smart developers back then, but they were (and are still) the minority.
Now, "those days" are over and technologists are in higher demand than ever. I don't think we got rid of many of the dotcom bubble bad apples, and now we're bringing in a whole new batch of terrible software developers.
The situation is worsened by the immaturity of our profession. Who really knows how to deliver software efficiently? Martin Fowler, Joel on Software, Kent Beck, Zed Shaw? I know who's practices I prefer, but it would be quite naive to ignore the possibility that I've been led down the wrong path.
Teams are generally built around shared practices, so if you pick the wrong practices chances are you are on the wrong team. If the entire team is doing something wrong, who could tell the manager? Who would even know? Realistically, the team would carry on under-delivering until someone with another perspective enters the picture. But, there's no guarantee that the newcomer is correct either.
If we cant be sure what the best practices are, how would we know who to fire? It's tough to say, but I have a few things that I look for in co-workers.
- Attention to Quality
- The Desire to Improve
- The Ability to Adapt
- Strong Collaboration Skills
Do you pass the test?
- Have you tried Test Driven Development? Can you name something you liked and something you disliked?
- What language(s) that are gaining popularity, but not yet mainstream, have you written Hello World in?
- Do you read books or blogs looking for new ideas at least (on average) once every two weeks?
- Do you at least attempt to learn a new language every year?
- If you don't understand a requirement, do you IM, phone, or go talk to the business?
- Have you ever run a code coverage or cyclomatic complexity tool against your codebase?
- and so on...
- You're junior and could use a good mentor
- Or, it's time to find a new profession.
Software will be delivered even if the situation stays the same, but shaking things up could deliver faster, cheaper, and better software. And, that world is a better place to live.
There are some good points here, but also some apparent naivety about human nature.
ReplyDeleteDale Carnegie astutely pointed out that every person firmly believes that they are right, doing the right thing and are generally superior in what they do.
There are few exceptions to this. They would include people in depression or some other mental crisis.
So when you say "If you aren't a fit, you should find something else to do" you are showing either lack of understanding of human nature or else some very strong wishful thinking.
The point of your other statement: "If you manage weak programmers, you should force them to find something else to do." eludes me.
Do you mean something along the lines of "You suck at coding, from now on I want you to just make coffee for the team"?. Do you mean "just fire them"?
I am assuming that the manager in question has already tried to raise up and develop the weaker staff before reaching for the Austin Powers, Dr Evil, flaming trap-door button.
Hi Mike.
ReplyDeleteThanks for the comments. I don't think people are self-aware enough to know they aren't a fit. However, if they don't meet the list above, I'm hoping they are smart enough to say: oh, he's talking about me, maybe I should consider finding something else.
But, I'm aware that's highly unlikely.
As far as managers, the solution is see most often is hiding the problem or pretending it doesn't exist. I'd prefer that the manager encourage the bad fit to take on a new role where they are a better fit. I'm not sure what that role would be, I think it would depend on the person. If no role can be found, then yes, fire them.
Cheers, Jay
There are two issues at play here. Apply it to different professions and trades, it's the same thing everywhere.
ReplyDelete1. Commitment & Passion - There are, and always will be craftspeople (not being discriminatory!) and 9-5ers. Simple.
2. Renumeration - There are always cases of people getting paid phenomenol amounts of money for little experience. Market demands cause this (and unions). Look at anywhere where there's not enough resources and tonnes of demand. Fact in our industry.
Above those two, what you're eluding to and what I believe is it's both sad and frustrating to see people who's skills lie better elsewhere and for whatever reason they're in the wrong profession. It leads to a whole raft of problems down the line. I've seen numerous cases of people who really should be doing something different with their life. Sit those people down and talk to them. Do you really want to be doing this ? What do you like to do ? Can you mix IT and that ? Apply your passion with it ?.
If the passion is there, and they're just not good - as someone points out - it's then a managers job to sort that out. Anyone with a passion can learn.
Fundamentally it's about passion in your chosen career, right. You seem to have it. Do what you can to impart that passion on others.
Why is that so called 50% doing the wrong thing ? Bills to pay ? The easy option ? Who knows. But every industry is the same. Don't get disheartened by it. Help those people along. Identify it in job interviews so you don't hire them. If you have one on your team talk to them. See what can be done.
If you love what you're doing and are able to do it then feel pretty damned lucky. I for one am in that privileged camp. I know there's lots of people that aren't...
Unfortunately, I doubt your audience includes any programmers that would fail this test.
ReplyDeleteThe problem is recruiting. That basically includes 4 guilty parties. 1) The HR person who doesn't know what worked and didn't work on interpersonal side when a person vacates or doesn't understand business or salary etc.
ReplyDelete2) The hiring manager: They go for contingency style recruiting, aka, throw resumes in days and see what sticks--well, what sticks is a crappy hire who looked great on paper. Just because someone passes your technical doesn't make them right for the role long term.
3/4) The corporate recruiter and the contingency recruiter and their whole hodge podge methodology. None of them understand development or their product nor ask the right questions to determine what's realy needed. They also just want to fill a job or get a fee vs have a fee (as in the case of a retained search) and do research and get the right person.
That's my perspective and that's why I started Magnet. There's a glutton of bad products, dying companies, and it's al a result of fast food style recruiting and poor human capital management.
ryan [@] magnetagency.net
p.s. I'm hiring solid backend ruby people who can run in a loose environment and build cool stuff for a client in SoHo and always looking to network with developers..
Hi Jay
ReplyDeleteSpeaking as one who would almost certainly fail your "are you good enough" test I don't believe that it is possible to be overpaid :-)
Regards, Tony
I agree with your points. IMO the best way to hire programmers is to know them personally or by their contribution to the community. Your test questions are good starters too :)
ReplyDeleteIf you happen to hire basing on resumes and/or interviews led by "HR people" you will fail sooner or later.
I think that you're also glossing over the point that having too many people who think they know everything inevitably leads to the "too many cooks in the kitchen" problem. I've worked with any number of developers who weren't the strongest in the world, but the project would have never been finished without them.
ReplyDeleteYou always need people who can just get the work done.
This seems a little fad-ish to me. Perhaps a bit myopic. Sorry if I seem a bit negative, but I've seen this before, just in a different context.
ReplyDeleteConsider that those people who are skeptical of unsubstantiated pronouncements on programming.reddit.com (choose your favorite aggregator) are probably not going to pass your test. I suppose that doesn't make them a good fit for your organization in some sense. But I wonder whether that really translates into more productivity, or just into a collection of web-programming nerds who are unwilling to question ideas that confirm their own biases.
Just to point out a two examples:
* Cyclomatic complexity: Is this *really* a great metric? Of what, density of syntactic structures? I have seen no strong evidence the time to make the tools work is worth it.
* Learning a new language every year. What relevance does this have to skill? THis isn't a bad hypothesis! It seems like it might in the sense of broadening your horizons. But it also could be that it promotes a kind of programming tool ADD. Again, the benefit is not really substantiated -- just hypothesized and pontificated about in blogs.
Anyway, this skepticism of these checklists is driven by knowing various people (usually older and more experienced) who really *don't* fit this criteria, but who are not only essential to the teams I've been on -- but would be essential to *any* team. And, yes, they are quite technical. They just have lives, and don't read news aggregators constantly. :-)
@e.s.
ReplyDeleteI didn't say you have to use or trust cyclomatic complexity, I'm more interested in knowing that the developer is interested in trying tools that may create improvement. That's why I say "Have you ever run a code coverage or cyclomatic complexity tool against your codebase?" instead of "Do you use cyclomatic complexity tools as part of your build.
Learning a new language every year undoubtably opens your eyes to different ways to solve problems; hopefully, more effectively. Again, I think you might be reading too much into it. I'm not saying you should work primarily with a new language every year, only that you should learn a new language every year. It's up to you to define what learn means to you. For me, it's probably doing one small task with the language just to get familiar with it.
I don't think reading a section of a book or a blog every 2 weeks is too much to ask of anyone. I can't see how you could continually improve without some continuing education. What do these older people do to stay ahead, or do they stick to cobol?
Ok, I guess I misunderstood -- what you had listed sounded more like a checklist, rather than an honest appraisal (I'm not being sarcastic here, maybe I just didn't get what you trying to say). The idea that there are "right" answers to these questions that should be a cutoff for a candidate threw me off a bit...
ReplyDeleteHey, no fair, Re: the "COBOL" comment. :-) Many of the people I work with are highly competent, but they don't devote their lives to code. They learned new tools on the job, when the situation demanded, and they are very good at that. They dive very deeply when needed, and don't necessarily read up on the latest fad every month (or every two months).
I, personally, am an info-junkie -- so I don't mind the requirement in your list.
But the real question to your assumptions here is whether your job *really* requires this kind of slavish out-of-band dedication to the profession (or the literature) or whether this is really a pretense to being a scientist rather than what we really might be, which is a bunch of plumbers. :-)
@e.s.,
ReplyDeleteI wasn't trying to be rude, I was just wondering how they keep on top of their craft. Learning on the job is definitely an option.
I don't think people should dedicate their lives to their jobs (unless they want to). I also don't think that my list requires that kind of dedication.
Maybe I wasn't clear enough. But, I think all of those things are part of your job and should be done on the job.
I don't think the problem with our industry is that people don't put enough time in, I think it's that they don't desire or aren't able to improve.
If you have ability or potential, I'm happy to help. If you are a NNPP and no desire to improve, I'd like to show you the door.
Cheers, Jay
Interesting, learn a language a year. Sounds good but what languages you have experience in (have put something into production) is a different story during your interview. You have experience in what your job pays you to do. This is the same for development methodologies.
ReplyDeleteJust because someone has not done Test Driven Development, does that not make them a valuable candidate. When did tools and methodology become more important then Data Structures, algorithms, relational modeling, etc.
Do you think all those Google PhD's have SCRUM experience when they were hired.
On the other hand, fire them so my skills can command a higher salary for lack of competition.....my rant
@anonymous,
ReplyDelete"When did tools and methodology become more important then Data Structures, algorithms, relational modeling, etc."
I don't think they are. However, the list is meant to find out if the person is interested in continual improvement, not an evaluation of their skills.
I think there are plenty of good programmers who haven't had the need for deep algorithms (Web 2.0) and some who haven't needed relational modeling (Apps with no DB). Therefore, I wouldn't require a candidate to have experience with those things.
I'd say Data Modeling is one of the hardest and most important things you can do as a developer. But, it's hard to come up with a general rule for Data Modeling experience. Design Patterns is a great book, but it doesn't apply across languages all the time. Domain Driven Design is a great book, but it's a painfully slow read.
Either way, I totally agree that there are plenty of things not on my list that make great developers. But, my list wasn't meant to point out who's elite. It was meant to point out who's likely a NNPP.
Cheers, Jay
harsh, but very true
ReplyDeleteSome of you including Jay are approaching this as if some people should just pick up and leave voluntarily. Obviously that is not going to happen.
ReplyDeleteTo me the point of this intellectual exercise is identifying that the labor market and hiring practices in software development are not consistent with productivity/value that certain developers provide.
In other words, if 50% of software developers are inadequate or do not provide real business value, they should leave their jobs because companies wise up and stop hiring them at the expense of those who bring more value, or let go of them.
Really it's companies who continue to not pay developers commensurate with their productivity that keep that 50% employed.
Stupid people do stupid things, smart people outsmart each other...
ReplyDeleteHi Jay,
ReplyDeleteI'm a bad developer, but I earn a decent salary. Can you explain how it would benefit ME to leave the profession?
Mat
Hi Mat,
ReplyDeleteI'd say it totally depends on why you are a bad developer. If you enjoy developing, but need training, then I'd look at getting training instead of leaving the profession. However, if you don't enjoy programming, then I'd suggest finding something you do enjoy.
If you enjoy something, I expect you'll do a good job and be paid well for it.