September 18, 2014 at 1:16 pm
it has a 5 and 5a in it so the 5a is the .5 in the 10.5
September 18, 2014 at 1:50 pm
This is rapidly turning into a top 100!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 18, 2014 at 2:15 pm
No doubt this is a topic we all are learning or have learned. To be honest I have been doing this for over 30yrs and I still come across stuff I didn't know.:-P
September 18, 2014 at 4:10 pm
This (plus the additionals posters have added, they're great!) should be put on every programming-related wall in every school in the US. The list is absolutely awesome!
5a. is the hardest, and most critical thing for a developer to learn. I can't count the number of times I made a serious mistake, and then compounded that mistake majorly by taking an un-thought out kneejerk reaction fix that left me in far, far worse shape than I had been. When all the blood drains from your face as you watch that mistake unfold, place your hands firmly in your lap and think about what just happened for a bit.
September 18, 2014 at 4:26 pm
SimonHolzman (9/18/2014)
Doctor Who 2 (9/18/2014)
I really like your step 5a, "When you make a mistake - STEP AWAY FROM THE KEYBOARD". Now, honestly that might not always be possible. There could be people standing around you, requiring you to "sit there until it's fixed". But if you can, stepping away to think about what's happened and why, might save frantic attempts to speedily fix a problem and possibly just making it worse.In my experience, stepping away is expecially helpful when there are other people around and actually increases their respect for you - By all means, be honest and explain what has happened and why you need to take a moment before diving in to fix anything. That will help sooth the other people so that they can calm down as well. After all, the main reason your boss stresses out about a mistake that you make is because they are afraid for THEIR job. Yours may already be toast as far as they are concerned, but they don't want to join you under the bus. If you can calm everyone down, work out a practical solution, implement it and then provide your boss with some practical suggestions on how to avoid similar issues in the future (or explain why there is no practical way to prevent similar issues in the future), you may get promoted instead of fired.
If you do work in the sort of environment that demands that you "sit there until it is fixed", find another environment. Even if you are working on software that is really a matter of life and death, there WILL be errors. Unless your name is "God", you are not perfect and will make mistakes. So will everyone else. An environment that does not accept any mistakes is corrosive because there is no way to avoid all of them. The end result will be huge turnover in staffing as people are fired for their mistakes, which prevents anyone actually learning from their mistakes and improving.
Finding another environment is harder than you think. Due to economic conditions (the place I was working for has been experiencing cutbacks in budgets and staff for years) this year I was one of those let go at the end of the fiscal year, due to further cutbacks. So it wasn't a condition such as you're describing, in fact things were fine when I left. Anyway, the point is that it really isn't easy to find a new work environment. My position lost funding at the beginning of July and I'm still looking. It doesn't come quickly. So, generally speaking if one were to find themselves in a hostile environment that you described then yes I would agree leave, but be mindful of the fact that you might not find anything new quickly. Better to stay there at least long enough to get a new position, then give notice. And hopefully the funding for your position will last long enough for you to do that.
Rod
September 18, 2014 at 5:04 pm
Doctor Who 2 (9/18/2014)
Finding another environment is harder than you think.
I've been lucky with my career in that I have never wanted to leave a job because it (or the other people there) sucked. However, I have been laid off a couple of times and, you are right... it is a nightmare finding a new gig. On one of those occasions, the reason I was laid off was the economic climate and so my job hunt was against a riptide - it took most of a year. Trust me, I know how hard it can be to find a new job.
Still. If you are working in an environment where you are constantly scared of losing your job anyway, where you have little authority or support from your colleagues and bosses but you have lots of responsibility, or where you are doing work that you do not occasionally feel pride in... GET OUT.
Take a month or two. Maybe three at the most, but get out of there. Otherwise you will get sucked into that morass of misery and you will end up destroying any relationships you have and losing the desire to remain in the best job in the world - you'll eventually be fired or quit and will next be seen on Fox News wearing camo, a beard and a tin-foil skullcap. It ain't worth it.
September 18, 2014 at 6:41 pm
I would also add:
5a(1) When you step back to the keyboard have another coder otherwise remoted in or next to you that can understand what's going and speaks the <native language> and can explain what's going on to the supervisor(s). That way you can fix the error(s) and not lose concentration.
There's been more than once I've been working on an issue and the people kept calling me or coming to my desk and bugging me especially when it was some sort of three fold problem that I'm solving. So I effectively lost the details of the fixes I would have to do.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
September 18, 2014 at 6:43 pm
Great list! Sent the link around the office.
There's a commandment missing from this, though it's somewhat related to the Aye Aye Capt'n Bligh Commandment:
We are not the business; we are the expiditers. We don't make the rules and we don't need to provide perfect solutions, we translate their needs to automation and convenience while preserving cost and sanity.
AKA: Don't overengineer the solution, or over-emphasize the problem.
Far too often I've seen people try to convince business of what they want, instead of talking with them and trying to provide them what they need.
IE: "I'd really like to not have to copy and paste this website page into excel and then reformat it heavily to get the totals for the salespeople on a particular day."
Wrong answer: "Well, then what you want is us to code that up in SSRS, write up this and that and then you'll have to go over here in THIS system..."
Right (first) question: "What do you have to reformat? Depending on what it is we could probably just make the page display the way you need or give you an alternate display."
2: "Audit needs us to archive this information that we use from this webpage for determining the rates we applied to that month's mortgages."
Wrong Answer: "Oh, wow, well we'll have to hook up to them and see if they have an RSS feed or we can apply an OCR scraper..."
Right (first) question: "How often, and would a screenshot repository work or do you need something more complex?"
I purposely took these out of the T-SQL arena simply because sometimes we're too close to our tools to see the overkill we occassionally try to provide. Even when we're aware of it, we still do it if we don't step back and go... Waaaaiiit just a second. Constant vigilance is required, though. I know damned well not to do this and I still catch myself a few dozen miles down the road when asked to put a sign just outside the village.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 24, 2014 at 9:08 am
Great editorial, thanks. 😎
qh
October 24, 2014 at 5:02 pm
I missed this article the first time around and glad it was republished. Absolutey awesome job. I especially like the part about putting the documentation into the code where it can't get lost.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply