It just happened that I used Python for months to work on my thesis. Those few months weren't enough for me to become a master in Python. It's almost two years from my graduation and I haven't touch Python since then. I'm currently using PHP at work and having no personal projects in Python.
Nor am I an active helper volunteer at https://discord.gg/python. Only a few times a month or two, I may visit the server looking for people who need help.
Am I seeking for reputation? With all these thanks?
It could be the case, but firstly, I have no inclination to publish it on LinkedIn. So, there's no one on the internet will know about it. Secondly, no one at my company will be interested in it. Because we're not using Python, haven't, and likely won't. You may ask why on earth it must be Python in the first place? Simply, just because I already joined into the server, not to any Laravel server.
So, am I seeking for reputation? That's only a consequence. Of what? Practising!
Getting real-world problems. We can always look for any problem, but it's often only something we've made up. While having solutions for someone's real-world problems may solve our own problems some day.
The solution may not solve other problems directly. Consider we had this yesterday:
1 + 2 * 3 = 7
But we have this today:
1 - 2 * 3 = ?
The number 7 cannot be the solution, but our approaches yesterday can lead us to the solution.
One day, someone chatted me in private, asking me to help with his technical problem for his thesis. The problem was so simple: how to run a Python script from PHP. I asked why and he replied that he wanted to trigger the opening of a window, that'll run his computer vision project, by clicking on a button on a web page. I said that it's possible, until we run into the environment variable isolation issues. A few days later, when I encountered a similar situation, I already knew that the approaches wouldn't work. So, need to find another solution.
Defining problems better. Not all problems are clear. The ability to recognise problems is a skill in itself.
// 1st case console.log("0" + "1" == "01"); // returns true // 2nd case console.log("0" + "1" == 1 ); // returns true console.log("1" == 1 ); // returns true console.log("0" + "1" == "1"); // returns false // 3rd case console.log("01" == 1); // returns true console.log("01" + 1 == 2); // returns false
+----+-------------+ | id | invoice | +----+-------------+ | 17 | 0001/A/2022 | | 18 | 0001/B/2022 | | 19 | 0002/B/2022 | | 20 | 0002/A/2022 | +----+-------------+
Of the sample records above, without Ben needs to continue explain further, we already know where the question is headed.
If we hadn't asked Ben what he's trying to do, we'd have gone too far to explain, we'd never come with:
var newInvoice = ((+"0002") + 1 + "").padStart(4, "0"); console.log(newInvoice); // returns "0003"
In real life, I'd asked to add a feature in response to the client's problem, but the solution brought up to me won't solve the problem. So we got into a fight just because she was too lazy to discuss further with a hard-to-compromise client. I've lost. As a result, I wasted some times just to see the feature removed completely. It's hard not to admit as to, "Just hit the delete button, right?" Correct!
It's just a small feature. I've had the experience of deleting an entire rebuilt page from scratch. The client asked to come back with the non-digitalised solution, when I believe that we only needed to make some adjustments to our solution if only we could have spotted the real problem earlier. Today, the problem still exists; there's no alternative solution yet to integrate the spreadsheets into the database, since I'm refusing to rebuild the page a second time.
Responding questions nicer. Talking is an art in social life. Not everyone can gently say, "Next time, please ask the actual problem, okay?" Instead, some people find it easier to say, "Don't waste my precious time with XY problems." They don't realise that they left another problem without solving anything, "What's the XY problem?"
I've seen someone come up with, "How do I print hello world in Python?" Many times, people would solely throw away some how-to-codes article links. Or demeaning by saying, "Learn the basics and come back with quality questions." What if he had done with:
print 'hello world'
But it didn't work at all, because he had a newer Python but an older lecturer.
Avoiding problems gentler. Not everything can be answered. Sometimes, it's against the law. Other times, it gets out of context.
Unfortunately, I often come across such bad habits from people who, sadly, do more in commenting than writing articles on DEV.
Maintaining own behavior. Sometimes our kindness isn't rewarded with good behavior. We'd spent our precious time answering his question, but he just disappeared. So, we'd been waiting for him forever in case he'd respond.
Sometimes, we'd managed to solve his question, but he forgot to say thank-you.
Another time, we're forced to deal with someone who's grumpy.
This is quite problematic, even today for me. We don't want the questioner to ruin our whole wonderful day, by leaving us to respond with similar tension and bad words. Don't let him turn our good behavior into an equally toxic person.
With many practises, we can definitely become better-behaved people in dealing with chaos.
Googling more effectively. We can master anything, but not everything.
Sometimes, we don't even know the context of the question at all, because it's new to us. So, we need to do a quick review before starting to think of a solution. To find out more, we can read the official documentation or the
man pages. But oftentimes, googling for the problem or similar ones is more effective. Also more efficient than buying a book.
Sometimes, we can't think of any solution. Or we doubt that our solution is the best. Or we're bad at explaining the solution. Or we don't know to compare two solutions. We need not to worry because someone may have done it somewhere on the internet.
Helping others can help us practice googling better, discovering best practises ourselves.
Picking suitable solutions. When we get more than a solution, we must decide carefully which solution is the most suitable. What'll be the most suitable? Here's what I've learned: get to know the questioner well, his background and himself. If he's among the beginners, we don't put any concerns against big-O notation or other advanced topics. Just keep it simple!
Someone may ask how to perform mathematical operations in string. I've seen this quite often. So, let him do:
math_op = "1 - 2 * 3" result = eval(math_op) print(math_op, "=", result)
Don't bother him with security issues and suggest moving to
ast.literal_eval(). But well, usually, someone asking such a question isn't allowed to use
eval(). That's just an example case.
Learning from others. I sometimes fail to prevent myself joining the conversation. That's a big shame. Not because I don't want to help, but just because I'm incompetent. In that case, let people answer the question while we learn together with the questioner.
Not only can we learn about the solution itself, but also learn how people arrange kind words to answer the question. And learn how people deal gently with someone who misinterprets the problem thus gives the wrong solution.
That's all for today.
So, again, am I seeking for reputation? Yes, I do. Having better soft skills can improve our reputation in the workplace, indirectly. It'll be more effective than waiting for opportunities in the office that might never come.
But more importantly,
If you want happiness for an hour, take a nap. If you want happiness for a day, go fishing. If you want happiness for a month, get married. If you want happiness for a year, inherit a fortune. If you want happiness for a lifetime, help somebody else. —Chinese proverb