|
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 I am an idiot.
|
|
|
|
|
"Pretty" and "beautiful" are ambiguous when talking about code. It could mean that you make the text easy to read (align curly braces, consistent indentation and capitalization, style enforcing, etc.), or it could mean that you remove all code smells, make code easy to maintain, and appropriately comment your code.
I require my developers to write pretty code in both senses of the term. It's just easier for everyone else to look at and understand what they did. I highly encourage use of auto-formatters prior to check-in.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
my meaning of "pretty" / "beautiful" is hopefully in the highest sense . thus no ambiguity . i attempt to write code which another developer can understand w/ ease . apparently i fail as i am surprised i myself have difficulty understanding my own code after some duration . though on one occasion a job interview i seem to have succeeded as i was informed my solution to the assigned problem was the only one which required no assistance for the interviewer's programming assistant to understand . i was not offered the job .
|
|
|
|
|
Sounds like they already had someone in mind and were just required to do interviews to prove no favoritism. Unless there were red flags during the process, I would have hired you in a heartbeat if you were the only one to do that.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Sounds like burn-out. And "finishing" is never as satisfying (IMO) as seeing the light at the end of the tunnel.
My story (wrapping up a contract):
"Are you sure you don't need any more changes?".
"Yes".
Later ...
"Please change the "form#" on this report". Not "can we". Or "should we". Just do it. etc.
Nooooo.
"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
|
|
|
|
|
Gerry Schmitz wrote: Sounds like burn-out.
That is a definite possibility because I'm still confused about why he left when his code was so great.
Gerry Schmitz wrote: And "finishing" is never as satisfying (IMO) as seeing the light at the end of the tunnel.
That is very true!
|
|
|
|
|
It's not light at the end of the tunnel it's a train coming the other way
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
raddevus wrote: because he was overwhelmed with the C++ code...the best I've ever seen to this day.
Could just have been personal.
But perhaps he got into the mindset that he needed to achieve perfection rather than just good enough.
|
|
|
|
|
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".
|
|
|
|
|
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.
|
|
|
|
|
I've learned the same lesson.
|
|
|
|
|
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
|
|
|
|
|
In simpler terms:
"Hoe to the end of the row"
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Other topic:
Sometime back, I remember you having mentioned about good resources (books, sites, etc., other than the official tutorials) for learning ReactJS. Am not able trace that message of yours, here in CP. Request you to please point me to that message of yours for ReactJS learning; i intend to learn it now.
Thanks in advance.
|
|
|
|
|
|
Thanks a lot.
The Indian edition of this book is available on Amazon India, and I'll procure it right away.
And will go through your CP article later today, or over this weekend. This is a long weekend in India, for Diwali, or Deepavali, the Festival of Lights.
Thanks once again.
|
|
|
|
|
Once you get into it, COM is rather elegant, even with its belts & suspenders.
|
|
|
|
|
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: A CS post grad fresh out of the local state U...not been compiled in at least the past couple of months
And obviously the dev was not being mentored for all that time.
|
|
|
|
|
|
Bob Grommes wrote: he did not like compiler errors
Looks like he relied on a built-in compiler in his head.
|
|
|
|
|
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 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 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."
|
|
|
|
|
okay, that was funny
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.
|
|
|
|