If a fluent coder disregards good practices, doesn't his fluency work against him?

Question

I am working on a fairly large and buggy application - and due to the way it's written (I'll spare you details, but it violates rules in most areas you can think of), it is next to impossible developing it without major refactoring.

Significant part of the app was authored by interns, n00bs etc.; but there has also been a programmer in the rank of Master Developer, and with all humility, the code he left behind is dubious as well, in a different way perhaps but still.

Granted, his code tends to get the job done - most of the time - but it's typically cryptic, reinventing the wheel (eg. a big custom method accomplishing a rather ordinary SQL db backup) etc. Basically, needless confusion plus lots of overengineering

And it got me thinking that being a highly skilled coder (I deliberately don't use the word "developer", assuming that it indicates a wider set of skills), if not accompanied by other qualities, can actually be sort of poisonous.

Assuming that it's true, some of the reasons I could think of are:

• if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.
• if one is experienced enough to easily maintain a mental image of a complex program, one is less inclined to split it into modules, layers etc.

So my point is that if a fluent coder happens to be a bad developer, their fluency not only doesn't compensate for the latter, but it actually does even more harm instead.

What do you think of that? Is it true (to what extent if so)?

Answer 1

if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

Yes. I've been that guy. And I've learned that it's a terrible thing.

It's all very well for you, you don't have to learn something new.

But what about the rest of your team? They become very reliant on you. They cannot google for "Clive's Quicky ORM" to get help on the object-relational mapper you've written.

And then comes the day they need to hire someone new and they can't look for people with experience in Clive's Quicky ORM.

And finally comes the day when you leave and somebody notices a bug in your ORM. And it will be there, because you don't have a whole community of people testing and fixing your product.

Yes, learning Hibernate might have taken more time than writing something lightweight. But the benefit of doing so is far too great to ignore, IMHO.

Answer 2

•if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

Skilled in the language but not the tools. That's not really even being a strong coder. It is just polishing one skill (language knowledge) and allowing another to get rusty (library knowledge). The other way around is just as bad, but easier to spot.

•if one is experienced enough to easily maintain a mental image of a complex program, one is less inclined to split it into modules, layers etc.

That's just laziness disguised as a skill. It doesn't take much effort to keep what you're actively working on in your head. It does take skill to find the proper seams and split the code along them. Coders who say it was faster or better to leave everything in one spot often can't see which items to split out.

Answer 3

Just make sure this isn't because he's been working in a "If your keyboard isn't clicking, you're not working" environment. We all look back on code and wonder what were we thinking. Also, is this shop in the practice of refactoring their code? That may have been a luxury he wasn't given.

However, we do need to break away from our first idea (the one you can just sit down and hammer out) and do a little more planning, research, thinking. The temptation to get each little problem out of the way is tempting and the whole project is littered with this practice. Nobody wants to pay people to fix things that "ain't broke", so why refactor.

Edit: Let's make sure we don't punish those who do happen to know the answers. There are those who are fluent and write good code with speed. The key is not to approach every problem this way.

Answer 4

100%.

The cynical way of looking at this would be that these kinds of coders are actually keeping the majority of developers in work, fixing bugs which are so fundamental that you can sink thousands of developer hours into it without getting halfway to a stable, flexible, secure, modular or [your favorite software property] system. These systems have so many idiosyncrasies that the very thought of migrating to something else, even with 95% of the features already in place and a vibrant community behind it, is considered somewhere between ridiculous and grounds for being fired.

In short, fluent coders can do more damage than a horde of competitors, but the price is usually paid over many years. And they were usually simply doing their job (as defined by someone else).

How to tell if you're a developer or a coder? I guess that's impossible, but every time you find a way to make your code simpler without reducing quality you've taken another step towards enlightenment.

Answer 5

Having been both in your situation and having caused similar situations I understand your frustration, but I think the answer to your question is a flat "no". Fluency doesn't guarantee that a programmer is going to produce maintainable code. Often organizations force programmers to deliver poorly designed and implemented software due to ridiculous budget and time constraints. It's possible that the fluent programmer is cutting corners only programmers care about to deliver something that customers do care about. Obviously this isn't good in practice, but sadly a reality most every programmer has to deal with at some point in their career. There is also the chance that fluent programmer is just being lazy or complacent. I can speak perfect English, but it's easier and more fun to use slang.

As for the using other's code or rolling your own argument, I think it really comes down to what gets the job done best. Sometimes "best" doesn't account for things like style and maintainability if "best" means deliver a six week project in two weeks. This is why we refactor and refine. Also, the developer has to be aware of what's available in terms of third-party code and they have to know how to use it and trust that it will work and be properly supported/maintained. Given that there are thousands of optional frameworks, libraries, and APIs for any popular development paradigm using such things can end up costing more time, energy, and stress than just rolling your own. Also, I do find cases where third-party code just doesn't do exactly what I need it to do - which is when it's highly beneficial to be fluent.

Answer 6

The problem you described was basically NIH ("not invented here") - are there other symptoms?

Sometimes NIH, particularly if it's isolated to one or two people, can be dealt with in a group discussion ("Joe here has some experience in doing SQL backups using standard libraries - what do you think, Joe?"). This could be less confrontational than you just directly going to the person and saying "Hey! Use the standard library, dummy!" :)

Answer 7

I'm in that boat (legacy fluently written code) and was of the fluent type myself for a while.

The biggest hurdle to "quick and dirty" solutions is always when you need to add more to it later on. When you need more features. There's only so much you can do without structure. After that, it breaks, and it's costly to rearrange it (yet satisfying, but not really appreciated).

Basically, you have to guard yourself against ANY HACK which could potentially become a "workable solution", ready to be sold by an eager salesperson. It's the old "It's not ready! - But it works, no?" conundrum.