Sometimes, being a developer, your job consists of just saying no. No to a feature, a client or your boss requested, no to a new project or no to a developer who is applying for a job.
For me writing code is easy. Sometimes I need to sleep over a problem, but usually I find a solution to a problem quite fast. But dealing with people is a hard thing to do. You have sometimes to do hard decisions.
I just want to give you some examples, where saying no saved my ass in the last two years and where saying no would have been a better approach.
Telling a to unexperienced developer that, he is still not ready is hard. Specially, when it's hard to find new people anyway. It took me a lot of time to find another co-worker, now I have someone, who wrote productive code after just after two weeks in the new job.
My boss asked me to not focus so much on the admin-interface of the online-shop. I refused to do a sloppy job. Now I have something, were I can tell everybody in the company to dispatch the orders with just a two minutes introduction on what they have to do.
My other boss asked me to change the color-schema of an online-shop to "anthracite". On a screen there is not such color. It would have slowed down the render-times, if I used images. So I refused to do so and customers are satisfied with the look and render-times.
A thing I did not clearly refused was to do a project with someone for a hourly monetary compensation. I told my boss, that this would just lead to a lot of emails which requests to change a lot of "small things". Always accompanied by the word "just". Here I instantly regretted not to stayed firm in my position to refuse to do this project for a fix price.
Especially when you are in an environment where you have to deal with non-technical-staff and employers, your role should be more than, "the one who just codes". You have technical insides and experiences, that maybe no-one else has. Use it for good.
What have been your experiences? What have been your success-stories and biggest fails?
Top comments (3)
I find that most feature requests have a valid problem behind them, even if what was specifically asked would lead to a worse product. The hard part is teasing the actual problem out of the request instead of taking the request at face value. Rather than saying "no", I usually find more good will by having a conversation with the requester to figure out what problem their request is meant to address. And then bounce ideas off of each other that can meet their constraints and my constraints (e.g. performance, quality, etc.) while solving the actual problem. If it's something that has unclear implications, then I will add it to my backlog of work but continue to collect information and refine the problem definition until an answer becomes clear. Instead of "no", it's "later".
All that said, I have said No on occasion. One particular consulting job, I refused to do because I was given some donated code from an outside company and told to adapt it to the client's system. They were hoping since the code was already written it would be a quick and easy new integration for them. It was a spaghetti mess that I didn't want to be responsible for going forward, and I told the client as much.
For us it's usually already on the backlog and it's a matter of saying "Yes, but it might still be a while". But feature requests always get a bit of a boost.
No is almost always no for now, or yes, but it has to fit the structure a bit better, here's what we're thinking.
I asked my ex-boss for salary raise. He said "NO". Then he became my ex-boss.