As a Manager: What I value in developers

Stephan,

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

I always thought in this balance between do the “best” solution and deliver software to customer, but never with these words you used.

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.

Great post! Finding a balance between professionalism and getting things done always made perfect sense to me.

From a corporate perspective, you’re absolutely right—companies need the hard-working productive programmers to make the products they can sell. Managers love manageable workers!

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.

I’m seeing that timely and professional time/work estimates are critical.

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.

awesome, thank you!

Well, I agree with you and all, but people have been confusing “professionalism” with folk medicine.

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? :-(

s/payed/paid/

As a Developer : What I value in managers is ability to shut up and get out of way.

Replying to the last bit about too much professionalism:
There is no such thing as “too much professionalism”. You either do your job right (professonally in other words) or compromise reliability of your project.

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.

In the 12 principles of agile (http://agilemanifesto.org/principles.html) you will read “Continuous attention to technical excellence and good design enhances agility”
A lots of the other parts say “deliver”, too. So you have the dame trade-off.

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

This reminds me a boss, who always had the things done, he was a professional… the problem was his code was the most horrendous thing in the world…lol..

s/an account /an accountant /

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.