Open Discussion Thread: "What Is a Professional Programmer?" by Sarah George
This an open discussion thread for the developer.* article "What Is A Professional Programmer?," by Sarah George. If you haven't already, you can read it here, then add your comments below.
Interest in the problem space
Hi Sarah,
Nice article. I miss one aspect you didn't touch : interest in the problem space.
I've had the occasion of working with certain people in the past that had no interest in the problem space but which had various aspects of the 'professionalist' like you have specified. However, my personal feeling is that you can only be a professional if you are also interested in the problem space.
Best regards,
Mario.
"Minimize Risks" Good luck
"Minimize Risks"
Good luck with that. Let me know when you get rich.
Sometimes. Maybe.
Mario, assuming "problem space" is equivalent to "business domain", I'm not so sure I agree.
I will admit that "interest", or at least some kind of personal investment, is pretty important to the development task in most situations. If a developer is working--especially as a full-time employee--in a given domain, it should be that they are tacitly and at least passively absorbing knowledge as they go. Active resistance to this is counterproductive and unprofessional. But when you're talking about contract or consulting developers, you've got a different situation. The very nature of their revenue stream requires only a limited engagement with the problem space, enough to provide agreed-upon solutions and maintenance. They can't afford to get overly caught up in their clients' specific business issues.
And, assuming I understand your comment correctly, there's another exception I must take. One of the primary difficulties I've encoutered in my career is the persistent and (IMHO) false belief that one's skills as a developer must be augmented by biz domain experience. I think this line of thinking hampers understanding of development on the whole, because it fosters this attitude: "OUR line of business is COMPLETELY unique -- if you don't know the business, you could NEVER develop software for it".
To be completely frank, this is BS. The whole idea of the profession of "software developer" is a developer has a set of skills applicable to ANY context. It is our job to abstract the specifics into logic that is functional, maintainable, adaptable, etc. -- not to be subject matter experts. If one's head is too far into the problem space, you lose the perspective necessary to create that abstraction successfully. From my own experience, in the world of business software the notion of domain uniqueness is particularly widespread AND fallacious.
The truth is, business is business; currency is being exchanged for goods and/or services, END OF STORY. You can provide better service as a professional business software developer by:
1) being at the top of your game w/ respect to technology and design, and
2) having a very solid understanding of business concerns and needs as a whole, and keeping those top-of-mind as you move through projects.
As I stated earlier, you should be open to absorbing domain knowledge and getting involved in the problem space as a matter of professional course. But that doesn't mean that only people who have worked on medical office software are qualified to work on medical office software, or that only developers w/ accounting backgrounds are capable of building accounting software. Again, the professional developer should be in a position to facilitate cooperation with subject matter experts in order to make sure that domain knowledge is correctly coded into the software.
Domain Knowledge
Thanks for your thoughts, Andy.
With domain knowledge I think the key is that (ignoring for a moment the effect of management as a middle-man) the programmer and the domain expert need to be able to meet in the middle somewhere. During a project they will learn from you how to better specify what they really want, and you will learn from them a little of the domain.
A good programmer will be able to abstract the problem and write components that are reusable in other domains.
However, when they're writing an instance of that component for a specific application they should have enough of a feel for what the application does that they are not blindly writing from a spec without knowing "where are they going with this?"
Embrace domain knowledge
Sarah,
You have formulated it perfectly : that was the point I wanted to make.
Andy: I did not wanted to 'hint' that good medical software can only by written by people that have enough domain knowledge. I have had experiences with people that were working for several years on a product and were not interested at all in what it was doing. Sorry, but I cannot call such people 'professionalists' whether they are consultants or working as interns in a company. Personally I have been working both as consultant and as intern and I never experienced any major difference in the way I need to go about with domain knowledge.
Independent of whether you are an architect, developer or analyst: you need to be able to understand your stakeholder's concerns. If not, the product/project you're working on is doomed to fail.
I don't believe in the idea that developers are robots with only technical skills to facilitate in the translation of ambiguously written requirements text into software code that matches what the stakeholder had in mind.
Best regards,
Mario.
Same Page
Reading subsequent comments from both of you, I don't think we're all that far apart from each others' opinions. I think my response was pretty strongly worded, but keep in mind that I did state repeatedly pretty much what Sarah replied with: a developer should be absorbing domain knowledge as they go, and to actively resist that is a major negative. And I agree, Mario -- that's extremely unprofessional.
My point is more centered on the notion that domain-specific knowledge is something that must come into a job with a developer. I think that's a fatally flawed notion. The developer's task, in addition to ones I've already enumerated here and in my blog post, is to pick up the necessary information as they go and learn the goals of the system-to-be -- not to know it ahead of time.
Glad to be part of this discussion!
SQL? Up to date?
Keeping up to date by learning SQL? SQL's been around since the 70's... if you don't know SQL, you've got some bigger issues.
Try some other buzzwords like AJAX :)
Unprofessional
No ego
A professional (programmer) is someone that knows they are good without having an ego.
The number of years at a trade does not make one a professional. Experience and dedication makes one good at what they do. I could argue the kid next door is a professional Pokemon player, and he's only 8 years old. He's a pro because he has passion about the game and that's what he does (all day).
But where the kid may not be a professional is if he brags that he's good at the game. Pros don't brag nor boast, they don't have to.
Programmer
A programmer would be hard to describe. His life is really tough. He has to go through uncountable client's requirement,each one different from each other. And,he has to meet each one's expectations.
Professionalism
This is a good start article, but there are things missing in it. Like comparing a little more in detail to other professionals. The responsibility that comes with the classification professional. But like I said it is a good start.
please make every thing clear.
I don't have any comment but i am reading your comments. so, please tell me what the requirements to be a professional programmer. Guys, sorry not sending you a comment rather a question.
Professional Programmer Requirements
Natty,
Your question is a difficult one to answer, because there are no official requirements for becoming a "professional programmer" in the same way that there are for doctors and lawyers and engineers. There is not any certification or standardized curriculum. The way it works generally (at least where I live, in the U.S.) is that you acquire the skills or knowledge any way you can, and then try to convince people to give you a job.
Your ability to get a job is based on how you measure up against other people who are competing for the same job, and also on how much money you are willing to work for. The most desirable and most specialized jobs have the most competition and the highest pay, and the least desirable jobs have the least competition and the lowest pay. Sarah's article (and her web site) is basically about the "informal" journey of becoming a professional programmer, as opposed to a more "formal" or "traditional" path of going to school, getting a degree, and get a job in the software field after college.
A book you might find interesting is After the Gold Rush, by Steve McConnell. Another good resource is the SWEBOK project, which stands for Software Engineering Body of Knowledge. Also, an article I wrote a few years ago called "Making the Cut" addresses some issues related to your question.
Hope that helps,
Dan
Professionalism evolves
Thanks for a great article! I also started programming as hobby as a child, and knew very quickly that I wanted to be a programmer by profession. That was 27 years ago now. :-) I was very fortunate when I was 15 years old to meet a businessman who trusted me enough to work with me writing business software. This was a great experience for me, and I managed to go straight to work writing software out of high school.
One thing I have noticed is that over time people expect more and more out of professional programmers. The level of richness that people expect from software increases over time, and the amount of knowledge required to attain the minimum expected level of utility grows year after year. In addition to objects programmers must now understand agile methodology, unit testing, source control systems, UML, etc.
Young hobbyists can still program to satisfy themselves of course, but the languages are heavier and less nimble. Ah, I can remember when... ;-)
The Making Of Professionals
This article provides a good definition of professionalism.
However, it does not mention an important force that can affect the way developers preceive their work. A force that can nurture them as professionals, or drive them away from being ones...
See: http://articles.qualityaspect.com/the-making-of-professionals/