is it about fancy titles in software development? no! it’s about your attitudes!

I’ve read some articles in the past that discuss the importance and hence difference between some titles or roles which are involved in software development. Whether it’s the discussion of ‘Programmer vs. Developer’, ‘Developer vs. Designer’ or ‘Designer vs. Architect’ – all those essays contain not more than hollow words to me, since they first of all argue about nifty titles.

In fact, when it comes down to the core of software development – it’s the value we create for our customers that counts, no matter if we’re called an architect or designer. questions like ‘are you a programmer or developer’ are completely irrelevant, as it doesn’t matter if we don’t take responsibility for what we’re ‘producing’.given a sound technological background – compare an ‘architect’ who doesn’t take care about the projects progress (i’ve seen some of them which seem to be interested in the more funny things – building a technical prototype and leaving the project prematurely without taking care about the shortcomings of their consigned ‘architecture’) and a ‘developer’ who’s all in all interested in the quality of her results. which of those will give more value to the overall goals of a project?

do we really add value in respect to our customers needs at everyday work? do we take responsibility in your professional environment?
independent of a particular functioning within a project, the following attitudes are considered essential when we want to take care about the long term value of our work.

passion

passion drives us to the limit. we don’t settle for a half baked solution.
for example, we don’t want a solution (even in the small) not only to work as required, but also in conjunction with the projects goals, that may be code that’s easy to refactor or readable and easy to maintain (as Martin Fowler said: ‘any fool can write code that works …’).
accepting the surrounding forces, we want to get the job done in the best way that is satisfactory for all participants.

empathy

we not only produce artifacts. we also produce means that will help others to get their job done, too (be it the end user or our very next team mate, who’s efforts are based on our products).
for example, we not only want to write code that is somehow well structured, but code that is comprehensable to other developers, giving them orientation, i.e. helping to maintain or evolve the code.
we not only think about getting a job done, but getting it done in a way that will provide meaning or at least support for others, helping the project to progress.

curiosity

we not only work with our brain turned of, but strive for knowledge that will help to produce solutions that are in conjunction with the needs of our clients.
for example we not only implement relayed requirements blindly, but want to give productive feedback when recognizing contradictions, inconsistencies or incomplete specifications.
we not only will produce only as much as mandated to accomplish a single task but also use our head and/or question until we understand in order to produce solutions that are truely essential to our customers.

communicative

we share our insights, giving others the chance to evolve or at least avoiding to make mistakes (may the ones that we’ve encountered the hard way).
for example, we not only want to give documentation but to ensure that others understand our results in the right way.
we not want to fight a one-man-show for others, but know that the whole team is essential to progress and hence help among each other by passing relevant knowledge.

courage

we adress problems, even if they are uncomfortable for us or the team in the short term, but to avoid greater damage in the long run when concealing it.
for example, if we encounter a design flaw that we can bypass in order to get our current task done, we even adress the problem officially, giving the chance for a decision towards a more expensive solution.
we aren’t keeping quiet about problems, giving the customer the chance to react, even if such problems are unpleasant for all participants.

pride

we are proud about the products we create. those pride is expressed in the achievable quality of our products under the given circumstances.
for example we we’re willingly ‘sign’ a class or component with our name, giving others the chance for feedback or questions. We stand to the code that we’ve produced.
we’re not proud of the title we’ve received within a project. we’re rather proud of what we’re contributed to the overall goals of the project!

what’s real important

so what’s the bottom line?

the importance of our role in a software development project doesn’t come with an official title. It’s more about how much we’ll take care about the projects goals, feeling responsible about what we are contributing to the project in the long term!

it’s time to get ‘titled’ by the real value you’ll produce for the project and your customer in the end, than by some official role names.