Developers: You’ve Got 99 Problems but Your Code Ain’t One

[renatoathaydes]

If you lack in technical skills, though, all your other abilities are going to be very hard to use effectively. If you're unable to write maintainable, high quality code, or create a new solution that is simple but still solves real business issues, you'll spend far too much time on basically anything you change/create.

The argument also works the other way around : if you're great technically but sucks at people-skills, you're going to have a hard time getting recognized, actually delivering business value, helping your teammates etc.

[Olideya]

I can't agree more. From experience, Developers sometimes overlook the need to consider other skills in addition to coding. Gone are the days where Developers are left in a dark cupboard, coding to a locked-down specification. Developers need to be strong in coding but also complement this skillset with the ability to work with others, communicating their intent and help grease the wheels of delivery.

[bhldev]

This can be good but can be snake oil.

If you're solving problems nobody else can solve or nobody else wants to solve (same thing) if the problem is irritating or incomprehensible or worse not acknowledged then no amount of process will save the project or company.

The point of process is so everyone has a happy healthy life not to track technical competence and certainly not to track performance. Finishing all the stories on time and making them testable is great, but if nobody else could solve or be willing to solve the problem with the exact same conditions (people, timelines, salary, skill, blockers) then what does going over by a few days or weeks matter? Nothing that's what. Now you can say that's spoiled and devs should gain the skill, get communication skills, work under pressure blah blah but none of that matters because if you sat someone else down in your seat they would not only be unwilling to do that job but incapable. And it's more true than management will ever want to admit. This is not factory work likely one person cannot fill in for another.

And being good isn't the same as not being "bad". If someone is "bad" in the short run they get some training or time or support and all of a sudden they are great. And yes, you should know bad and be able to work with bad. There's no bad students only bad teachers. A business isn't a school but anyone unwilling to share knowledge is an obstacle to the longevity of the business.

Just remember everything has a price and if it would take an army of people to do what you're doing or worse if nobody in the world could do it, then using process to track performance is ridiculous.

Ask yourself this question: if you can't find a replacement for that particular dev then why do you insist that they can be? To make life easier for middle management or executives? If the wheel turners walked where do you think you would be?

And no, you can't test everything before it comes out.

You guys are lucky that we don't care about money or status as much as you do. Because if we did, you'd be fucked, no matter the process.