Tuesday, May 20, 2014

Developers worth a (better) salary test

Recently, I've spent quite much thinking time with the idea of 'being a professional'. I (re)read Robert C. Martin's book "Clean Coder" to get reminded that as per that book, professional developers estimate and test, and play well with others. The book left me also thinking that professionals are people with stories to share of their learnings, and strive to be on an improvement path towards something better.

I've also been thinking about people who are not as professional as one might like them to be. In particular, a tweet just a few days ago left me wondering:
It helped me realize that this is very much true in my experience as well. As much as I work with agile-minded organizations and colleagues, I still keep meeting many many developers, who don't do much of automated unit testing. Or if they do, they do it because they have to and just look for opportunities to maintain the unit test base by deleting most of it on a basis of 'architecture change'. there's individual developers that I trust and respect that test - either test first or test soon thereafter continually.  But 90 % of my sample is still people who think testing is trying out something very little if anything, and trusting that it either works or someone else will tell them about it.

There was one developer, who started off telling me that he is too valuable to test. In his perspective, those who can't code are less worthy. The less worthy in this particular case were product management people, same people who should actually spend their time speaking with the customers and making sure there's a steady flow of income to pay for the development. Saying that is less worthy seems off by much, as there's no chance the developer would get a single customer commit to paying anything for the product. Different is not inferior. The attitude was not a very professional one. I would expect just a little more of perspective, seeing things in context.

There was another developer that was (in)famous for his ability to do quick prototyping. The negative side of it was that while he could make the system run once with the happy paths, his code was a maintenance nightmare. There were hacks and little structure. Any way he could make it work before moving elsewhere was the deal. Other developers quietly fixed and compensated after him, complaining in the background. Making things work now without considering maintainability is not very professional either.

And there was yet another developer. His skills were not that toned but he did his best. He just wasn't very enthusiastic about his craft. When sent to a course he requested, he listened a bit but skipped all the exercises. His learning and enthusiasm was quite low, and requiring paired development in the team is his nightmare - he'd rather work solo. Again, not a very professional approach either.

Thinking through all the problems I've had over the years with developers producing more bugs as they attempt to fix something, developers having no clue of what could break with their change and developers creating maintenance nightmares, there seems to be two things in common.
  1. None of these developers test and think testing. Rather, they externalize testing as somebody else's responsibility. They also tend to like to externalize requirements and designs as someone else's responsibility.
  2. None of these developers practice their craft. They don't talk to others about how to do things better, and submit themselves to feedback and learn actively. They already have "the tool" and that seems to be enough. 
A bad, unprofessional tester wastes his work time into producing very little value. When a tester is bad enough, the rest of the team won't talk to him with various excuses. The bad tester sits in the corner, creates test cases and runs them, creating test cases statuses. A bad tester with a good developer is wasted effort, but not a problem. Bad tester - Bad developer is a pair that seems good enough, as someone needs to do even the most basic checking. But if you've ever seen anything better, you may find it hard to accept. In my experience, in this case the bad developer gets better by removing the tester.

A bad, unprofessional developer causes problems in a much bigger scale. There's no sitting in the corner when your code ends up in the end product and fails. There's the approaches I've seen where you code just a little every week but avoid doing much - to keep the scale in which you fail smaller. 

I'm not looking for the perfect developer. We're all people, with different skills and backgrounds. But if you don't practice, hone your skills and actively get better at what you're doing, could you please consider doing something where you cause less harm to others? Just care a little. 

Testing is learning. It's a thinking tool. Developers who externalize testing delivering just-don't-work-quality systems to testers miss out on being more valuable. And I'd like to believe that we're learning, as industry, to pay better for those who take a bigger chunk of the value chain focusing on throughput instead of sitting quietly in our presumed silos. Be it 'design', 'code' or 'test'. Developers who test should be paid more. Or, developers who don't test should not be paid as much as they are paid now before they learn to be worth as much as their test-able counterparts. Full-stack developer - extending beyond code&test - sounds good, but how come I see so few people like that? It seems developers who consider themselves agile are ones building communities and practicing seriously in dojos and retreats, and unconferences, seeking out mentors they feel they need, in- and outside of their organizations. Or again just my sample?

Within testing specialty, there's a lot of talk about T-shaped testers: doing either business analysis or development as the other thing to testing, extending your skills. That seems relevant as in adding the value you can deliver and thus what you should be worth in salary.  The old-school test case executor testers should be really low pay (or extinct by automation). Active and thinking testers are needed and respected. Professional. 

1 comment:

  1. You are SPOT ON about professionalism (or a lack of) in some people. I honestly believe one of the reasons people push back on agile adoption is because of a lack of professionalism. Developers are no longer the "Superman" of the team and they don't like it; it hurts me to say this but some testers are content doing a poor job and keeping the team "happy". In agile everyone is viewed as equal and brings an equal amount of value to the team. That is hard for some less professional people to handle as they are no longer the superstar. Or even worse, in their mind they now have to step-up their game; what they have spent the last 20 years trying to avoid doing.

    Your last paragraph about T-shaped testers is becoming a personal crusade of mine. I am opposed to it. I don't think testers should do analysis or development work. They should test. Where they can add value (and prove they are worth more $$) is by becoming a better tester. Testers need to raise their game. We can no longer think of ourselves as just GUI, happy path testers. We need to bring a stronger knowledge of Unit Tests, Integration Tests, System Tests, Performance Tests, etc; we need to be able to query databases, hit web services, run our scripts/framework in a CI environment efficiently and effectively. That is a lot more game than many traditional testers are use to or want. As you wonderfully state it requires "active and thinking testers". To me, this is the new "Professional" tester.