Yes seeing ones work in a portfolio is great but who is to say it wasn’t a team that worked on that last project with this programmer only adding in small portions of work.

The other hard part is if you do not read and write code one can not tell the difference between good and bad , clean or not clean code.

If one was to create a test for a programmer to complete it might tell you the that he or she has the skill set but but would not necessarily tell you if she or he is professional in work ethics.

I found this to very tough when hiring a programmer, so now we try our best to weed out the mediocre by try out programmers on smaller projects to get a feel for if they are a good fit for the project and work as well as the others.

The trend over the last 20 years is to pigeonhole developers into developing (coding) only and I’m 100% opposed to that – I usually don’t spend more than about 30% of my workday writing any code.

I’d also say where I work, me or my colleagues could cold-learn any standard tech – PHP, Cassandra, SQL Server, DHTML whatever far faster than the more painstaking and rewarding process of learning enough about our various businesses to provide something useful with these things. The kind of developer that craves not working in a mental factory where coding is 90%+ of your effort is the kind of IT person I’d want.

My “me too” comment: Professionalism, as you describe it here, and some amount of “coding for pleasure” outside of work. These are things I look for in an interview, before worrying about experience with a particular language or database or whatever.

I’m reminded of the “sharpen the saw” entry in The Pragmatic Programmer.

In our company we, as well, try to get the focus a little bit more on those principles. Those teams embracing technical excellence continue to improve. Those teams will find a lot of things in retrospectives where other teams tend to say “well with our team everything is fine but management sucks”.

I say technical excellence or professionalism has something to do with accountability. Development teams have the core responsibility for getting it done. So of course they are to be made accountable for quality. And quality happens on its own as soon as a team starts to understand that technical excellence is the key to delivering in the future, too (Alistair Cockburn on scaling agile and solving technical risks early: http://www.infoq.com/presentations/cockburn-bury-not-praise-agile).

Of course there is a trade-of. But there is a way of approaching it, too: Technical excellence is directly connected to technical debt. There are always parts in the code critical for the future or performance (domain model, database stuff etc.) and there are parts that may never change again according to requirements.
So you may want to focus your technical excellence on those parts where quality is critical for your business.

Of course, if the trade-off is pushed to deliver by a deadline (and you cannot scale) or by money, well then you have to tell the customer what this means for his risks in the future. It is up to them to decide. And its up to the software company to know if are capable of getting the job done with the money they get from it.

Dead simple

Would you say “not too much professionalism please” to your doctor? :)

PS: There is another thing called ‘overengineering’ which should not be confused with professionalism.

Take, for instance, clean code. A lot of code analysers — and people, of course — take for granted that small methods and classes are better. However, research has shown that defect rate gains purported just aren’t there once you cut out the boilerplate code you are adding, and that the “best” size is actually between 100 and 150 lines for a method.

To tell the truth, I’m sick tired of unsubstantiated claims, lousy methodology and statistically insignificant samples. I come across the research Uncle Bob has turned up on TDD, and I keep asking myself: yeah, but is it sound? :-(

I’ve worked with developers that know within 15 minutes how long something will take them and all of the steps. I’ve also worked with some that will say, “Sure, we can do it by Friday” and then deliver two weeks late and with half of the features.

Poor time estimates will kill a company.

From several years in open source, I’d say it’s hard to get paid for scratching your itch.

As a Kanban enthusiast I think value is determined by customers.

As a side note: I do like smart and creative people, I just do not value those traits most. I do like creative surgeons, but I value other traits in them most. Non creative, dumb developers will also leave agile environments or adapt, and are not a major concern to agile development.

But if you’re not tied to a corporation for your livelihood, or your passion drives you to code beyond your 9 to 5 job, there’s a more satisfying way to create things that people want to use. It’s the mentality that says, “Go ahead and scratch that itch.”

So I’d add “entreprenerial-minded” to your list. From the non-productive itch-scratchers come the bulk of the software I use on a daily basis.

Those are the kinds of developers I like, because they’re smart (as Spolsky says) but also are engaged in creating new and useful things. Not everything they create is wonderful or even sellable, but in most of the companies I’ve been at in the past dozen or so years, the bulk of the great ideas that turned into high-selling products came from inventive programmers, not management. Letting smart and creative people take off the tie once in a while is an investment that little companies seem to understand better than large companies do.

” What about developers? I expect there to be only very few working under similar conditions. ”

It will lead to “bankruptcy”. Not being able anymore to develop new features (Ebay anyone?) and have a massive rewrite. Competitors taking over. Patient dead.

“[...] but also the need for a supporting environment, enabling it.”

Important yes. I’ve seen it here and there, I try to instill it everywhere I am. But change starts with developers not cutting corners, not dropping double book keeping.

As a coworker, I’m a developer, I value the proficiency in find solutions by himself. Not meaning completely alone, because we’re a team, but to be able to research without annoying the others in the team. For example, let’s say that a new team member needs to solve a bug and he don’t know where to start, I like to point out where he/she should start looking and he by himself needs to be able to dig down the problem without need help in every little step.

Gettings things done is important. And I value professionalism and “getting things done”, too.
Anyway, there are reasons and/or situations you simply fail on this.
Think about customers not understanding the need for “lightweight” approaches. Think about projects that have to cutdown costs (mostly tests are dropped :-) ) … Think about managers, not understanding the need for usability tests … and some other examples.

Where is the difference between a surgeon and a developer? What is the difference between the industries? If a surgeon disregards sterile procedures it would possibly harm human life. What about developers? I expect there to be only very few working under similar conditions. Are there different levels of “professionalism”?

I believe, it is not only the need for professionalism but also the need for a supporting environment, enabling it. Have you seen much of them?

-Markus