An inspirational story: tenacity
-
What surprises me is that someone who can write some of the best code you've ever seen didn't recognize his own ability. Perhaps he's among the apparently not-so-small group that are high performers yet secretly believe that they're actually incompetent and that their world will come crashing down once people realize it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
he's among the apparently not-so-small group that are high performers yet secretly believe that they're actually incompetent
This sentiment deeply resonates with me. I have no college degrees, have no published books, and have little recognized public domain work. Being surrounded by brilliant, acclaimed engineers my entire career has always been a source of great anxiety. Even today, 25 years into my software development journey, I still fear I could be discarded at any time for my lack of credentials and/or incompetence.
-
Greg Utas wrote:
he's among the apparently not-so-small group that are high performers yet secretly believe that they're actually incompetent
This sentiment deeply resonates with me. I have no college degrees, have no published books, and have little recognized public domain work. Being surrounded by brilliant, acclaimed engineers my entire career has always been a source of great anxiety. Even today, 25 years into my software development journey, I still fear I could be discarded at any time for my lack of credentials and/or incompetence.
Nothing you listed, other than incompetence, will get you discarded unless, for example, you falsely claimed to have a college degree. And even that might be overlooked, given that you've demonstrated your skills. The fact that you're still around after all these years proves that your employer values you.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Nothing you listed, other than incompetence, will get you discarded unless, for example, you falsely claimed to have a college degree. And even that might be overlooked, given that you've demonstrated your skills. The fact that you're still around after all these years proves that your employer values you.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Of course, its self-perceived incompetence, not actual incompetence. Its a quirk of human nature whereby the more you learn, the more you realize how much you have left to learn.
-
Greg Utas wrote:
he's among the apparently not-so-small group that are high performers yet secretly believe that they're actually incompetent
This sentiment deeply resonates with me. I have no college degrees, have no published books, and have little recognized public domain work. Being surrounded by brilliant, acclaimed engineers my entire career has always been a source of great anxiety. Even today, 25 years into my software development journey, I still fear I could be discarded at any time for my lack of credentials and/or incompetence.
My degree is in filmmaking. I am self taught. The best developer I work with has no IT degree. Two of the best hires I have made over the years had fresh degrees with ink still wet and no experience - and both knock it out of the park every day. I respect the work it takes to earn those degrees, but "getting it done" is all that really matters in the long run.
-
Thought of this story today... I joined a company as a Dev in 2000. They said the previous dev had left because he was overwhelmed with the C++ code he was writing which used COM to speak to a hardware device. They told me, he left in a hurry and told everyone "do not contact me". I was afraid to look at the code. Digging Into Dev's Code Then I dug in and I discovered the most beautiful code I'd ever seen. It was self-explanatory code & I learned new techniques. It was amazing. I didn't have to do much and I got the code working. 1000 Mile Journey That developer had been on a 1000 mile journey and gave up inches away from success. Still blows my mind. And, even after all these years, I remember that code as some of the best I've ever seen to this day. One of my favorite quotes is
confirmed Louis Pasteur (quote investigator[^])
let me tell you the secret that led me to my goal. My sole strength is in my tenacity.
I hardly know anything but I have the weird ability to try a (technology) thing 1,000 times and not get bored or give up entirely.
I had an experience similar to this back in the 90's. A CS post grad fresh out of the local state U had been hired to create a system to process a large volume of data coming from hundreds of different sources. It wasn't getting anywhere, the developer was deflecting and delaying, and I was brought in to assist and assess. The first thing I noticed is that the app was pretty good ... a bit overthought, arguably with overuse of inheritance perhaps but this guy was a newly-minted dev working on his first real-world project (but at least it was greenfield). The second thing I noticed is that it had not been compiled in at least the past couple of months, which means it hadn't been tested. I compiled it and there were a handful of syntax errors and the like. Cleaned those up, ran some tests, and it was actually working. When I asked the dev why it hadn't been compiled he reacted in horror ... he did not like compiler errors, he said, and he always makes everything perfect before compiling his code. Long story short, they had a working product less than 2 weeks after I came on board. I tried to show the kid how to work in a real-world business environment, how to not let the perfect be the enemy of the good, etc., but he was having none of it. He quit in protest and went back to graduate school at some other university in another state and for all I know, all these years later is still doing perfect ivory tower theoretical work somewhere. I went on to specialize in the industry and have rewritten that system three times for four different companies in the past 25 years. So this kid was probably on the spectrum or suffering from OCD or both, but the reason doesn't matter so much as that he had actually created a credible system that was nearly production ready, but was unable to pull the trigger on it, just like the guy in the OP's story. I think the term of art for this is "approach avoidance". Some people are terrified of actually releasing their work into the big wild messy world. And it's probably more common in our craft than in many others because being compulsive and perfectionist is both an advantage and a disadvantage. It attracts perfectionists to the work but puts them off actually finishing it.
-
It was C++ (and a long time ago), but what I remember was: 1. Fantastic / balanced use of classes & OOP 2. Code organization / design which made it easy to discover his original intent. 3. Just enough comments -- actually quite light because the code just did exactly what it "said" it did. 4. Amazing use of C++ #define macros. I'd never seen macros like the ones he created. So clear and so helpful -- but no more. Just like "Einstein"* said 'As simple as possible but no simpler' 5. No over-engineering or confusing stuff, just clean, pure code broken up into pieces that made it all digestible. Keep in mind with all of these comments that this was MFC / C++ which used some custom-created COM components and I had to understand the COM components themselves too (the dev created them) because they interfaced with a laser micrometer. *Pretty sure Einstein never actually said this but it's a great quote.
raddevus wrote:
hey interfaced with a laser micrometer.
I just realized that when you mentioned "speak with a hardware device", the code was actually not a text-to-speech implementation for a voice-commanded hardware piece :doh: I am an idiot. :)
-
Yeah, could've been any of that. It's remained a mystery to me for all these years. It was the lead dev and the other devs that worked beside him that told me "he felt overwhelmed and didn't think he'd ever complete it with his skills".
-
Something that particularly irks my wife (but me too) is that in schools these days (in the UK at least) there is no incentive to "finish" anything. If time runs out, kids get marks for effort, or based on what they've done so far. That's fine, but there is then no requirement to complete the task in their own time. This happens over, and over, and over again and children learn that it doesn't matter if things don't get finished. We see it creeping into politics too; e.g. a new policy is introduced, but before implementation is finished or results visible it gets changed; but the one who started it off gets the praise anyway. We see the results all around; unfinished projects, or products with great potential but not properly finished, or great marketing ideas released without anyone bothering to proof-read. But the worst thing? People never get to experience that feeling when you can finally put your feet up and admire a job well done and take pride in it.
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
Some places here in the states have a "no grade below a 50" edict. Kid can turn NOTHING in and get half credit.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
I had an experience similar to this back in the 90's. A CS post grad fresh out of the local state U had been hired to create a system to process a large volume of data coming from hundreds of different sources. It wasn't getting anywhere, the developer was deflecting and delaying, and I was brought in to assist and assess. The first thing I noticed is that the app was pretty good ... a bit overthought, arguably with overuse of inheritance perhaps but this guy was a newly-minted dev working on his first real-world project (but at least it was greenfield). The second thing I noticed is that it had not been compiled in at least the past couple of months, which means it hadn't been tested. I compiled it and there were a handful of syntax errors and the like. Cleaned those up, ran some tests, and it was actually working. When I asked the dev why it hadn't been compiled he reacted in horror ... he did not like compiler errors, he said, and he always makes everything perfect before compiling his code. Long story short, they had a working product less than 2 weeks after I came on board. I tried to show the kid how to work in a real-world business environment, how to not let the perfect be the enemy of the good, etc., but he was having none of it. He quit in protest and went back to graduate school at some other university in another state and for all I know, all these years later is still doing perfect ivory tower theoretical work somewhere. I went on to specialize in the industry and have rewritten that system three times for four different companies in the past 25 years. So this kid was probably on the spectrum or suffering from OCD or both, but the reason doesn't matter so much as that he had actually created a credible system that was nearly production ready, but was unable to pull the trigger on it, just like the guy in the OP's story. I think the term of art for this is "approach avoidance". Some people are terrified of actually releasing their work into the big wild messy world. And it's probably more common in our craft than in many others because being compulsive and perfectionist is both an advantage and a disadvantage. It attracts perfectionists to the work but puts them off actually finishing it.
-
Yeah, could've been any of that. It's remained a mystery to me for all these years. It was the lead dev and the other devs that worked beside him that told me "he felt overwhelmed and didn't think he'd ever complete it with his skills".
I get "overwhelmed" all the time ... make some Visio diagrams, and all is well again. (Even though I resist initially .. gotta be "programming").
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I had an experience similar to this back in the 90's. A CS post grad fresh out of the local state U had been hired to create a system to process a large volume of data coming from hundreds of different sources. It wasn't getting anywhere, the developer was deflecting and delaying, and I was brought in to assist and assess. The first thing I noticed is that the app was pretty good ... a bit overthought, arguably with overuse of inheritance perhaps but this guy was a newly-minted dev working on his first real-world project (but at least it was greenfield). The second thing I noticed is that it had not been compiled in at least the past couple of months, which means it hadn't been tested. I compiled it and there were a handful of syntax errors and the like. Cleaned those up, ran some tests, and it was actually working. When I asked the dev why it hadn't been compiled he reacted in horror ... he did not like compiler errors, he said, and he always makes everything perfect before compiling his code. Long story short, they had a working product less than 2 weeks after I came on board. I tried to show the kid how to work in a real-world business environment, how to not let the perfect be the enemy of the good, etc., but he was having none of it. He quit in protest and went back to graduate school at some other university in another state and for all I know, all these years later is still doing perfect ivory tower theoretical work somewhere. I went on to specialize in the industry and have rewritten that system three times for four different companies in the past 25 years. So this kid was probably on the spectrum or suffering from OCD or both, but the reason doesn't matter so much as that he had actually created a credible system that was nearly production ready, but was unable to pull the trigger on it, just like the guy in the OP's story. I think the term of art for this is "approach avoidance". Some people are terrified of actually releasing their work into the big wild messy world. And it's probably more common in our craft than in many others because being compulsive and perfectionist is both an advantage and a disadvantage. It attracts perfectionists to the work but puts them off actually finishing it.
Fantastic post! Really great story! Thanks for sharing.
Bob Grommes wrote:
he reacted in horror ... he did not like compiler errors, he said, and he always makes everything perfect before compiling his code.
!!!! :wtf: :wtf: :wtf: I love the compiler. My system has always been. 1. Change a letter or a variable value 2. build 3. inspect errors 4. back to 1. Build early & build often. I had always felt like a unknowledgable person because I would poke around and build, build build! Then someone created that REPL idea[^] and I was like, "guess I'm a genius cuz I been doing that for years." :laugh:
-
raddevus wrote:
think he'd ever complete it with his skills
Life lesson perhaps? At one point I wrote code that I then could not understand several months later when I needed to maintain it. Hard lesson learned - stop trying to be clever.
-
Thought of this story today... I joined a company as a Dev in 2000. They said the previous dev had left because he was overwhelmed with the C++ code he was writing which used COM to speak to a hardware device. They told me, he left in a hurry and told everyone "do not contact me". I was afraid to look at the code. Digging Into Dev's Code Then I dug in and I discovered the most beautiful code I'd ever seen. It was self-explanatory code & I learned new techniques. It was amazing. I didn't have to do much and I got the code working. 1000 Mile Journey That developer had been on a 1000 mile journey and gave up inches away from success. Still blows my mind. And, even after all these years, I remember that code as some of the best I've ever seen to this day. One of my favorite quotes is
confirmed Louis Pasteur (quote investigator[^])
let me tell you the secret that led me to my goal. My sole strength is in my tenacity.
I hardly know anything but I have the weird ability to try a (technology) thing 1,000 times and not get bored or give up entirely.
-
Thought of this story today... I joined a company as a Dev in 2000. They said the previous dev had left because he was overwhelmed with the C++ code he was writing which used COM to speak to a hardware device. They told me, he left in a hurry and told everyone "do not contact me". I was afraid to look at the code. Digging Into Dev's Code Then I dug in and I discovered the most beautiful code I'd ever seen. It was self-explanatory code & I learned new techniques. It was amazing. I didn't have to do much and I got the code working. 1000 Mile Journey That developer had been on a 1000 mile journey and gave up inches away from success. Still blows my mind. And, even after all these years, I remember that code as some of the best I've ever seen to this day. One of my favorite quotes is
confirmed Louis Pasteur (quote investigator[^])
let me tell you the secret that led me to my goal. My sole strength is in my tenacity.
I hardly know anything but I have the weird ability to try a (technology) thing 1,000 times and not get bored or give up entirely.
-
Thought of this story today... I joined a company as a Dev in 2000. They said the previous dev had left because he was overwhelmed with the C++ code he was writing which used COM to speak to a hardware device. They told me, he left in a hurry and told everyone "do not contact me". I was afraid to look at the code. Digging Into Dev's Code Then I dug in and I discovered the most beautiful code I'd ever seen. It was self-explanatory code & I learned new techniques. It was amazing. I didn't have to do much and I got the code working. 1000 Mile Journey That developer had been on a 1000 mile journey and gave up inches away from success. Still blows my mind. And, even after all these years, I remember that code as some of the best I've ever seen to this day. One of my favorite quotes is
confirmed Louis Pasteur (quote investigator[^])
let me tell you the secret that led me to my goal. My sole strength is in my tenacity.
I hardly know anything but I have the weird ability to try a (technology) thing 1,000 times and not get bored or give up entirely.
-
What surprises me is that someone who can write some of the best code you've ever seen didn't recognize his own ability. Perhaps he's among the apparently not-so-small group that are high performers yet secretly believe that they're actually incompetent and that their world will come crashing down once people realize it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.and with just a touch of encouragement..... We (techies pounding code, designing systems, etc) have been programmed to think we cannot ask for help. Decades ago I read a book on software teams and development processes. One of the chapters was titled, "Beware the Dark Office" where you had this one person desperately trying to complete a task. We could do better.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
and with just a touch of encouragement..... We (techies pounding code, designing systems, etc) have been programmed to think we cannot ask for help. Decades ago I read a book on software teams and development processes. One of the chapters was titled, "Beware the Dark Office" where you had this one person desperately trying to complete a task. We could do better.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
We can't ask for help because, as Brooks pointed out, adding more people to a late software project makes it later. One person desperately trying to complete a task often means the truck number of that group is 1. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
We can't ask for help because, as Brooks pointed out, adding more people to a late software project makes it later. One person desperately trying to complete a task often means the truck number of that group is 1. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.truth. But there is a difference between asking for help, being encouraged to ask for help, and the PM trying to make a baby in one month :)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I keep telling my kids that my success is "Not from being the smartest guy at work, but from being too stupid to know when to stop trying."
-
I had an experience similar to this back in the 90's. A CS post grad fresh out of the local state U had been hired to create a system to process a large volume of data coming from hundreds of different sources. It wasn't getting anywhere, the developer was deflecting and delaying, and I was brought in to assist and assess. The first thing I noticed is that the app was pretty good ... a bit overthought, arguably with overuse of inheritance perhaps but this guy was a newly-minted dev working on his first real-world project (but at least it was greenfield). The second thing I noticed is that it had not been compiled in at least the past couple of months, which means it hadn't been tested. I compiled it and there were a handful of syntax errors and the like. Cleaned those up, ran some tests, and it was actually working. When I asked the dev why it hadn't been compiled he reacted in horror ... he did not like compiler errors, he said, and he always makes everything perfect before compiling his code. Long story short, they had a working product less than 2 weeks after I came on board. I tried to show the kid how to work in a real-world business environment, how to not let the perfect be the enemy of the good, etc., but he was having none of it. He quit in protest and went back to graduate school at some other university in another state and for all I know, all these years later is still doing perfect ivory tower theoretical work somewhere. I went on to specialize in the industry and have rewritten that system three times for four different companies in the past 25 years. So this kid was probably on the spectrum or suffering from OCD or both, but the reason doesn't matter so much as that he had actually created a credible system that was nearly production ready, but was unable to pull the trigger on it, just like the guy in the OP's story. I think the term of art for this is "approach avoidance". Some people are terrified of actually releasing their work into the big wild messy world. And it's probably more common in our craft than in many others because being compulsive and perfectionist is both an advantage and a disadvantage. It attracts perfectionists to the work but puts them off actually finishing it.
Bob Grommes wrote:
he did not like compiler errors
Looks like he relied on a built-in compiler in his head. :-)
