Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Failure Expand / Collapse
Author
Message
Posted Friday, May 16, 2014 10:00 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 3:15 PM
Points: 586, Visits: 6,686
Hrm. Well, it's still rather early in my career (just under four years of being a DBA/Database programmer so far), but I'd say I've definitely failed so far, on several occasions . The core failure in every case to date has simply been that I've failed at failing.

I'd imagine it's not too different for most new programmers, but I could certainly be wrong. When I first started, I had a few screwups and mistakes, and the response I had was one of puzzlement. "How did that go so wrong? I tested it plenty! It shouldn't have done that!" and so on. Eventually, in my puzzlement, I'd stumble upon the answer.

That's not the right way to go about it, though, at least from my current point of view. No, with each new bit of functionality, I should've been thinking "This WILL break. It won't work right. Something's not going to act as expected. But plan for every eventuality you can think of, trap the problems, and improve the process." That's a far better means of thinking, I'd say, and it sadly wasn't until recently that I'd had that epiphany.

Granted, there are the occasional problems that blindside me, but thankfully it's fairly rare and still easily handled. I'm quite happy that, in the case of an unexpected problem, I can now troubleshoot it, institute a fix, and have it back to the users with no harm done by the problem in less than 15 minutes, in my current environment, anyhow. And from that, I learn another way that my code was faulty, and I slap on another lesson about what works and what doesn't.

Now, the next fun bit will see where I fail at in the future other than in this area of thinking




-
Post #1571805
Posted Friday, May 16, 2014 11:57 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, July 9, 2014 11:13 AM
Points: 65, Visits: 366
Steve, Most people measure the value of their careers by their successes, but I am of the camp that measures (in part) the value of their career by my failures... and believe me I've had some spectacular ones. I believe that if you don't have any failures, then you probably haven't stretched that limits of what you are capable of doing, and consequently are falling short of your potential.
Post #1571837
Posted Friday, May 16, 2014 6:07 PM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 2:32 PM
Points: 607, Visits: 974
After 30+ years in IT (and more than that "in the world") I've had my fair share of failures. First rule of failure: Admit it! That's what allows you to work on it and take corrective action. Here's a short list of the ones that immediately come to mind:

- Yelled at a co-worker (in my 20's), which really upset her. Learned to keep my frustration in check and properly channeled.

- Dropped a card deck - several boxes worth (yes, I'm THAT OLD). Learned to carry fewer boxes! (and pick up my feet)

- Deleted an entire production database. Learned to check the SQL in TEST first!

- Argued with my boss. Learned that supervisors aren't always right, but some of them don't want to know that. Started down the road of learning how to tell someone they could stand to improve (without pissing them off).

- Learned that some managers don't care about their people, and that I didn't want to work in that kind of environment. Yes, I left that job. In retrospect probably should have left earlier, but then again the new job I took lasted 10 years and I was making lots more money - and enjoying the work while improving the IT Infrastructure and assisting with a merger (lots of stories there). So maybe the timing was right after all.

- Can't count the number of coding errors, even if I wanted to. Or in how many languages. Just learn from them and move on; no point in dwelling on them.

- Failed to recognize or acknowledge my own talents. I'll bet a lot of people share this one. Maturity, some counseling, and regular reviews of my accomplishments have (mostly) removed this from my reality. Now if I can just keep my ego in check...

And who knows what I'll fail at tomorrow... and what I'll learn from the experience. "It's only failure if you quit."



Here there be dragons...,

Steph Brown
Post #1571956
Posted Saturday, May 17, 2014 3:34 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 10:32 AM
Points: 2,905, Visits: 1,825
I think most of mine were around the people skills thing.

Not grasping the true meaning of what "its not what you know, its who you know" thing and "People and processes over tools and technology".

Being right is no substitute for being believed. Going the extra mile is all very well but if no-one cares then you've burnt some family time doing the impossible for the ungrateful.

Sometimes people are hell bent on doing something stupid. Sometimes less damage is done by letting them get on with it, having their inevitable disaster and either have them learn from it or move on. Trying to prevent the disaster actually prolongs the impact and you can end up being tarred with the wrong brush and blamed. I've made this mistake a few times and ended up being ill because of it. Make sure you are ready for the disaster and have plan B warmed up and ready to go.

I joined IT at a point where people in IT cared that the job was done right. It was a vocation for pretty much everyone involved. It has come as a rude awakening to find that some people just regard it as a job an scoot along doing the bare minimum, collecting their pay cheque at the end of the month.

My uncle said "don't work for losers, try and work for people who are going somewhere". His rationale was that a successful person will want to take his team with him. A loser will get replaced and it is more likely that they will be replaced by an external person (who wants to bring his own team in) than promote from within. You don't promote in a losing team.

Spending too long in a niche subject area. Have a principal skill topped up with niche supplement. That way if the niche closes you have at least some relevant skills on your CV.

Don't go chasing every technology fad. There isn't time to learn it all and you'll burn out trying. Focus on learning the concepts behind the tech and what the tech was designed to be used for. Some things come back into fashion and some concepts give you down different perspectives on how to use the tech you already know.

Above all remember that you spend a huge amount of time at work. If you don't enjoy it then you are in the wrong job. Many of our prisons are in our mind and of our own making.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #1572041
Posted Sunday, May 18, 2014 8:28 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, May 19, 2014 6:11 PM
Points: 1, Visits: 8
Failure is often a good lesson. Throughout 2001' during the .dot.com mess, I kept making the wrong decisions, based on principal, and not best practice.

And today, 14 years later, that failure was a really good lesson, but one of which has had direct consequences on my career as both a software, and database developer.

I've been a store clerk the last 9 years, with no hope to return to Australia, Oahu, Cancun, Aruba, or the 29 states that my experience afforded me to visit.

But in the meanwhile, I did write a business application for the store to manage a complicated product delivery system that's been a huge success -mostly because it forced me to learn C#. The back end was MS SQL which, along with Oracle, and Ingress I had a pretty good command.

But my lesson is not keeping up aggressively with current technology, so if I were to return to the tech industry, catching up would be hard pressed.

It would be more like starting over. But that's ok, too! Because in all the business applications for which I advised, all the software languages I learned, all the software testing positions I served, all the support positions that lead to my experience -is evidence I started somewhere.

Not one of those positions did I fail. I only failed in choosing to stay with a core company being left behind, rather than the break away company with millions in financing willing to leave the old ones behind.

I made the right decision. But, damn I miss the international travel!
Post #1572081
Posted Monday, May 19, 2014 7:12 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 9:24 AM
Points: 485, Visits: 799
My biggest flaw was expecting that others had the same ideals as I had. For example, wanting to do a job correctly. Even today I am amazed at all the people I encounter who just want to collect a check but not do anything. Even if I didn't like who I worked for, I still gave it my best, and I have worked for some pretty bad people over the years. (Note that I have also had the pleasure of working for a lot of outstanding people as well!)

Today I just bring those issues to my manager, and if he ignores them, it isn't my issue. If someone is affecting my ability to get my job done, and it is ignored, then management made the decision, not me. Fortunately I currently work for good people, who understand that it is important to address substandard workers, and who still balance that against the fact that none of us are perfect. What this means is that people who have temporary issues are allowed to work through them, but people who simply shouldn't work on our team are replaced.

All of us come up against toxic coworkers, and it is one of the most difficult tasks we face. How we deal with that not only affects our performance, it affects our health, our family life, pretty much every part of us.

Like all of us, I also make mistakes. I make my share, but prevent this from becoming an issue by owning up to them. In most cases my manager has heard from me before my mistake came to light - allowing them to prepare and respond appropriately before someone approaches them about any issue.


Dave
Post #1572253
Posted Monday, May 19, 2014 7:20 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 9:24 AM
Points: 485, Visits: 799
hisakimatama (5/16/2014)
Hrm. Well, it's still rather early in my career (just under four years of being a DBA/Database programmer so far), but I'd say I've definitely failed so far, on several occasions . The core failure in every case to date has simply been that I've failed at failing.

I'd imagine it's not too different for most new programmers, but I could certainly be wrong. When I first started, I had a few screwups and mistakes, and the response I had was one of puzzlement. "How did that go so wrong? I tested it plenty! It shouldn't have done that!" and so on. Eventually, in my puzzlement, I'd stumble upon the answer.


There is nothing at all wrong with that, assuming you did indeed test it. Asking how something went wrong is not an issue, it is correct behavior. Expecting our code to work correctly before releasing it to end users is also correct.

Those who accept that their code will have issues frequently have far more issues because their standards are too low.

When I write something, say to extract data for someone, I test it until I believe it is correct. At that point, I then tell the end user to expect it to fail. I ask them to prove me wrong. Most of the time they can't do that. But their attempts to break it, or to find my mistakes, generally leads to better QA than I can do myself.

The key to what I am saying is that we should code until we believe we have it right, but we should encourage others to find our flaws that we may have missed. We should not accept our limitations and expect others to deal with it. The line between doing good work or shoddy work is hard to find, but I think most good programmers really believe their output is correct before releasing it. Shoddy programmers believe it is good enough.


Dave
Post #1572262
Posted Monday, May 19, 2014 8:08 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 3:15 PM
Points: 586, Visits: 6,686
djackson 22568 (5/19/2014)
hisakimatama (5/16/2014)
Hrm. Well, it's still rather early in my career (just under four years of being a DBA/Database programmer so far), but I'd say I've definitely failed so far, on several occasions . The core failure in every case to date has simply been that I've failed at failing.

I'd imagine it's not too different for most new programmers, but I could certainly be wrong. When I first started, I had a few screwups and mistakes, and the response I had was one of puzzlement. "How did that go so wrong? I tested it plenty! It shouldn't have done that!" and so on. Eventually, in my puzzlement, I'd stumble upon the answer.


There is nothing at all wrong with that, assuming you did indeed test it. Asking how something went wrong is not an issue, it is correct behavior. Expecting our code to work correctly before releasing it to end users is also correct.

Those who accept that their code will have issues frequently have far more issues because their standards are too low.

When I write something, say to extract data for someone, I test it until I believe it is correct. At that point, I then tell the end user to expect it to fail. I ask them to prove me wrong. Most of the time they can't do that. But their attempts to break it, or to find my mistakes, generally leads to better QA than I can do myself.

The key to what I am saying is that we should code until we believe we have it right, but we should encourage others to find our flaws that we may have missed. We should not accept our limitations and expect others to deal with it. The line between doing good work or shoddy work is hard to find, but I think most good programmers really believe their output is correct before releasing it. Shoddy programmers believe it is good enough.


Oh, certainly! I should clarify; it wasn't so much that I tested it to the limits of the edge cases I was thinking of, I was instead simply testing it to where I thought it shouldn't break. That, of course, didn't include fun edge cases where the users would try things that I hadn't thought of, but really should have . Then, once it broke, I felt personally offended, with the ever-so-terrible mindset of "they shouldn't have done that anyhow! It wasn't in the intended use cases!"

Now that I've stopped thinking in such limited terms, though, I instead test as far as I can, then throw in some random nonsense to make sure the process won't break, and on top of that, I try to plan for any weird-yet-possible cases that could happen, like a user totally ignoring that an import process actually needs something to import, or trying to import an image instead of a text file. Add in the appropriate messaging on those errors, and plan for a few more strange cases, and brace for any failures, and deploy!




-
Post #1572297
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse