up one level
---
w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶
As a Software Development and Support Engineer Failing and Succeeding
I’m going to focus on activily failing better. Failing earlier and more often. As a Software Development and Support Engineer I’ve had a fear of failing that’s so bad that it’s that so-called “self-fulfilling prophecy” that results in me failing.
Looking back on a few cases of this, I now see in hindsight that it’s gone like this:
I get a Software Support and Development Engineer task in front of me. It might be a task of “medium” difficulty, which to complete will take back-and forth with other people, over multiple days’ time, and some personal effort.
Then I freeze and just do nothing because I’m scared that I’ll fail. What is the result? Of course because I did nothing, I fail. Self-fulfilling prophecy.
I’m going to try to improve my failing process.
First, in the first hour, within the first two minutes of me knowing about the project, I will estimate whether I can do the project, figure out that I can’t, and tell the stakeholders within the first hour that I’m not going to be able to do this project because X. (X being for example because other projects, full calendar, I lack required Y Access or I lack necessary Z Power). In this way I’ll be failing to do the project, in a way that is better than failing-by-doing-nothing.
Second, I’ll make an attempt to complete one part, iteration, or try at the project, for one hour, then stop, and consider how far done is it? Is it done but missing critical functional elements, and so not done? Or is only done one part of four, and so not done? (Since it really is a medium project, it will be one of these two) Then I’ll tell the stakeholders that I completed one attempt and failed. In this way I’ll be failing to do the project, but in a way that is better than failing-by-doing nothing.
In either of the above, is communicating my progress to the stakeholders in any case, even when the progress is news-of-failure.
In fact, taking it a step further, I’ll communicate every single project of mine as a failure *until the moment that it’s done* at which time I’ll then communicate it as a success.
In other words I’m proposing an “under-promise, over-deliver” method. A key to this though is that I need to A. attempt to complete the project (as opposed to doing nothing) and B. do it with a light heart — with gusto and optimism (as opposed to doing it with a fear of failing)
I know that I’ll find that, compared to the old failing-through-fear-and-inactivity, is this type of actively-often-failing will be magnitudes better.
In summary, I’ll get better at failing. In this way I’ll move towards succeeding.
Edit: This post was previously published at: w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/2016-06-25-engineer-failing-and-succeeding.php
[2019 edit: Moved to: https://i̶n̶v̶e̶s̶t̶o̶r̶w̶o̶r̶k̶e̶r̶.̶c̶o̶m̶/2016/... .html.]