OSNews

To some degree, a very well agree with you, and you simply misunderstand by what I mean by discipline.

To start with, as with any other job, the only people that really going to be good at the job are those that truly love it and are dedicated to it - this holds true whether you are a shop keeper, a welder, a CEO, a programmer, or even (dare I say) a politician. On that point we agree.

However, you don't see the discipline in which I speak - you mis-associate so what you are thinking is different from I am thinking. So please bear with me while I layout my thoughts, and try to make them as clear as possible at the moment - at least those which I have thought enough to be able to well formulate.

So let us first layout what I mean by discipline:

To start with, a programmer must exercise great discipline in how a program is laid out. Logic should be clear, predictable, well documented (e.g. comments in the code that are clear). Coding style should be uniform across the team and the company as a whole; that is not to say that the programmers would not work to build a single coding style, but once laid the MUST follow it, leaving their arrogance aside. (A hard task, but it is a must if software programmers are to be respected.) Errors must be handled - ALL errors, not just those that are expected.

While there is more I can say, I have more thought to do before saying it aside from what else I will answer while responding to your comments below.

I very much agree that programmers need more freedom; but not likely on what that freedom is. For instance, coding style is not a freedom for the programmer - to a company, programmers come and go; but the programs remain, and another programmer must be able to pick up the work and continue it on. Programmers need to realize that they are not the only person to work on a project and that they must build the project such that the next fellow can pick it up - the only assumptions should be that they will be familiar with the field in which the program is targeted; that is - if the program is specific to a field of biology, the comments should reflect that and speak to that field so that a programmer (who may not be quite as experienced as the one writing the code) may be able to pick up the software and continue. Likewise, the programming style should be uniform so that any programmer working at the company can quickly pick up the program's source and be able to understand it - having similar logic, error handling, etc; allowances of course as implementation languages dictate.

However, I very much agree that the programmers - the technical people - need to be involved in the requirements gathering and design - e.g. the concept of operations, analysis, architecture, requirements, architecture, etc. The earlier they are involved the better - and not just one programming individual, the whole team in so far as who is working on the project. (E.g. if developer A is not assigned to the project, then they should not be in the meetings; but once it is realized that developer A will be on the project they should be immediately brought in, brought up to speed, and made part of the effort from then on.)

Let them talk to the customer - or at minimum, let them listen in directly on the conversation - e.g. they're in the same room during the discussion - even if the company wants all questions to go through a specific individual who ultimately talks to the customer; and give them some way to pass questions to that individual on the fly.

I realize that most on this list will not like many aspects of the discipline I propose - and for that, I simply would have to reply - grow up, humble yourself, and learn to work as a team for the company. Creativity can still be had within those limits, and far more will be doable and achievable. And if I were your boss and you wouldn't follow the policies set forth, you'd be out on the street just like anyone else who wouldn't follow the company policies - following such policies is part of your employment contract. (And yes, it is legal to let someone go on those grounds.) The sooner you realize that businesses are less and less going to let programmers get away with the antics they have in the past, the better - because it is changing.

Instead of thinking that your job security lay in that only you can understand the code (it doesn't - it never will), think instead of your job security as the ability for you to bring profit to the company - the more you can bring, the better. (And yes, that can be with FOSS too!) But it first starts with working to achieve standard processes, policies, etc. for writing software and then following them and ensuring the whole team follows them.

And if you don't think this works - just look at the Linux Kernel. No patch is accepted unless it meets the standards set forth by Linus and his band of lieutenants - standards that even layout an explicit coding style. It works; and it can be achieved even among the most creative.

There is a time for being creative, artistic and there is a time for it not. Learning to differentiate between them is a good software engineers responsibility; and doing so shows a great maturity that will garnish respect. Coding style is one of those times to set aside your creativity and artistry and just get with it; your work life will be better for it too.

And, btw, I do my best to do this myself. I have one preferred coding style; but I do my best to follow what has been set before me. I may use my own style on projects (it does fit the guidelines of my company - the company coding style is too inclusive to start with, but that's all I shall say on that), but I also try to fit code for others projects in the same coding style that project uses. In other words - I try to adapt to what the company requires of me, no matter my genius or lack thereof.