One of the developers I'm mentoring asked me a question about a situation most probably all of us faced.
"I was working on a project, I implemented some features, then it never went to production. The feature was no more wanted. Should I feel bad about it?"
My answer is short and straight:
No.
In detail:
No, you should not feel bad about it.
I'm just joking, it's not a detailed answer.
If you ask the question, I'm pretty sure you already feel bad about it. But why would you do so? Well, I can think about a couple of reasons! You might think...
- What you wrote was a great piece of code
- You put some serious efforts into it
- You lost some opportunities to shine
But are these concerns valid? Probably you already know my answers, but let's see behind.
It was a great piece of code
If you felt like it, it's great! It means you crafted it with care, you did your best to write maintainable code and probably you learned something new on the way.
It's great.
Yet the code - regardless of your experience - was probably not so exceptional. Hopefully, in hindsight, you wouldn't consider it terrific code.
Why do I say that?
Alain de Botton British philosopher said, "anyone who isn't embarrassed of who they were last year probably isn't learning enough."
If in a year you'd have to read your code once again, what would you say? Do you think that you'd be proudly browsing the lines thinking how great software you delivered? Or would you rather exclaim, who wrote that crap?
If it's the first case, it only means you didn't learn enough during the last year. You can be the best developer, but there is still room to learn and get better. If you are so good that it's not the case for you, then I'd advise you to be more humble... But you wouldn't even ask the question that is the focus of this article.
So hopefully, you'd be closer to the group who would be embarrassed looking at their own code. Yet, you shouldn't be that harsh with yourself. You should be grateful for those feelings, you should be happy that you learned new things.
Just because today you think that you wrote great code, it doesn't mean that it's actually marvellous. Don't feel bad about the unshipped code because of its quality. You might want to keep that branch in your fork and look at it in a year, just to verify whether you learnt enough during the past months.
You put some serious efforts into it
You might feel bad about the unshipped feature or project because you put some serious efforts into developing it and now you feel that those were wasted energy.
First, it's not true from your perspective - it was no wasted energy. Second, you shouldn't care about the company's perspective.
Let's start with the latter one, with the big picture. You might feel that the company wasted some efforts. So what? While it might be true, you shouldn't care about it at all. There are different numbers exposed by different studies - as it's impossible to get a precise one -, let's say that half of the software projects fail one way or another. Meaning that your case is not special. A feature or a project going outright to the bin is not something extraordinary. Some might even say that it's normal.
The decision-makers know it better than you. At least they are not afraid of declaring some expenses as sunk costs. They made a hard decision to avoid future losses instead of taking past expanses as a rationale to spend even more. Most of us are afraid of doing so. At least they dared.
And what about your personal efforts?
I hope you didn't waste your own time on it and you didn't do any unpaid and probably even unexpected overtime. If you did, I see why you are unhappy with the loss of your efforts. At least you had the lesson, avoid doing any unpaid overtime. If that's something you are requested to do regularly, look for another job - unless you have a very clear goal with what you want to achieve with unpaid work. Prefer doing a great job within its boundaries and work on your personal projects otherwise.
In case you only worked during your normal hours, don't feel bad, you're paid for your efforts. You gained some experience in real-life circumstances and hopefully, you even learned something during the project. Maybe you practised how to use consts correctly, maybe you applied the techniques you learnt in Code Complete. Or maybe you could use some of the soft skill you picked up in Software Craftsmanship.
Anyway, as long as you were paid and you even learnt something, you have nothing to worry about.
You lost some opportunities to shine
It's arguably better to work on successful projects. I know someone who had to wait longer to get the opportunity she strived for because she was working on projects seriously late. Although it was not her fault and I think she did a very decent job, she simply couldn't showcase her skills as the project was not the right one.
Imagine a surfer without waves, what can he ride? You need to catch some nice waves if you want to rock.
If you want to climb the ladder, if you want to shine you need successful projects.
But nobody's track record stays clean. Even the best football teams lose once in a while, even the best athletes make mistakes and in the case of a failing IT project, it's very rarely the fault of a single person.
Just accept it and be grateful for whatever you learnt.
At the same time, be aware of what happened. If you work on nothing but on failing projects, you should either think about moving somewhere else or think about whether it's still your fault somehow. I mean being on the downside every once in a while is normal, but constantly being the sucker implies that you need to do some changes.
It's like poker. Losing in the short term is part of the game, but losing in the long term is not. It only means that you need to change your game.
Conclusion
You shouldn't feel bad because you worked on a project that didn't make it to production, or because your feature the feature you worked on was not shipped finally.
You'd see it in half a year that it was not such a great code as you thought so.
As long as you didn't put unpaid overtime into it, you lost nothing, you'll still get paid for it and for sure you had the opportunity to learn something.
Finally, it's true that it's better for your career if you can ride the waves of successful projects, but one cannot be always on the top. If your projects always fail, take your consequences, otherwise, just take the stoic approach and accept it as a fact of life that some projects fail, be grateful for what you learnt and be eager to take on the next one.
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let's connect on Twitter!
Top comments (3)
When working in agile environments / UCD environments I think you learn/understand to "let go". Sometimes a feature just does not test well with users, no matter how much business analysis/prototyping we do. I think also a large chunk of code that hasn't gone through that sort of rigour - even though it's great code - you shouldn't be too attached to. An engineer doesn't have that sort of skill set to determine if features are worth it.
awesome post. i wrote some time ago about "detaching emotionally from the code you write" but in regards to code-review critics, code design fights and technical discussion in general, but it is indeed true also to deal with the frustration that comes with not seeing the code not being used at all. very valid points here
also loving the quote from Alain de Bottom!
That is one of my favourite quotes