July 8, 2014 at 9:03 am
GoofyGuy (7/8/2014)
Approach all problems with the belief they can be solved.And if you can't, it's time to find a different profession.
We make our living solving mysteries.
... and preventing them 🙂
July 8, 2014 at 9:38 am
david.wright-948385 (7/8/2014)
GoofyGuy (7/8/2014)
Approach all problems with the belief they can be solved.And if you can't, it's time to find a different profession.
We make our living solving mysteries.
... and preventing them 🙂
I have found that the biggest problem in my work is my work. It is not that the work is poor but the work is an extension of what I then knew with limitations and misunderstandings. The logic of yesterday was predicated by the experiences of the days before, and since that experience was more limited then then now, there were inefficiencies and errors that I would not make today. At least I would hope so.
Finding the errors and inefficiencies in your own logic is one of the more challenging things IT people do. To search your logical pattern which was and still may be prone to commit the same error in the same manor as in the program or object, and then after finding the error, replace that logic with new code or functionality is to rethink, retool, and relearn some of the paradigm we operate under. In short we need to find where we are wrong and fix it, this being one of the most difficult things for us to do, for we really do not want to admit that we were wrong. And learning when we already know it all is hard to understand.:-)
Like others apologies for the preaching.
(And please note that this is not all meant to be serious)
Not all gray hairs are Dinosaurs!
July 8, 2014 at 9:45 am
I enjoyed the article and didn't take it as preaching. Motivation to keep looking for a solution/better solution - yes, but not preaching. However, there does exist the possibility that there is no current solution. That doesn't mean we should give up or stop, but it may be worth saying "I am not able to do this with the tools/knowledge available to me right now" at some point. At that point, start looking for alternatives to the ways available - maybe a "good enough" solution. My first instinct isn't to say "no", but I'm definitely open to the possibility that that might be the answer and we might need to come at the problem/solution a completely different way.
July 8, 2014 at 9:51 am
I have found that talking about a problem with someone else helps me to think logically. It usually makes the solution clearer. It helps when the person knows little to nothing about technology. It makes me think about the problem and explain it in great detail. It is through this process where the solution appears.
It also helps to know when you need outside help.
Tom
July 8, 2014 at 10:48 am
Maybe I'm taking this too much from a developer's stand point, but I'd like to add "don't just think about today's problems, think about tomorrow's problems too" By which I mean, once you know the business and your users, you can start to get a feel for what they might ask for. As your solving one problem, try to anticipate some of the things they may ask for in the near future.
July 8, 2014 at 12:25 pm
Good thoughts for the day in a field where solving "impossible" is routine.
When I think of "never give up" I think of the phrase coined by Pirsig in Zen and the Art called the "gumption trap".
July 8, 2014 at 12:43 pm
I guess I'm a bit more of a commoner, but what stuck in my head is the quote from Galaxy Quest, "Never give up... Never surrender!" 😀
I can't resist trying to figure things out, I'm just a figure-outerer that way.
July 9, 2014 at 2:59 am
I must admit I like to give users an opportunity to attempt to solve their own problems as I see this as having several benefits..
1)They quickly get a better appreciation of the problems and difficulties involved.
2)They tend to then ask better questions.
I work with a lot of intelligent people - that intelligence should give them the flexibility to learn new things even if they are outside their direct remit.
I see my role as tackling the problems that they really can't solve or steering them in the best direction to solve their own problems.
and yes never give up
I usually have a number of really tricky issues that I periodically review as new products come on line that show potential for solving a perceived issue or could massively improve things. They are often good topics in the pub at conferences.
Complex Event Processing is something I am mulling over at the moment.
cloudydatablog.net
July 9, 2014 at 5:36 am
Dalkeith (7/9/2014)
I must admit I like to give users an opportunity to attempt to solve their own problems as I see this as having several benefits..1)They quickly get a better appreciation of the problems and difficulties involved.
2)They tend to then ask better questions.
I work with a lot of intelligent people - that intelligence should give them the flexibility to learn new things even if they are outside their direct remit.
I see my role as tackling the problems that they really can't solve or steering them in the best direction to solve their own problems.
and yes never give up
I usually have a number of really tricky issues that I periodically review as new products come on line that show potential for solving a perceived issue or could massively improve things. They are often good topics in the pub at conferences.
Complex Event Processing is something I am mulling over at the moment.
The problem I have with users solving their own problems is that they usually do so in an Excel spreadsheet and when that breaks guess who gets called to fix it? And of course it will break within an hour of a critical deadline.
July 9, 2014 at 6:05 am
LightVader (7/9/2014)
Dalkeith (7/9/2014)
I must admit I like to give users an opportunity to attempt to solve their own problems as I see this as having several benefits..1)They quickly get a better appreciation of the problems and difficulties involved.
2)They tend to then ask better questions.
I work with a lot of intelligent people - that intelligence should give them the flexibility to learn new things even if they are outside their direct remit.
I see my role as tackling the problems that they really can't solve or steering them in the best direction to solve their own problems.
and yes never give up
I usually have a number of really tricky issues that I periodically review as new products come on line that show potential for solving a perceived issue or could massively improve things. They are often good topics in the pub at conferences.
Complex Event Processing is something I am mulling over at the moment.
The problem I have with users solving their own problems is that they usually do so in an Excel spreadsheet and when that breaks guess who gets called to fix it? And of course it will break within an hour of a critical deadline.
Quite often, you're right. However, building up a reasonably close relationship with one's users does open the door for them coming up with solutions which developers and DBAs implement. That way, the solutions are business solutions rather than just techie elegance, but are put in place in a robust and maintainable manner. And it's the relationship that ensures the solution is sanity checked from both a business and a technical feasibility perspective.
Semper in excretia, suus solum profundum variat
July 10, 2014 at 1:20 pm
crussell-931424 (7/10/2014)
I've always believed I could do anything, if given enough time.
I don't know about you, but nobody ever seems to want to give me time. It's always a rush to solve whatever the users come up with.
July 10, 2014 at 1:23 pm
I don't know about you, but nobody ever seems to want to give me time.
It's 12:23pm PDT.
Don't say you didn't ask.
July 30, 2014 at 8:11 am
My general approach is:
1. If it is a coding problem, I try to come up with my own way so as not to just copy what someone else has done. I have found that makes me learn more about the problem and the different solutions. If I still can't figure it out, then I do some research.
2. If it is an emergency or bug, I first Google or otherwise research the issue, so that I err on the side of safety, i.e., not going down blind alleys that might waste time or make things worse.
In either case, I always compile the sources that helped me and reference them in the code that I change, to give proper credit.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply