That sounds straightforward enough. Take your job seriously. As professionals, we can do no less. We have to do what we feel is in the best interests of the project. Which means exercising best practices, writing the best code you know, and making the best decisions possible under the circumstances.
The "best" here is a sticking point because best practices are situation-dependent. There are situations where what's considered a "best practice" elsewhere is a nuisance and waste of time here (Like SEO for a data management system. Or anti-XSS safeguards for a static site...). And of course, we have to consider the fact that clients and higher management have a very different view of web development. It's not necessarily a wrong view, but the business perspective markedly differs from the technical one. Even discounting that, sometimes technical professionals have different preferences where implementation is concerned. And it's usually a good thing to discuss, debate and come to a consensus. But where does one draw the line? When do you reach a point where you say - enough is enough, let's put it to a vote and get on with it? Where the development process is concerned, are you engine grease or a spanner?
A couple years back, I was an in-house web developer in a small department within the company. I reported to a manager and worked alongside a few other colleagues. There was one that stood out, in particular. Not because she was ugly, because from an objective point of view she really looked all right. Not because she was bitchy, because, credit where it's due, she did make an effort to be nice. But because she was a massive pain in the ass to work with.
Ouch. |
An early example
Picture our manager holding a small team meeting. There were a few projects on hand that the team needed to produce, and we were discussing specifications. Our manager was saying how she planned for the project to be coded the traditional "procedural" way when my colleague raised an objection. No, she declared, there was no way she would agree that the project not be coded in her framework of choice. And of course, there was the obligatory back-and-forth about the pros and cons of a framework-coded project vs a traditional approach. I had zero problem with that. My manager had her say, my colleague had her say. Everything was cool, right?Not so.
My colleague argued her case vehemently and it was quite apparent that there would be no compromise. It must be coded in an MVC framework. She was adamant about it. I almost expected her to start stamping her feet for emphasis. My manager, tactfully, moved on, but I could tell she was perturbed. After all, she was the manager, for goodness sake. She was the one who would be held accountable if the project tanked. Granted, it was our duty as her colleagues and subordinates to point out any potential pitfalls, but shouldn't she have the final say? On my part, I was appalled, but I kept my peace. This wasn't my fight.
A mystifying question
Months later, our manager got transferred. This troublesome colleague got promoted.After her promotion, my new manager wasted little time getting me alone for a 1-on-1. And she laid a real beauty of a question on me.
"Do you have any problem with the fact that I got promoted despite the fact that you're older and more experienced?"
I was honestly baffled by this. Seriously? This was taking insecurity to ridiculous levels. I was not going to dig my heels in and refuse to budge just because I think she had her head up her ass. That would be unprofessional, prima donna behavior.
This is how I see it - the company pays me for my cooperation, and thus my cooperation is assured. Same for clients. If I think the client's requirements are not in the best interests of the project, it is my professional duty - no, obligation - to advise accordingly. But that is as far as it goes. Because however much I take "ownership" of the project, ultimately it's not my project, and it's not about my satisfaction. Every professional needs to take a certain amount of pride in their work, but they should never let their ego get in the way of delivery. At the end of the day, delivery - to client specifications, of course - is what counts. You can have the most technically solid product in the world, but if it expressedly goes against client requirements and you're unable to get the client to sign off on it as a result, you have a big fat zero.
Be reasonable - do it my way. |
This is not to say that I will automatically agree with everything. If I have reservations about what's required of me, I will voice them. But I will voice them only once. And after my objections have been filed for the record, it is time to STFU, roll up my sleeves and get cracking.
Many people think that professionalism is about excellence. They're not wrong. But it is also about compliance. Compliance to standards, compliance to procedures, sure. But most importantly, compliance to product specifications. Because if this is not met, the other two no longer matter. Therefore, if the client wants a piece of shit, he is going to get a piece of shit. In fact, he is going to get a magnificent steaming pile of excrement. And I will gladly take a long piss over that pile of excrement, just to give him his money's worth. This is not about how much better I can do, or how superior my knowledge is to the customer's. In fact, this is not about me, period. It is about delivering what I'm paid to deliver.
Where's your professional dignity, man?
That is my brand of professionalism - pragmatic, un-fancy, and utterly workman-like. It's all well and good to have principles. But the one principle that should receive top billing is - Get. The. Fucking. Job. Done.
Be engine grease, don't be a spanner - be a lubricant, don't be a tool.
T___T
T___T
No comments:
Post a Comment