February 14, 2018 at 9:07 pm
Comments posted to this topic are about the item Muddle Through
February 15, 2018 at 2:50 am
Nice comforting editorial today Steve, thanks. It's certainly how I've made whatever name I have, more as a developer than a DBA but it's the same principle. I've learned and forgotten more stuff than I can remember (that's why I've forgotten it!) but if I need to know it I'll work it out.
I'd comment that muddling through seems a peculiarly British idiom, perhaps I'm wrong, or perhaps you have been lingually influenced by visits to this side of the pond? 🙂
February 15, 2018 at 6:28 am
I continue to muddle through but I make a point of capturing my muddlings on Confluence so the next poor sod has at least a strong starting point.
The great thing about writing stuff down is that those that know better can see where I'm going wrong and correct any incorrect assumptions. One of the problems with muddling through is that, although you will produce something that works, you are never sure if you have produced something that does it the hard way. Where is the trusted source of knowledge on the subject on which you are muddling through?
February 15, 2018 at 7:02 am
Good comments Steve. I'd say that they worst scenario I was in where I really had to muddle through was to support an antiquated phone system. It was a proprietary system that had limited connectivity and administrative options and it worked alongside a different proprietary voice mail system that was equally barren of documentation and support. Both systems were from different manufacturers who were no longer in business. No one at the plant knew much about them other than some very basic tasks, therefore it fell to me to figure out how to go beyond the basic tasks and perform true management including expansion and preventative maintenance. I was able to consolidate the management of them into a single dedicated PC connecting to them both via serial ports. Of course, no one was happier than I when the system was replaced with one much easier to manage and maintain.
I did learn an awful lot from that experience. While I've never had the need to manage another phone system since (and do not plan to do so again!), I did learn a lot about how to address problems, research issues, determine solutions and even to how to make improvements in a less than ideal situation.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
February 15, 2018 at 7:10 am
In the beginning of my career, I learned IBM's Assembly language by muddling through mainframe core dumps and the System/360 Reference pamphlet. I believe that discipline helped guide me through the ever-changing landscape of technologies in application and database development. Thanks for the article Steve.
February 15, 2018 at 7:24 am
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 15, 2018 at 8:07 am
sdorris 90134 - Thursday, February 15, 2018 7:10 AMIn the beginning of my career, I learned IBM's Assembly language by muddling through mainframe core dumps and the System/360 Reference pamphlet. I believe that discipline helped guide me through the ever-changing landscape of technologies in application and database development. Thanks for the article Steve.
I remember learning IBM's assembly language back in the '70. A great way to understand how a computer really works. congrat's on the learning process.
The more you are prepared, the less you need it.
February 15, 2018 at 8:09 am
It's muddles all the way down... 😀
I automated myself out of a job once with 2 DCL scripts on the company VAXen...
February 15, 2018 at 8:12 am
Great points Steve! when you read one of those crazy job descriptions where they want the new person to do everything, you can expect that the person who left was one of those '...take on any project...' types., just like Steve. And it is a great way to learn on the job! Who does not want to get paid to learn?
The more you are prepared, the less you need it.
February 15, 2018 at 8:24 am
chrisn-585491 - Thursday, February 15, 2018 8:09 AMIt's muddles all the way down... 😀I automated myself out of a job once with 2 DCL scripts on the company VAXen...
I once substituted for a migration manager who was on maternity leave. I automated her very manual processes with a few DCL scripts and simplified the process greatly and freed me up to do other things instead. When she returned she was furious because I took a job that only she could do into one that anyone could do and it toppled her position of power.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
February 15, 2018 at 8:41 am
"Fake it until you make it" is advice that was off-putting to me at first and then after I was put into a position that really required it became wise words. Additionally - a lot of good tech people suffer from Imposter Syndrome. This is a good coping mechanism for overcoming that. Muddling through is an important concept especially when stretching outside of your comfort zone.
February 15, 2018 at 9:09 am
jmlakar 69347 - Thursday, February 15, 2018 8:41 AM"Fake it until you make it" is advice that was off-putting to me at first and then after I was put into a position that really required it became wise words. Additionally - a lot of good tech people suffer from Imposter Syndrome. This is a good coping mechanism for overcoming that. Muddling through is an important concept especially when stretching outside of your comfort zone.
A good tech person stops faking it and has finished making it prior to deployment. A bad tech person never stops faking it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 15, 2018 at 9:19 am
Eric M Russell - Thursday, February 15, 2018 9:09 AMjmlakar 69347 - Thursday, February 15, 2018 8:41 AM"Fake it until you make it" is advice that was off-putting to me at first and then after I was put into a position that really required it became wise words. Additionally - a lot of good tech people suffer from Imposter Syndrome. This is a good coping mechanism for overcoming that. Muddling through is an important concept especially when stretching outside of your comfort zone.A good tech person stops faking it and has finished making it prior to deployment. A bad tech person never stops faking it.
I agree. At some point you need to "make it" else you are an impostor. I look at the main point of this article as starting and overcoming new challenges therefore this is good advice. The situation changes once it is no longer new.
February 15, 2018 at 9:44 am
Good editorial, Steve. There's one thing I'd like to suggestion and an observation I'd like to add.
First, I suggest that if someone asks you a question you don't know the answer to, admit it up front but say you can find the answer and get back to them.
Second, touches upon muddling through something, by way of learning something new. Where I work there's another group that support an important public service. They're working with old software. I don't know if the software was home-grown or purchased. In any case three years ago they got together to start designing a rewrite of the app. They were excited about it. They had the talent to do it. But, they were apparently held back. I don't know the details as I'm not a part of that group and don't have to interact with them. All I know for sure is that now people are abandoning the thing en masse or will be laid off because at some point this year the whole thing will be replaced by an outside software solution. It's sad that they didn't get the chance to solve the problem themselves.
Kindest Regards, Rod Connect with me on LinkedIn.
February 15, 2018 at 10:01 am
Eric M Russell - Thursday, February 15, 2018 9:09 AMA good tech person stops faking it and has finished making it prior to deployment. A bad tech person never stops faking it.
Perhaps, though deployment is not always in our control. A good tech person just keeps improving things as much as possible. The serenity prayer helps here. Control what you can, accept what you cannot, and learn the difference.
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply