Instead, I find it better (except for how long it takes) to walk them through finding the problem as if it's really hard and just nudging them to the steps they'd need to take to find it themselves. They learn even more, and it doesn't immediately show the difference in skill between you and them.
At the very beginning, even a small difference in skill can seem like a lot to the lower-skilled person.
Admittedly, when I started at the present company, I also remarked "this logging tool [Sumologic] is pretty difficult to use". The response from my senior engineer at the time was "it really isn't that hard." and then she didn't answer the question I had and made me figure it out on my own. It felt a bit brusque at the time, but it was very useful in the long run. I did end up figuring out how to query Sumo (I still maintain that its UI is gawd awful), and that's enabled so much debugging.
I think I also ended up authoring our internal documentation's page on how to effectively query in Sumo, which I feel has been read never.
That's a shame, because often I think people that have competence in a subject come naturally to them end up at a disadvantage later, because their foundational knowledge is lacking (at least in cases where that's possible and learning was self driven).
One example of this is learning a programming language through doing compared to actual study and research. By "doing" I'm not referring to a project to cement details, but for example how most people know bash.
Another example would be spoken languages and some of my college professors. I'm not sure I ever heard anyone speak with as good of a vocabularity and diction as one of my CS professors that English wasn't his first language.
Of course, you can always choose to learn something you aren't best at, but at least you know the trade offs (i.e. needing to spend relatively more time to reach the same level of competence as more talented person).
You just have forgotten what it is like to be a child who knows nothing. I've been speaking English since I was a toddler, I'm learning Spanish now and I make tons of mistakes and often can't understand even a basic sentence - but in fact I'm a lot better at Spanish than I was at English when I had equivalent amounts of study into English.
Once you are a minimal level of competency it is a lot easier to study as well. So if you have only a tiny head start you will be top of your class, and that is always more enjoyable.
The mental sphere is where it becomes super vague for me. Did John Von Neumann just study really hard? The anecdotes told about Feigenbaum of Chaos Theory make him sound like a savant among savants. They just kept that childlike curiosity? Doesn’t make any sense to me. It seems they are tuned differently.
....That doesn't track.
If there is such a thing as lack of talent, then "talent" is just "not lack of talent".
For good reason. Wisdom is recognizing which is correct for the current situation. There is no rule that applies to every situation. You have to make a choice and stick with it. Sometimes that means you try something decide it isn't for you. Sometimes you try something and even though you hate it, someone needs to do it so you keep at it - of those sometimes you will turn out to love it in the long run sometimes it was just a job. (it seems to me the only people who actually hate it are justifying a mid-life crisis that turned them to something new - if the mid-life crisis hadn't worked out they would have returned and been happy)
May God grant me the courage to change things that I can, the patience to endure the things that I can't, and the wisdom to know the difference.
if(/some really long boolean value with AND and OR clauses/); { /* some code to execute if TRUE */ }
He was sure that the if statement was FALSE some of the time, but the code inside the brackets would always execute. He spent more than an hour pouring over the code.
It took me a few minutes before I noticed the semicolon at the end of the if statement. I'm sure he felt stupid when I pointed it out.
He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it.
But the alternating between feeling like the dumbest person on Earth and the smartest person on Earth never goes away.
After at least a few hours away (ideally not coding) your fresh eyes will often spot it.
Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).
bool condition = /some really long boolean value with AND and OR clauses/;
if(condition); { /* some code to execute if TRUE */ }
1. It's much easier to notice that incorrect semicolon
2. Even if you don't, you can stick a breakpoint (or log) between when condition is set and when it is evaluated, to convince yourself it works.
3. All modern compilers will produce the exact same code as they produce with it mashed into the if()
if(!condition) is a much better read and less prone to errors than trying to negate a long statement inside the if().
This pattern also eliminates duplication. I have fixed bugs in code where the same long if condition was duplicated several times within the same function (probably with cut and paste). This wastes cycles recalculating it each time and runs the risk of changing one of them without changing them all.
bool subCondition1 = /* something kinda long */;
bool subCondition2 = /* something also kinda long */;
bool subCondition3 = /* something absurdly long */;
bool condition = (subCondition1 && subCondition2) || subCondition3;
if (condition) {
/* do something */
}
Your change also got me thinking of unit tests: at some point it becomes worthwhile to have dedicated tests on that condition, and that's often easiest by putting it in a static method, and that also improves readability.
I take a different approach where I immediately point out the issue, and if they get discouraged about how fast I solved the problem, I remind them that I’ve spent hours banging my head against the same issue. They will probably run into this same issue again, and get stuck again, but next time they’ll figure it out faster, and the time after that a little faster, until it’s basically instantaneous. And then when they’re instantly able to solve a problem for a newb, they’ll have to give the same explanation as I’m giving now.
I've reflected on this point quite a bit because I really struggled with it when I was teaching myself how to code. It's extremely demoralizing in the beginning, because of a couple of root causes (IMO).
1. We place a lot of cultural value around "genius", and we often ascribe that quality to programmers, mathematicians, etc. While some of them undoubtedly are, it's not clear what that genius actually is, and a great deal of people mistakenly believe that they don't have the "right brain" for it, or are not "smart enough", because they don't feel like geniuses. When you make several mistakes when learning a new activity, every mistake reinforces that perception.
2. There are two relationships you can have with technology - that of a consumer , and that of the provider. As a consumer of technology, your perspective is that "technology works", and if it doesn't work, then something went terribly wrong. But once you become a provider of technology, that perspective is flipped. Technology is broken, and if it works, then something went wonderfully right. It takes time to develop that perspective, and so young engineers will have their programs break constantly, not realizing that "broken" is the default state of the world, and in fact now their job is to make things work. Of course it's broken.
If it were easy, everyone would do it and it wouldn't pay as much. It's supposed to be uncomfortable in the same way that exercising at the gym feels uncomfortable. Thinking is effort.
I've been coding for 15 years and could not imagine myself in your classmate's place - but I feel exactly the same while learning to draw.
I try to draw a somewhat straight line or something at least resembling a circle, fail, and feel like it's completely impossible to me, be close to tears, and everyone who can do it might as well be a wizard.
Most people naturally choose to focus on things they are relatively good at, instead of keep banging their heads on something they struggle at.
GP's comment seems to imply it was a negative experience for the newbie, but in all probability given the daily frustrations and chaos of software development in the real world, switching majors might actually be the "right" decision for that person.
> Most people naturally choose to focus on things they are relatively good at, instead of keep banging their heads on something they struggle at.
My parents told me I had to get a degree - they had very little appreciation for art, and some appreciation for engineering, but 0 understanding of computers. So I enrolled in CS so they would get off my back. Before college I had written maybe 50 lines of C.
I was never particularly good at CS - I just did OK enough under the pressure of having a clear goal (a degree) and there being no alternative to success (definitely not moving back in with my parents. I would have preferred joining the foreign legion).
When something goes wrong on the computer, there are two types of reactions: I am wrong, or the computer is wrong. The "I am wrong" person is discouraged and never gets very good at computes. The "computer is wrong" person persists until they bend the computer to their will.
Local football coach often says “failing is progress”: